[Ach] implicit TLS vs. STARTTLS [was: Re: Fwd: E-Mail Protocol Security Measurements]

[Kim Alvefur]

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