Re: [TLS] SCSVs and SSLv3 fallback

[Geoffrey Keating <[e-mail]>]

Trevor Perrin <[e-mail]> writes:

> Hi,
> 
> I've heard (anecdotally) that HTTPS between browsers and webservers
> who are both TLS-capable sometimes results in SSLv3 connections.
> Presumably this is due to firewall interference with the TLS
> handshake, causing browsers to retry an SSLv3 handshake.

The name of one firewall which is confirmed to do this would make it a
lot more convincing...  It's likely that some TLS connections failed
due to packet loss or a busy server and so the 'fallback' was a
mistake.

> I believe TLS Extensions are generally not sent in the SSLv3
> ClientHello (?).  This isn't a major problem for TLS Extensions as
> optimizations (e.g. session tickets or OCSP stapling).
> 
> However, there are proposals that *require* a TLS Extension response,
> for security:
>  - TACK's "TackExtension" [1]
>  - Certificate Transparency's "SignedCertificateTimestampList" [2]
>  - OCSP stapling in the presence of an X.509 "must-staple" extension [3]
> 
> How should these work in the case of a network-triggered SSLv3 fallback?

I would phrase this as "how should these work when under attack and
the attacker is blocking extensions".

In the case of TACK, I think it should work by saying that if
you've previously negotiated TACK, therefore the server must
previously have supported at least TLSv1+extensions, so you SHOULD NOT
fall back to a SSLv3 ClientHello for that server, and if you do, you
MUST continue to apply any active pin.

> One proposal would note that some browsers do, I think, send the
> RFC5746 TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite in an SSLv3
> ClientHello, and receive a "renegotiation_info" ServerHello extension
> in return.

I don't believe sending the ServerHello extension is the important
part of that protocol, the key part is that the server rejects
any renegotiation where the ciphersuite is included.

> So there's evidence that this idiom of a "special ciphersuite value"
> in an SSLv3 ClientHello, and a TLS Extension in ServerHello, is
> "compatible-enough" with the horrible middleboxes triggering these
> fallbacks.

For counter-evidence, see
<https://bugzilla.mozilla.org/show_bug.cgi?id=672749>.