Re: [TLS] SCSVs and SSLv3 fallback

["Yngve N. Pettersen" <[e-mail]>]

On Sat, 06 Apr 2013 18:59:06 +0200, Trevor Perrin <[e-mail]> wrote:

> 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.

In which case the client knows what the highest supported version, and the  
extension tolerance, for the server, as you say.

In any such case the client should IMNSHO assume that it is being  
subjected to a Man In the Middle attack, using a version rollback attack,  
and abort the connection. The client should in such a situation not permit  
itself to downgrade the security of the connection, which includes _not_  
attempting to set up the connection using SSL v3, or any TLS version lower  
than what was used the last time it had a successful connection.

That is BTW, the principle embedded in my version rollback removal draft  
<http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/>,  
which uses the server's support of the Renego extension as a proxy  
indication to determine full version and extension tolerance, and then use  
that information to assume that any failure to negotiate a connection,  
when signaling the client's highest supported version with full extension  
support in the handshake, means that the connection is being subjected to  
a version rollback attack, and terminate the connection attempt rather  
than roll back to an older version.

> 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.

It could be that they have been patched, if there was a problem, but the  
Renego issue was a high profile security issue, and its solution was one  
that was being deployed in all clients within a very short period of time.  
Failure to patch any troublesome middleboxes would have caused severe  
problems for users.

I doubt any such incentive to patch will be present for most other  
extensions of TLS, particularly if the usage of the SCSV depends on the  
server being known to support the new feature.

In other words: If there is a problem in this area, you should not assume  
that it will be quickly fixed, at least not before general server support  
is past 50% or an even higher percentage of high traffic sites use it,  
which might take several years to be achieved.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/