Re: [TLS] SCSVs and SSLv3 fallback

[Trevor Perrin <[e-mail]>]

On Sat, Apr 6, 2013 at 5:14 AM, Yngve N. Pettersen <[e-mail]> wrote:
> On Sat, 06 Apr 2013 06:41:33 +0200, Trevor Perrin <[e-mail]> wrote:
>>
>> Suppose the SCSV is only allowed in the specific case of an SSLv3
>> fallback where an extension response is required or the connection
>> will fail (due to a requirement for TACK, CT, or OCSP).
>>
>> In this case, it can't break anything because the connection is
>> already going to be broken.  It's not guaranteed to work, but there's
>> evidence it might.
>>
>> Does that address this concern?
>
>
> No, it does not.
[...]
> we do not at present know if the SCSV
> variant will work in all cases.
[...]
> So, using an SCSV in the SSL v3 handshake do risk breaking a handshake that
> would otherwise have completed.

No, you missed my point.

I was proposing using SCSVs only in the case that an SSLv3 fallback is
necessary, and the browser *REQUIRES* some data from the server (TACK,
CT, OCSP), or the browser will refuse the connection.

Example:  Suppose a browser has an active TACK pin for a domain, but
sending a TLS ClientHello to that domain results in a TCP reset.

Since the TACK pin exists, the browser can assume it is not contacting
a TLS-intolerant server.  But a TLS-intolerant middlebox seems like a
possibility (though we still need more data on prevalence).  I believe
current browsers would want to try an SSLv3 fallback in this case, to
attempt to work around the interference.

However!  SSLv3 fallback is pointless here unless the browser has some
chance of signalling that it requires a tack, and receiving it.

I am proposing giving this a chance of working, by using the same SCSV
/ ServerHello Extension idiom that has worked for RFC 5746.

Of course, this might not work for any specific middlebox!  But if the
middlebox allows unknown ciphersuites and data at the end of the SSL
ServerHello, then it will.  And if the middlebox has been patched to
whitelist the specific 5746 SCSV and ServerHello extension, that
implies it could be upgraded for new uses of this idiom as well.


Trevor