Re: [exim] Storing messages in Maildir format with symmetric encryption
On 2022-11-23, Jeremy Harris via Exim-users wrote: > On 23/11/2022 00:16, Dengler, Gabriel via Exim-users wrote: >> I want to store the incoming e-mails using the Maildir file format encrypted >> by using some symmetric encryption using the user's password > > It seems like a generally valuable concept - but I'd think that assymetric > encryption > of the data-at-rest is more appropriate than symmetric. The MDA (exim, here, > receiving > a message and delivering to file) shou be able to encrypt for the destination > user > but NOT decrypt. So it should have access to a public key and not a private > key > for the destination mailbox - and this is entirely separate from notions of > SMTP authentication. > > Where to implement it in the code? Probably pretty late in the appendfile > transport; about where it's doing actual writes to the file fd - and using > a public key supplied via a transport option (which the config pulls > from a database lookup using the username, or localpart, or whatever) > and perhaps another giving the cipher scheme. Perhaps use some sort of GPG wrapper as a transport_filter, and do decryption client-side? -- Jasen. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Storing messages in Maildir format with symmetric encryption
Hi Heiko, Hi Andrew,
thanks for your answers! At first, I wasn't aware that Exim has such
fancy concepts for on-the-fly modification of messages.
Mybe I'm missing the point. The on-disk representation of the password
is a hash. That can't be used for symmetric encryption/decryption.
You want to "grab" the real password during user login, and save it
somewhere for later use as encryption/decryption key?
yeah, that's my main idea. For clearness, a "normal" communication
profile would look like this:
* An external sender sends an e-mail to our local Exim Server.
* The Exim Server saves the message, e.g. via Maildir, encrypted with
the password of the receiver.
* When the receiver wants to access the message, e.g., via IMAP, he/she
encrypts the saved message again via its private password.
The goal is therefore that the messages are only encrypt-able when you
have access to the password of the receiver. And of course, a secure and
private password is necessary to prevent easy brute-force attacks.
Which user: the sender or the recipient ?
Intentionally, I wanted to encrypt the file with the password of the
recipient, so that an IMAP server can again decrypt the message. But now
as you ask: I think this is not possible, as you can only "grab" the
password when the "receiver" sends a message him-/herself and needs to
expose the password.
I think I have to sleep about this concept one more night, but besides:
would the general setup be possible with transport_filter if the
passwords are not hashed (although this is obviously a security issue)?
Best regards,
Gabriel
Am 2022-11-23 23:22, schrieb Heiko Schlittermann via Exim-users:
Hi Gabriel,
Dengler, Gabriel via Exim-users (Mi 23 Nov 2022
01:16:19 CET):
I want to store the incoming e-mails using the Maildir file format
encrypted
by using some symmetric encryption using the user's password (e.g.,
AES). So
in the end, Exim should write the encrypted files directly on the
disk.
Furthermore, it would be convenient if the actual password is solely
persistent saved as a hash (for checking at authentication), the real
password - and therefore the en-/decryption key - is only temporarily
available during the login session.
Mybe I'm missing the point. The on-disk representation of the password
is a hash. That can't be used for symmetric encryption/decryption.
You want to "grab" the real password during user login, and save it
somewhere for later use as encryption/decryption key?
IMHO no source modification is necessary, $auth2, $auth3 (depending on
the AUTH scheme you use (needs to be PLAIN or LOGIN) contain the
password. You're free to save it whereever you want (using SQL, using
embedded Perl code, using any external command, using readsocket, …)
The encryption I'd do with a "transport_filter", which basically is
can be an "aes-pipe" or similiar.
Therefore, I wanted to modify the Exim source code directly but was
confronted with a large amount of code, e.g., the differentiation
between
the different transport types or the many cases considered in the
appendfile
protocol. So I have some questions, where you might help me in the
"big
picture":
As stated, all transports can use a "transport_filter", which should be
able to processing your message on-the-fly, while writing it to the
mailbox file.
* How to enforce that a user has to authenticate him-/herself with a
password?
Use ACL to check if the user is authenticated. You should find it in
the
example config. Watch out for "authenticated = *".
* Where is a good point of "grabbing out" the password from the user
and how
to "carry" it to the point where the encryption happens?
The authenticators (authenticators section of the config) have the
password, and the server_condition does string expansion, so you can do
whatever you need there.
# example, *unchecked*, just served from memory, likely to be
# wrong
begin authenticators
plain:
driver = plain
server_advertise_condition = ${if def:tls_in_cipher}
server_condition = use $auth2 (user name) and $auth3
(password) in a creative way
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support
-
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3}
-
gnupg encrypted messages are welcome --- key ID: F69376CE
-
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Storing messages in Maildir format with symmetric encryption
On Wed, 23 Nov 2022, Dengler, Gabriel via Exim-users wrote: I want to store the incoming e-mails using the Maildir file format encrypted by using some symmetric encryption using the user's password Which user: the sender or the recipient ? -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Storing messages in Maildir format with symmetric encryption
On 23/11/2022 00:16, Dengler, Gabriel via Exim-users wrote: I want to store the incoming e-mails using the Maildir file format encrypted by using some symmetric encryption using the user's password It seems like a generally valuable concept - but I'd think that assymetric encryption of the data-at-rest is more appropriate than symmetric. The MDA (exim, here, receiving a message and delivering to file) shou be able to encrypt for the destination user but NOT decrypt. So it should have access to a public key and not a private key for the destination mailbox - and this is entirely separate from notions of SMTP authentication. Where to implement it in the code? Probably pretty late in the appendfile transport; about where it's doing actual writes to the file fd - and using a public key supplied via a transport option (which the config pulls from a database lookup using the username, or localpart, or whatever) and perhaps another giving the cipher scheme. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Storing messages in Maildir format with symmetric encryption
Hi Gabriel,
Dengler, Gabriel via Exim-users (Mi 23 Nov 2022 01:16:19
CET):
> I want to store the incoming e-mails using the Maildir file format encrypted
> by using some symmetric encryption using the user's password (e.g., AES). So
> in the end, Exim should write the encrypted files directly on the disk.
> Furthermore, it would be convenient if the actual password is solely
> persistent saved as a hash (for checking at authentication), the real
> password - and therefore the en-/decryption key - is only temporarily
> available during the login session.
Mybe I'm missing the point. The on-disk representation of the password
is a hash. That can't be used for symmetric encryption/decryption.
You want to "grab" the real password during user login, and save it
somewhere for later use as encryption/decryption key?
IMHO no source modification is necessary, $auth2, $auth3 (depending on
the AUTH scheme you use (needs to be PLAIN or LOGIN) contain the
password. You're free to save it whereever you want (using SQL, using
embedded Perl code, using any external command, using readsocket, …)
The encryption I'd do with a "transport_filter", which basically is
can be an "aes-pipe" or similiar.
> Therefore, I wanted to modify the Exim source code directly but was
> confronted with a large amount of code, e.g., the differentiation between
> the different transport types or the many cases considered in the appendfile
> protocol. So I have some questions, where you might help me in the "big
> picture":
As stated, all transports can use a "transport_filter", which should be
able to processing your message on-the-fly, while writing it to the
mailbox file.
> * How to enforce that a user has to authenticate him-/herself with a
> password?
Use ACL to check if the user is authenticated. You should find it in the
example config. Watch out for "authenticated = *".
> * Where is a good point of "grabbing out" the password from the user and how
> to "carry" it to the point where the encryption happens?
The authenticators (authenticators section of the config) have the
password, and the server_condition does string expansion, so you can do
whatever you need there.
# example, *unchecked*, just served from memory, likely to be
# wrong
begin authenticators
plain:
driver = plain
server_advertise_condition = ${if def:tls_in_cipher}
server_condition = use $auth2 (user name) and $auth3
(password) in a creative way
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
signature.asc
Description: PGP signature
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Storing messages in Maildir format with symmetric encryption
Hello everyone, I want to store the incoming e-mails using the Maildir file format encrypted by using some symmetric encryption using the user's password (e.g., AES). So in the end, Exim should write the encrypted files directly on the disk. Furthermore, it would be convenient if the actual password is solely persistent saved as a hash (for checking at authentication), the real password - and therefore the en-/decryption key - is only temporarily available during the login session. Therefore, I wanted to modify the Exim source code directly but was confronted with a large amount of code, e.g., the differentiation between the different transport types or the many cases considered in the appendfile protocol. So I have some questions, where you might help me in the "big picture": * How to enforce that a user has to authenticate him-/herself with a password? * Where is a good point of "grabbing out" the password from the user and how to "carry" it to the point where the encryption happens? * Where is a good point to add the encryption, e.g., by modifying the transport_instance block or directly before the file is written? Thanks for your help in advance! Best regards, Gabriel -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] debugging tls handshake failure
• Julian Bradfield via Exim-users [2022-11-23 18:25]: [...] > Kirill wrote: > > something in base64 which got saved as such:) I wonder why... > Asking I think for any information, as he sees something similar. Will > do. exactly: https://marc.info/?l=exim-users=166919251811778=2 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] debugging tls handshake failure
On Wed, Nov 23, 2022 at 06:25:29PM +, Julian Bradfield via Exim-users wrote: > >If the server in question is "london.jcbradfield.org", then another > >potential issue is a missing intermediate issuer certificate. Your > >certificate chain has only the leaf server certificate without the > >required "R3" intermediate issuer certificate. If using certbot, use > >"fullchain.pem" not "cert.pem" (or the equivalent for a different > >setup). > > Indeed. That's only been the case recently. For the last 20 years, > I've been presenting a self-signed certificate and had never noticed > any problems. A few days ago I happened to notice my bank getting > these TLS fatal alerts and then *not* falling through to plain text, > which most others do. So I started experimenting, but hadn't yet got > as far as giving the full chain (largely, I admit, because I don't > have certification internalized, and just follow recipes). So, have you tried configuring a complete certificate chain (ideally without the Android compatibility crutch). Did that make any difference? If you disable TLS 1.3, the alerts will be unencrypted in a packet capture, which you could then decode with "tshark" or wireshark without needing to resort to TLS key export. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] debugging tls handshake failure
Thank you for the various replies! Viktor wrote: >> 2022-11-21 21:10:42 TLS error on connection from >> r218.notifications.rbs.co.uk [130.248.154.218] (gnutls_handshake): A TLS >> fatal alert has been received. > >OpenSSL would usually log the alert number (and associated text string), >from which one could infer more information about what the remote client >is unhappy about. I'd hope that GnuTLS could also log this (or make the >alert info available to Exim to optionally log). Hopefully if I set it correctly, per Jeremy's reply below, it will. >That said, the most common issues that remote clients are unhappy about >are untrusted certificates and expired certificates. Perhaps you have a >Let's Encrypt certificate chain that includes a cross cert to the now >expired DST Root CA (for Android compatibility). You can configure >certbot et. al. to build a chain that skips the cross cert, expecting >clients to support the ISRG root. >If the server in question is "london.jcbradfield.org", then another >potential issue is a missing intermediate issuer certificate. Your >certificate chain has only the leaf server certificate without the >required "R3" intermediate issuer certificate. If using certbot, use >"fullchain.pem" not "cert.pem" (or the equivalent for a different >setup). Indeed. That's only been the case recently. For the last 20 years, I've been presenting a self-signed certificate and had never noticed any problems. A few days ago I happened to notice my bank getting these TLS fatal alerts and then *not* falling through to plain text, which most others do. So I started experimenting, but hadn't yet got as far as giving the full chain (largely, I admit, because I don't have certification internalized, and just follow recipes). Jeremy wrote: >The gnutls library helpfully (I infer) reads the environment at >process startup, too early for the config-driven addition of that >variable. Try having the thing firing off the exim process >adding to the environment instead. You'll need to add it >to keep_environment. Thanks! Should have thought of that. >Alternatively, since you know there's an alert involved, go down >the packet capture route. You'll need to >add_environment = SSLKEYLOGFILE=/sslkeys >and tell wireshark where to pick them up >(edit/pref/protocols/tls/ Master Secret Log filename) Ugh. Hopefully not... Presumably that would also have to be done by setting it before exim start. >Oh, yes, do ensure you're running with Exim's debug facilities >enabled. Commandline option or ACL modifier. Tried that. Debug +tls gave nothing useful. Kirill wrote: something in base64 which got saved as such:) (Anybody know a newsreader which supports following up to multiple article at once?) Asking I think for any information, as he sees something similar. Will do. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] debugging tls handshake failure
• Julian Bradfield via Exim-users [2022-11-21 21:41]: > I should like to know what's happening here: > > 2022-11-21 21:10:42 TLS error on connection from r218.notifications.rbs.co.uk > [130.248.154.218] (gnutls_handshake): A TLS fatal alert has been received. I see similar on a number of systems, and would be interested if you manage to find a solution. 2022-11-22 09:30:27 TLS error on connection from smtp-outgoing-1803.laposte.net [160.92.124.104] (gnutls_handshake): A TLS fatal alert has been received. 2022-11-22 09:41:06 TLS error on connection from smtp-outgoing-1601.laposte.net [160.92.124.96] (gnutls_handshake): A TLS fatal alert has been received. There are lots of them, and also from worldline.com and some other from time to time. The certificate on this particular host is issued by Buypass and entire chain is sent along. > However, I can't see how to get any more information. I've tried > setting > add_environment = GNUTLS_DEBUG_LEVEL=3 > in the exim4 config file, but it doesn't appear to do anything. > > Is there a way to get more information? -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
