Re: [TLS] SCSVs and SSLv3 fallback

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

[Resending since it was originally not sent to the group]

On Tue, 09 Apr 2013 01:21:56 +0200, Trevor Perrin <[e-mail]> wrote:

> On Mon, Apr 8, 2013 at 12:51 PM, Yngve N. Pettersen  
> <[e-mail]> wrote:
>> 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).
>
> Interesting!
>
> To make sure I understand:
>  - You're saying Opera 12.x will refuse to connect to RFC
> 5746-supporting sites if there's a TLS-intolerant middlebox in the
> way?

Opera will roll back all the way to SSL v3 when it does not know the
server's capabilities.

If it detect that the server support RFC 5746 it will, restart the
handshake using its highest enabled/supported version plus extensions. If
the handshake then fails it will report a handshake failure to the user;
it will not roll back.

Opera caches this result (the highest startable version) for 30 days.

>  - According to [1,2], about half of all TLS servers are RFC
> 5746-supporting?  Could I infer that Opera is providing
> rollback/MITM/middlebox protection to roughly half of all TLS
> connections made by its users?

The patch coverage in my sample according to my last numbers (from
December 24, 2012) is 75% of servers are patched for renego. That number
does not necessarily translate into the same percentage of connections or
actively used servers.

Essentially, the scheme establishes a connection with one attempt for
98.5% of servers; the remaining servers might require 1-4 more connections
to establish a connection or detect a renego "protected" rollback attempt
(the sequence for TLS 1.2, if enabled is TLS 1.2+ext->TLS 1.0+ext->TLS
1.0->SSLv3)

> If so, that's an impressive step, and great news!  Do you think other
> browsers will follow suit?

No idea, but I know Google is a bit concerned about those middleboxes.

>>> 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.
>
> Not sure that's true.  From Eric's draft [3]:
> """
> If the SCSV value is present and is not equal to
> ClientHello.client_version, then the server MUST terminate the
> handshake with a fatal "handshake_failure" alert.
> """
>
> From Adam's post [4]:
> """
> the semantics of TLS_CAPABLE_SCSV would be that servers would reject
> any SSLv3 handshakes that included this ciphersuite with a fatal
> error.
> """
>
> They have the client explicitly signal TLS capability via an SCSV,
> whereas you have the client infer the server's TLS capability from
> presence of renegotiation_info.

It seems I misremembered how their system worked, but I am still concerned
about how well it will scale as new versions of TLS are added.

However, I am also concerned about the timeframe for deploying their
system. we are currently 3 years into deploying a significant protocol
security fix (the renego patch), with 75% of servers patched, and a growth
of 8.5 percentage points in the preceeding 12 months, which indicates we
have at least 3 more years before closing in on 100% coverage (unless
clients start putting on the squeeze by removing padlocks, displaying
warnings messages, etc.)

After 4-5 years of Certificate Status Extension deployment, coverage is
still just 7.6%.  After 13 years the SSL v3-only server coverage is still
0.88%, but falling. How long do you think it will take to deploy an SCSV
based rollback protection? My guess: not less than it will take to get rid
of SSL v3.

> So their mechanism only works if both clients and servers support it.
> Your mechanism can be rolled out unilaterally in a browser, at the
> cost of a higher connection-failure rate (as you've said, ~1/700
> servers return renegotiation_info while being TLS intolerant; whether
> rejecting these servers is a "feature" or "bug" is another question
> :-)

I do think, if all clients were to deploy my method, that the actively
used servers with the problem would be gone in weeks; the middleboxes
would take longer, but probably not very long.


-- 
Sincerely,
Yngve N. Pettersen

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