tors jul 30 06:21:28 2015 GMT+0200 skrev Daniel Kahn Gillmor: > 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.
Only SNI and the server certificate are both sent in the clear, so it's no difference in security. -- Zash _______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
