Re: [TLS] SCSVs and SSLv3 fallback

[Trevor Perrin <[e-mail]>]

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

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


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

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
:-)


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

I agree these middleboxes will not get fixed unless browsers and
servers break compatibility with them.

But TACK/CT/etc aren't needed for this:
 - Browsers could refuse SSLv3 fallback for sites that signal
renegotiation_info (Opera)
 - Browsers could be preloaded with lists of sites to refuse SSLv3 fallback for
 - Browsers could stop doing SSLv3 fallback entirely
 - Servers could refuse SSLv3 handshakes
 - Servers could refuse SSLv3 handshakes with a TLS_CAPABLE_SCSV (per
Eric and Adam)

They are mostly not doing so.

So in the face of the widespread middlebox "capitulation" which is a
current fact-of-life on the web, I question whether it's fair to force
the cost of breaking these middleboxes on young protocol efforts that
are already facing huge challenges to deployment.

I think doing so will simply make potential adopters unwilling to
experiment with these new enhancements, while having no impact on bad
middleboxes.


>> 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 means we will learn how successful this approach is in creating
TACK/CT/OCSP-must-staple connections through TLS-intolerant
middleboxes.


> 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

I support your rollback removal draft, and other methods.  But
unless/until they've been effective, I don't agree that new TLS
enhancements should be prevented from trying widely-deployed
compatibility fallbacks.


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

I support removal of all these fallbacks.  I hope we can get there.
But that is not the present reality TACK etc. have to contend with.

(And do note that TACK / CT / OCSP must-staple etc. are attempting to
address *existing* serious security vulnerabilities related to the CA
system, revocation, and so on.)


Trevor

[1] http://my.opera.com/securitygroup/blog/2011/05/19/renego-popular-unpatched-and-vulnerable-sites
[2] http://www.acsac.org/2012/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=163&type=4&OPENCONF=75799905b2bb79c800ddf7ade3caad00
[3] http://www.ietf.org/mail-archive/web/tls/current/msg08099.html
[4] http://www.ietf.org/mail-archive/web/tls/current/msg08861.html