Re: [TLS] An SCSV to stop TLS fallback.

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

Adam, a few questions:

  - Are these implementations functioning as proxies or just inspecting the  
encrypted protocol data, without decrypting?

  - Does *any* of these implementations support the Renego patch? If they  
don't, then my suggestion for using the Renego extension support as a  
proxy for version tolerance might still work.

  - Do you know that none of them will not break due to an SCSV? If they  
are breaking due to expectations of what is supposed to be in the  
handshake, some of them they could very well break due to unexpected  
ciphersuites, as well. (while the Renego SCSV seem to have worked well, I  
don't think it can be relied on as a reliable indication as it is only  
used for SSL v3-only hellos, because there are servers that does not  
tolerate the Renego extension in combination with the Renego SCSV)

A pessimistic guess is that, as per Murhpy's Law, there will be both  
broken Renego patched implementations, and implementations that react to  
the proposed SCSV. As far as the SCSVs are concerned, how do you propose  
to handle those cases?

The questions then becomes: How many cases? And, are they are "too many"?  
(If the answer to the last one is "yes, always, one broken connection is  
one too many", then let's just park this entire discussion since it will  
never amount to anything. If there is no will to actually confront the bad  
implementations, the problem will never be fixed.)

Further thoughts:

Personally, I think a line needs to be drawn in the sand (or preferably  
concrete) and version rollback should be blocked in as many cases as  
possible, and as quickly as possibly (and needless to say, I think my  
proposal [1] will work better for both of those goals than SCSVs), and let  
the server, intermediary, and client side MITM vendors fix their products  
if they break other products, like browsers and other SSL/TLS clients.

The clients could include a message directly drawing the attention to (or  
better, putting the blame on) possible incompatible software in the system  
(particularly if other information can be used to make the case that it  
works from other network locations; diagnostic testing might also help).  
As long as incompatible implementations are allowed free reign, and IMO  
that is currently the case, then they will continue to be deployed and  
won't be retired. Only placing the user's security above user experience  
will help change the situation, because when placing the experience before  
security one only gets insecurity and vulnerabilities.

In my TLS Prober sample, 81.95% of servers are now Renego patched, of  
these 0.28% (~1200) are version and/or extension intolerant (mostly  
extension intolerant)

Since the TLS 1.3/2.0/4.0 discussion have raised its head again I'll also  
mention that 1.01% of renego patched servers are intolerant for Client  
hello version signaling v3.4,  and 8.34% are intolerant for Client Hello  
version signaling v4.1 (assumes a 3.1 record version).

The question needs to be asked: Will version rollback be acceptable in the  
next generation TLS client? Particularly considering the potential  
severity of the problems it is supposed to fix?

IMO the answer should be "No", and that means that the process of weeding  
out servers and intermediates that require clients to implement version  
rollback needs to be started now, and it also means that the next  
generation TLS will need to address the problem head on, and not back  
down. If that is not done, then we will be having this discussion again in  
(or for) another 15-20, maybe 30 years.


[1]  
http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/


On Tue, 26 Nov 2013 00:27:58 +0100, Adam Langley <[e-mail]> wrote:

> Sad as it is, in order to work on public Internet all browsers
> implement TLS fallback: in the event of a handshake failure they will
> retry the connection with a lesser SSL/TLS version.
>
> This means that an active attacker can disable AES-GCM support and,
> ultimately, ECDHE if they push the browser back to SSLv3. It would be
> good to finally do something about this.
>
> As I've mentioned before, with Chrome 31, we removed support for
> falling back to SSLv3 for Google sites. With Chrome 32, we were
> planning on removing all fallback for Google sites.
>
> Chrome 31 has been released and saw a fair amount of breakage due to
> an anti-virus that (in some configurations) acts as a local MITM and
> had bugs. Previously it was depending on browsers falling back to
> SSLv3 in order to function at all.
>
> I've since contacted a few other anti-virus and MITM vendors and asked
> them about the Chrome 32 change. A couple have informed me that they
> will break, at least in some configurations, if Chrome removes all
> fallback because they cannot do version negotiation correctly.
>
> I had expected the problems to come in the form of DPI devices sniping
> TLS 1.2 connections with injected RSTs rather than MITMs. These
> experiments in Chrome 31 and 32 were designed to probe how large a
> problem they were. The plan was always to gather information and then
> figure out a general solution that avoids having a special case for
> Google sites in Chrome.
>
> Since the MITMs are turning out to be the problem, I think the plan
> needs rethinking as the general solution need not break MITMs and thus
> could be deployed more easily.
>
> Thus I'd like to propose the design of an SCSV with which we can move  
> forward:
>
>   In the event that a client is making a fallback connection, it
> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the
> connection.
>
> This will not break MITMs because they will not process the SCSV. Any
> vendors that try to support the SCSV while having bugs that need
> fallback will find out when things stop working. But that, thankfully,
> will be their problem based on the Universal Rule of Users: the last
> thing that updated is to blame.
>
> Of course, this doesn't mean that firewalls won't turn out to be a
> problem but, at the moment, we can't even figure that out because of
> the the broken MITMs. We can't protect MITMed users, but it would be
> nice if they didn't ruin it for everyone else.
>
>
> Cheers
>
> AGL
> _______________________________________________
> 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/