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

[Marsh Ray <[e-mail]>]

From: TLS [mailto:[e-mail]] On Behalf Of Bodo Moeller
> As I've mentioned, the two options are not mutually exclusive, so I
> think you are constructing a false dichotomy.  We can start to use
> TLS_FALLBACK_SCSV ASAP to improve security *ASAP* for connections to
> *those* servers that do get updated (80% or even just 10% is better
> than 0% -- if only the most important servers that users trust get
> updated, that's something).

It seems to me like there are two scenarios:

Scenario 1.

A vulnerability in *handshake authentication* (stated as before)
is present only in downlevel but mitigated in the highest
protocol version that's common between the legitimate client
and legitimate server.

Thankfully, it's hard to come up with an example for this scenario.
But if it occurs, any protection deployed at the legitimate server
is likely to be rendered useless because the attacker could
impersonate the legitimate server to the legitimate client.
Obviously the attacker would opt not to implement the downgrade
protections in his evil server!

Scenario B.

A vulnerability in *record layer authentication or encryption*
present only in client fallback TLS but mitigated in the highest
protocol version that's common between the legitimate client and
legitimate server.

An example of this scenario is the chosen plaintext attacks on
CBC block padding (e.g., BEAST) that was fixed in 1.1 by sending
an explicit IV. Previous attempts at mitigation had been coded
in OpenSSL years ago for TLS 1.0, but were disabled by default
for compatibility reasons. If an attacker provoked a browser to
fall back to TLS 1.0, he could (in theory) effectively disable
some mitigations in place to prevent this attack.

Protecting against (B) seems like it could be useful, unless it
measurably increases the rate of failed handshakes and delays
in non-attack situations.

http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01#section-3
Server behavior:
> If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
> highest protocol version supported by the server is higher than
> the version indicated in ClientHello.client_version, the server
> MUST respond with a inappropriate_fallback alert.

Say the server implements TLS 1.0 reasonably well, but believes
it supports 1.2. Unfortuantely, it will successfully negotiate
the use of 1.2 but then crashes and hang the socket open until
the client gives up.

RFC 5246 TLS 1.2 says:

http://tools.ietf.org/html/rfc5246#appendix-E
> TLS clients that wish to negotiate with older servers MAY send any
> value {03,XX} as the record layer version number.  Typical values
> would be {03,00}, the lowest version number supported by the client,
> and the value of ClientHello.client_version.

and

http://tools.ietf.org/html/rfc5246#section-7.4.1.2
> ClientHello.client_version
>    The version of the TLS protocol by which the client wishes to
>    communicate during this session.  This SHOULD be the latest
>    (highest valued) version supported by the client.

That sounds to me like the client MAY retry with record.version={3,0},
but it SHOULD still send ClientHello.client_version={3,3}.

So for clients that follow RFC 5246 recommendation, what is gained by
sending TLS_FALLBACK_SCSV? Why couldn't we instead recommend that
servers reject with *any* connection attempt for which
ClientHello.client_version < "highest version supported by the server" ?

But draft-bmoeller-tls-downgrade-scsv-01 suggests that clients in the process
of auto-downgrading behave otherwise:

http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01#section-4
Client behavior:
> If a client sends a *ClientHello.client_version* containing a lower
> value than the latest (highest-valued) version supported by the
> client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value
> in ClientHello.cipher_suites.

I.e., clients are *lying* about the actual highest version of the
protocol they support and they're doing so against the
SHOULD-level recommendation of the TLS RFC's.

The weakness I see is in draft-bmoeller-tls-downgrade-scsv-01
is that servers are not actually in a position to know the highest
protocol version that the client supports.

Thus a server would have to refuse *any* connection for which the
client sends TLS_FALLBACK_SCSV set. Why? Because the server must
consider the unfortunate possibility that some infernal middlebox
is intolerant to TLS 1.3! (or any future version that the client
may support).

The attacker laughs his ass off as browsers and servers are stuck
in a tangled web of little lies mostly built on good intentions.

Sending a flag to say "oh by the way I'm lying about my highest
version" is not a complete fix.

I only see one correct solution: ripping out this auto-downgrade
logic from clients and putting these broken servers and middleboxes
on notice that they have no place on a secure network.

Only then will environment begin to heal and as it does page load
times would become a bit faster.

- Marsh