On Tue 2015-07-28 16:47:49 -0400, Hanno Böck wrote: > STARTTLS is risky, because there are mail apps out there that will by > default use "STARTTLS if available". That means they'll do STARTTLS, > but if the server doesn't support it they'll happily fall back to plain > text. It's on my "interesting project I could do at some point"-list to > do a check of famous mail client apps how they behave if you configure > a starttls connection and then suddenly disable support on the server. > If anyone wants to take that project feel free :-)
Note also that there are some ISPs that are deliberately doing STARTTLS stripping :( https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks that said, i think there is no difference in principle between the two approaches, as long as (a) the client side knows whether it should expect TLS and is vigilant about enforcing it (i'd love to see someone do Hanno's proposed experiment), and (b) the pre-STARTLS handshake leaks no additional metadata about the connection. This is true for IMAP and POP3, but arguably is not the case for either SMTP (the initial EHLO leaks its configured hostname) or for XMPP (the opening <stream:stream> element's "to" attribute leaks the desired xmpp domain, which might vary for connections to a multi-tenanted XMPP service). failures in (b)-style leakage for XMPP and SMTP could be mitigated by selecting a generic string for the relevant field that any server could accept as an "i'm about to go to TLS" message. I don't know if anything like that has been specified anywhere though. --dkg _______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
