Re: [TLS] SCSVs and SSLv3 fallback

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

On Sat, 06 Apr 2013 00:47:16 +0200, Trevor Perrin <[e-mail]> wrote:

> On Fri, Apr 5, 2013 at 3:19 PM, Paul Hoffman <[e-mail]>  
> wrote:
>> On Apr 5, 2013, at 3:11 PM, Trevor Perrin <[e-mail]> wrote:
>>> On Fri, Apr 5, 2013 at 2:30 PM, Nikos Mavrogiannopoulos  
>>> <[e-mail]> wrote:
>>>>
>>>> I wouldn't expect the problem of failed TLS connections due to middle
>>>> boxes or bad implementations to disappear by making a complex protocol
>>>> even more complex.
>>>
>>> If the problem is TLS-intolerant middleboxes, then allowing necessary
>>> handshake data to flow via SSLv3, using a mechanism that has worked
>>> for other extension data, should make the problem better.  No?
>>
>> No. You assume that the "TLS-intolerant middleboxes" actually  
>> understand real SSLv3, not some very limited and old picture of it. You  
>> might fix the problem for *some* middleboxes, at the cost of making the  
>> protocol even more fragile.
>
> Well, we're agreed this might fix the problem for some middleboxes. :-)
>
> The alternative, in the TLS-intolerant middlebox case, is... what,
> exactly?  Fail to connect?

Given that we don't know what these middleboxes react to, using SCSVs  
might work for some, but not others, because those could be checking for  
"known" cipher suites; some might even consider a unknown cipher suite to  
be an "attack". (Note: There are apparently middleboxes that do not allow  
TLS 1.1 or TLS 1.2 connections to be established, so if these middleboxes  
block on "unknown" protocol versions, I would not be surprised if some  
don't fail to pass "unknown" cipher suites, as well)

That the Renego SCSV *seem* to have worked, does not mean that a new SCSV  
will work equally well.

As Paul says, adding an SCSV system will add complexity, which might cause  
other problems, including differences between how implementations behave  
when seeing them. Example: There are a number of servers, F5 BigIP among  
them, that does not tolerate a combination of the Renego Information  
Extension and the Renego SCSV in the same handshake.

The danger is that by using an SCSV we might "fix" the problem for one  
group of users, and completely break SSL/TLS for another group of users,  
the size of which might conceivably be substantially larger than the other  
group, and there is no way to find out which it is going to be before the  
system is deployed.

For that matter, using an SCSV to indicate an extension and to bypass an  
interfering middlebox assumes that the middlebox will permit the  
associated handshake extension to be passed back to the client. I don't  
think that is a certainty, even if it seems to have worked for Renego (but  
worst case: that might be due to the middle boxes being updated to handle  
that particular extension, since it was a security protocol patch)

Bottom line: Assume that Murphy's Law applies; if something can be done  
wrong, then somebody will do it wrong. And in terms of these middleboxes,  
somebody have, but we don't know how many ways they have done it wrong.

-- 
Sincerely,
Yngve N. Pettersen

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