Re: [TLS] SCSVs and SSLv3 fallback

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

On Mon, 08 Apr 2013 20:34:59 +0200, Trevor Perrin <[e-mail]> wrote:

> Hi Yngve,
>
> Thanks for the reference to your rollback prevention draft [1].  I've
> also seen the Eric Rescorla and Adam Langley proposals [2,3].
>
> These all seem practical ways to enable a TLS-capable party suffering
> an SSLv3 fallback to detect that the other party is TLS-capable.
>
> I'd love to see any of them deployed, so such connections could be
> rejected.  Browser makers could aso preload their browser with a list
> of TLS-capable sites (such as their own), and disable SSLv3 fallback
> for them.

Opera 12.x already deploy the one I've described (It was also deployed in  
Opera 10.50 to 11.0x).

There are basically two main categories of Renego patched servers causing  
issues, one does not tolerate the Server Name extension (e.g  
<https://secure.avis.com>), the other does not tolerate the Certificate  
Status extension (e.g. <https://www.bigskybank.com/> which is part of a  
cluster of 90+ servers on the same /24 segment)

> Hopefully these actions would force TLS-intolerant middleboxes to be
> replaced, so browsers could stop having to work-around them and this
> problem would disappear.

I hope my proposal might manage that, but I don't think EKR and Adam's  
proposals will, since they try to work around the broken servers and  
middleboxes, and do not confront them.

Still, there have been little activity on this topic in the WG, no matter  
which direction one would like to take on this topic.

> However!  Until this happens, I  think new TLS enhancements must
> unfortunately try to be compatible with browser workaround behavior.
>
> So I'm proposing TACK (and similar proposals) could make use of SSLv3
> SCSVS in a narrowly-scoped context:
>  - Only in case of SSLv3 fallback
>  - Only when additional data is required from the server or the
> connection will fail
>
> In the long-term, if TLS-intolerant middleboxes can be eliminated to
> the point that browsers *don't* need to support them, this case will
> cease to exist.  At that point this mechanism will be unused and
> unneeded.

The problem, from my point of view, is that as long as standards and  
clients *capitulates* to (or maybe a better description is: allows  
themselves to be *blackmailed* by) those middleboxes (and servers), they  
will *never* go away, because the visited websites do not break; "if it  
ain't broken, don't fix it". (I suspect some would make references to  
"Danegeld" in similar situations.)

Case in point: Servers are still version intolerant 13+ years after TLS  
1.0 started being deployed, because clients allowed themselves to fall  
back to SSL v3. The situation is even worse regarding extension  
intolerance.

Even with the reminder about tolerance in RFC 5746 0.15% of renego patched  
servers are extension (88%) and/or version intolerant (24%) in the TLS 1.0  
to TLS 1.2 range, and the reason they are still around is that the other  
clients have not enforced a no-rollback policy for renego patched servers.  
Overall, 14.7% are intolerant for those in the 3.x and/or 4.x range.

> As you and Nikos have pointed out, there is no guarantee that this
> mechanism will always work.  However if deployed, we could gather
> statistics on it.

Which will not mean that the problem will get fixed. It will just mean  
that clients implement more and  more complex recovery methods in an  
attempt to get past what they think breaks the connection in those cases.

Quite the opposite of what my "removal" draft attempt to accomplish

Also: How long until a serious security vulnerability rears its head out  
of that mess of workarounds and iterative fallbacks?

>
> Anyways, I'd love to hear a better proposal for handling this
> difficult and unfortunate case.  But it's seeming like the best option
> for TACK (which is my immediate concern) would be to specify an SCSV
> mechanism.
>
> Does that seem reasonable?
>
>
> Trevor
>
>
> [1]  
> http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/
> [2] http://www.ietf.org/mail-archive/web/tls/current/msg08099.html
> [3] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html
>
>
> On Sat, Apr 6, 2013 at 12:04 PM, Yngve N. Pettersen  
> <[e-mail]> wrote:
>> 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/
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls


-- 
Sincerely,
Yngve N. Pettersen

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