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

Does anyone on the list know of an example website where one can observe a potentially attackable TLS fallback?

Douglas

________________________________________
From: TLS [tls-bounces@ietf.org] On Behalf Of Marsh Ray [maray@microsoft.com]
Sent: December 5, 2013 09:05
To: Adam Langley; Manuel Pégourié-Gonnard
Cc: tls@ietf.org
Subject: Re: [TLS] An SCSV to stop TLS fallback.

What percentage of these client fallback operations that actual users browsers are doing in the real world are being triggered for reasons *other* than actual server implementation bugs? I imagine this could be a difficult thing to measure. But I can also imagine the obvious client heuristics (if it fails, try again) could easily be triggered by a busy server or simple packet loss. Couldn't this represent a full 1% of connections, especially now that so many users are on mobile devices?

So if a fallback situation was a slow-loading lousy page experience before, what's it going to be after legitimate servers implement this logic? Will servers actively *refuse* legitimate client's retry connections? If so, isn't this just taking an intermittent slow-failure situation and converting it to an even slower but guaranteed interop failure? If not, what good will downgrade protection logic be?

TLS 1.2 was designed to mitigate some serious potential attacks. BEAST demonstrated these attack vectors could be practical.

We need to recognize ad-hoc client fallback heuristic for what it is: a security vulnerability.

Therefore, clients MUST NOT auto-downgrade.

Therefore, broken servers and middleboxes need to clean up their act or GTFO.

This was always clear to anyone considering it from a protocol security angle. But the strong desire for interoperability and the absence of documented attacks in the 2000's made it hard to argue from principle.

Do we need an RFC a' la 6176 to give security-minded developers an explicit argument from authority?

- Marsh

P.S. I admit to being somewhat skeptical when RFC 6176 was being proposed. But I mentioned it in a meeting the other day and there were literally nods of understanding all around the table. Thanks!

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Adam Langley
Sent: Wednesday, December 4, 2013 11:20 AM
To: Manuel Pégourié-Gonnard
Cc: tls@ietf.org
Subject: Re: [TLS] An SCSV to stop TLS fallback.

On Wed, Dec 4, 2013 at 2:12 PM, Manuel Pégourié-Gonnard <mpg@elzevir.fr> wrote:
> Unless I'm mistaken, the problem TLS_FALLBACK_SCSV tries to adress is
> not servers that don't implement version negotiation correctly, but
> MITM actively doing a downgrade attack (and faulty middleboxes, which have the same effect).

I think the chain of sadness goes like this:

1) Some servers don't implement version negotiation correctly, or have other bugs that happen to be solved by using SSLv3.
2) Therefore some clients implement fallback
3) Therefore attackers can trigger fallback even with correct servers.

The MITM proxies that also had downgrade bugs caused issues with a Chrome experiment where we removed SSLv3 fallback for Google properties because it looked, to the client, like an attack. But, since it's a MITM proxy, it's an attack that the user has authorised.

Cheers

AGL
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls