Re: [TLS] SCSVs and SSLv3 fallback

[Trevor Perrin <[e-mail]>]

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.

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.


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.

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.


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