If I read this correctly, starttls will fail due to the MITM attack. That is the client knows security has been compromised. Using SSL/TLS, the MITM can use SSL stripping. Since most Postifx conf use "may" for security, the message would go though unencrypted. Correct??? Is there something to enable for perfect forward security with starttls? ? Original Message ? From: s.arcus at open-t.co.uk Sent: August 21, 2017 3:07 PM To: dovecot at dovecot.org Reply-to: dovecot at dovecot.org Subject: Re: pop 110/995, imap 143/993 ? On 21/08/17 22:18, Joseph Tam wrote:> > Lest anyone think STARTTLS MITM doesn't happen, > >????? https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/ > > Not only for security, I prefer port 993/995 as it's just plain simpler > to initiate SSL from the get-go rather than to do some handshaking that > gets you to the same point.Frankly, after reading the above link and some more info on the internet on the subject, I am now wondering why do we bother at all with STARTTLS for imap, pop3 and even smtp (and by the way, port 465 for SMTP + SSL/TLS *is* indeed deprecated officially)? It would appear that STARTTLS is significantly more vulnerable to MITM attacks than plain SSL/TLS for all the above protocols. Is the slight extra convenience of opportunistic encryption really worth the substantial loss in security?
>> Lest anyone think STARTTLS MITM doesn't happen, >> >> https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/Right, the attack does happen, but it can be prevented by properly configuring the server and client.>> Not only for security, I prefer port 993/995 as it's just plain >> simpler to initiate SSL from the get-go rather than to do some >> handshaking that gets you to the same point.Simpler from a protocol perspective, yes, but not from a configuration perspective. A separate port requires more firewall configuration, requires listening on more one port if you need to accept both plain text and encrypted connections and requires that port to be allocated by IANA. Since dovecot, postfix and many other servers already support STARTTLS out of the box, sometimes with *less* configuration for it than the corresponding TLS-only protocol, I would certainly say it's not any simpler from a configuration perspective. That said, neither one is terribly difficult to configure.> Frankly, after reading the above link and some more info on the > internet on the subject, I am now wondering why do we bother at all > with STARTTLS for imap, pop3Certainly I would agree that it's not needed here, but I do not have a real issue with it, either.> and even smtp...because SMTP never worked over port 465. 465 is an alternate submission port (despite the name) and no MX server will connect to it. MX to MX traffic always has to happen on port 25 and so the only way to encrypt the stream is via STARTTLS.> (and by the way, port 465 > for SMTP + SSL/TLS *is* indeed deprecated officially)?Yes it is, and I think there was some confusion in this thread earlier about 993/995 not being official, they *are* official, but 465 is not which is probably what led to the confusion.> It would > appear that STARTTLS is significantly more vulnerable to MITM attacks > than plain SSL/TLS for all the above protocols. Is the slight extra > convenience of opportunistic encryption really worth the substantial > loss in security?I would not say significantly. If the client is configured to require encryption and to validate the resulting cert from the server then any MITM vulnerability of STARTTLS is fully mitigated. A MITM attack is only an issue if the client is configured for opportunistic encryption. Note that the server side should be configured to require encryption on as well, but the important thing is that the client requires it. I would like to point out that Thunderbird has not offered opportunistic encryption in its setup for a number of years now, and I think that other clients likely do not as well, so the MITM attack vector is only an issue on older clients that are likely insecure for other reasons as well. Even on those (older) clients you can likely configure them to require encryption, though.> If I read this correctly, starttls will fail due to the MITM attack. > That is the client knows security has been compromised.No, the attack vector is for a client that has encryption set to may. The MITM will either do a plain text connection to the server and strip the STARTTLS capability from the initial server response so that the client does not see it and degrades to plain text, or it will connect via STARTTLS but tunnel that connection to plain text itself, not offering STARTTLS to the client. In either case the client, if configured for opportunistic encryption will happily make the plain text connection to the MITM, or it will refuse the connection if it's configured to require encryption.> Using > SSL/TLS, the MITM can use SSL stripping. Since most Postifx conf use > "may" for security, the message would go though unencrypted. > Correct???Not really, no. Postfix is set to "may" by default, but this setting is only really used for MX to MX connections because of the number of MX servers that do not support TLS at all. If you look at master.cf at the commented submission service, which is what you would uncomment for submission, you will see that it is configured to not only require encryption but it also will refuse to offer or accept SASL AUTH on a plain text connection.> Is there something to enable for perfect forward security with > starttls?This is actually a client-side issue, but it is pretty much mitigated by the vast majority of modern clients by the fact that they no longer support opportunistic encryption. You either have to select plain text or encrypted, there is no, "encrypt if it is supported" setting any more. Peter
On 22.08.2017 03:56, Peter wrote:>>> Lest anyone think STARTTLS MITM doesn't happen, >>> >>> https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/ > Right, the attack does happen, but it can be prevented by properly > configuring the server and client.Dovecot, by default, requires STARTTLS before accepting plaintext authentication when SSL is configured and you are not connecting from localhost. You can verify this by telnetting to port 143 from somewhere else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you have enabled something like cram-md5. I think postfix, by default, will also prevent authentication without transport security. Also, you should probably using 587/tcp (submission) for sending mail, instead of 25. Some reputable ISPs prevent connecting to random MX servers to port 25 to make life harder for spambots. Aki
On 22/08/17 01:56, Peter wrote:>>> Lest anyone think STARTTLS MITM doesn't happen, >>> >>> https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/ > > Right, the attack does happen, but it can be prevented by properly > configuring the server and client. > >>> Not only for security, I prefer port 993/995 as it's just plain >>> simpler to initiate SSL from the get-go rather than to do some >>> handshaking that gets you to the same point. > > Simpler from a protocol perspective, yes, but not from a configuration > perspective. A separate port requires more firewall configuration, > requires listening on more one port if you need to accept both plain > text and encrypted connections and requires that port to be allocated by > IANA.Seriously? So one more port to allow through the firewall is somehow more complex than making sure the server and/or the client is configured to refuse falling back to plaintext communication - and testing various clients and server flavours to make absolutely sure that they do what they are supposed to be doing and don't fall for a MITM attack? At least with plain SSL/TLS ports, you know for sure that if you are connected, it is definitely encrypted. </snip>> >> It would >> appear that STARTTLS is significantly more vulnerable to MITM attacks >> than plain SSL/TLS for all the above protocols. Is the slight extra >> convenience of opportunistic encryption really worth the substantial >> loss in security? > > I would not say significantly. If the client is configured to require > encryption and to validate the resulting cert from the server then any > MITM vulnerability of STARTTLS is fully mitigated. A MITM attack is > only an issue if the client is configured for opportunistic encryption. > Note that the server side should be configured to require encryption on > as well, but the important thing is that the client requires it.Yes - and you have a lot of "if's" above - and that is exactly what makes it more vulnerable in practice - where you have to make absolutely sure that your particular version of your particular software definitely behaves like that - while with plain SSL/TLS it just works and there is no checking needed or "if's". In real life, that makes STARTTLS less secure.
On 08/22/2017 12:42 AM, Gary wrote:> If I read this correctly, starttls will fail due to the MITM attack. That > is the client knows security has been compromised. [...] Since most Postifx > conf use "may" for security, the message would go though unencrypted. Correct???Yup. FWIW, one doesn't need to be a large provider or do full traffic analysis to play this kind of game. A couple years back, my MUA failed to send e-mails while I was using the wifi of a Belgian camping ground. Looking into it, I found that SMTP was transparently redirected to an entirely different server - which did not offer the STARTTLS that I had my MUA insist on, either. Kind regards, -- Jochen Bern Systemingenieur Fon: +49 6151 9067-231 Fax: +49 6151 9067-290 E-Mail: jochen.bern at binect.de www.binect.de www.facebook.de/binect Binect ist ausgezeichnet: Sieger INNOVATIONSPREIS-IT 2017 | Das B?ro: Top 100 B?roprodukte 2017 Binect GmbH Robert-Koch-Stra?e 9, 64331 Weiterstadt, DE Gesch?ftsf?hrung: Dr. Frank Wermeyer, Nils Manegold Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264 MAX 21-Unternehmensgruppe ? Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der Binect GmbH versendete Mail ist sorgf?ltig erstellt worden, dennoch schlie?en wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH ausgelegt werden. Wir haben alle verkehrs?blichen Ma?nahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anh?nge an dieser Nachricht durchzuf?hren. Wir schlie?en, au?er f?r den Fall von Vorsatz oder grober Fahrl?ssigkeit, die Haftung f?r jeglichen Verlust oder Sch?den durch virenbefallene Software oder E-Mail aus. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly prohibited. All Binect GmbH emails are created thoroughly, nevertheless we do not accept any legal obligation for the information and wording contained herein. Binect GmbH has taken precautionary measures to reduce the risk of possible distribution of virus infected software or emails. However, we advise you to check attachments to this email for viruses. Except for cases of intent or gross negligence, we cannot accept any legal obligation for loss or damage by virus infected software. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20170822/2b213d56/attachment-0001.p7s>
On Mon, 21 Aug 2017, Gary wrote:> If I read this correctly, starttls will fail due to the MITM attack. That is > the client knows security has been compromised. Using SSL/TLS, the MITM can > use SSL stripping. Since most Postifx conf use "may" for security, the > message would go though unencrypted. Correct???Hi, many people think, the email is encrypted (secured), because it is sent through encrypted submission connection to client's smtp/submission server. I know some case, where one users sends credit card numbers over encrypted channel to SMTP server and he thinks the card numbers are protected! WRONG!!! The email is stored plain-text on the first server and then it can be sent to other few MX servers over plain-text connection. I.e. encrypted connection does not protect emails, but the authentication credentials. Users should know, that they have to encrypt the email itself, if they want protect it. Regards, Robert Wolf.
On Tue, 22 Aug 2017, Ivan Warren wrote:> Le 8/22/2017 ? 10:03 AM, Robert Wolf a ?crit?: > > > > WRONG!!! The email is stored plain-text on the first server and then it can > > be > > sent to other few MX servers over plain-text connection. I.e. encrypted > > connection does not protect emails, but the authentication credentials. > > > > > Indeed. > > Encrypted (SSL/TLS) SMTP/IMAP/POP3 sessions only server 1 purpose : To encrypt > authentication. Once a message is sent through a MTA, there is no guarantee of > privacy whatsoever. > > End to End privacy can only be achieved through actual e-mail signing and > encryption (PGP, S/MIME) (but only the message body is encrypted, not the > headers).Hello Ivan yes, headers are not encrypted in plain-text SMTP, the same way as TCP and IP and DNS Requests are not encrypted. One can only hide behind some anonymization system (TOR, Proxy, VPN for TCP, IP, DNS) or some non-presonal mail system to anonymize mail headers to not be able to connect real persones with mail sender/recipient. Regards, Robert.