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

Kim Alvefur zash at zash.se
Thu Jul 30 12:17:16 CEST 2015

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.


More information about the Ach mailing list