9
$\begingroup$

After reading through https://datatracker.ietf.org/doc/html/draft-ietf-tls-downgrade-scsv-0, I could understand that this option is recommened for use when one has legacy SSL Servers which only support SSLv3.

But could not understand how this option helps even after reading couple of articles.

Can anyone help me in understanding this?

Improve this question
$\endgroup$
3
  • $\begingroup$ Could you clarify? You see why it's useful, but don't? $\endgroup$
    – otus
    Commented Oct 16, 2014 at 9:15
  • $\begingroup$ We know that TLS Fallback Signaling Cipher Suite Value (SCSV) is for Preventing Protocol Downgrade Attacks in general. And SSL Client enabled for this option sends value 0x56, 0x00 (TLS_FALLBACK_SCSV) in the request, further updated Server on seeing this value, rejects tje request if the highest protocol version supported by the server is higher than the version indicated in ClientHello.client_version. How does this help? $\endgroup$
    – dpb
    Commented Oct 16, 2014 at 9:18
  • $\begingroup$ Is it that, in absence of TLS_FALLBACK_SCSV, the Server would step by step downgrade the protocol ? .. So in essence, are we stopping all possibilities of protocol downgrades except one ? Only possibility of downgrade will be when the Server only supports 1 unique protocol version and Client starts negotiation with newer version. $\endgroup$
    – dpb
    Commented Oct 16, 2014 at 9:24

1 Answer 1

Reset to default
16
$\begingroup$

In a better world, TLS_FALLBACK_SCSV would not be necessary: SSL has been supporting downgrade-proof version negotiation since at least SSL 3.0, so a man in the middle should never be able to limit a connection to a version older than the mutually supported maximum.

However, out there are some broken servers that don't really support that kind of version negotiation; simply receiving an unknown, i.e. newer, version number, or unknown TLS extensions in a ClientHello causes them to crash. (Compliant servers would not crash, but simply tell the client that they want to use a lower version of the protocol; the connection would be established using the highest mutually supported version.)

Ideally, clients would simply refuse to connect to such broken servers; the problem would be swiftly fixed by the server vendor, and proper version negotiation would be restored.

As it turns out, quite a lot of server vendors or administrators couldn't be bothered to do that. Many browsers will now try to fix the problem on their end by connecting using a "legacy" ClientHello that doesn't trigger the buggy server behavior, which is essentially a second connection attempt using only SSL 3.0.

Unfortunately, this opens up an attack possibility for a man in the middle: By simply suppressing client connection attempts using new TLS versions to the server and simulating a buggy server response to the client, they force an SSL 3.0 connection attempt; the connection using SSL 3.0 will eventually be established, with the server thinking that the client uses a really old SSL library, and the client thinking that it is talking to a buggy SSL-3.0-only server.

Essentially, TLS_FALLBACK_SCSV allows clients to send a hidden version number in the downgraded connection attempt in a way that doesn't trigger the server bugs.

Informally, the conveyed message might be interpreted as follows:

Hey Server, even though I only claim to support TLS version $x$ in the version header, I actually support TLS versions up to $y$. If you support anything better than $x$, this means that there is something sinister going on here!

Practically, the backwards-compatible signal is a special "dummy" cipher suite that will be ignored by servers not supporting fallback prevention (whether they are broken SSL 3.0 or fairly recent TLS 1.2 servers).

Only servers supporting the draft specification will be able to interpret the signal and act accordingly; older servers will simply think that the client supports some additional cipher suites that they don't know about, and will continue the handshake as usual.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ As per OpenSSL documentation - DO NOT ENABLE THIS if your application attempts a normal handshake. Only use this in explicit fallback retries. $\endgroup$
    – dpb
    Commented Dec 10, 2014 at 8:31
  • $\begingroup$ the intrerpretec part isnt completely correct. it doesnt send a hidden version number but rather something that means "I downgraded" because the SCSV is only one value, which appears as a pseudo-ciphersuite. If a server now sees this message and it knows that it can do better, it can abort the connection @dpb exactly. because this is just an "I downgraded" message instead of a hidden ver-number. a TLS 1.3 server would kill a 1.2 connection with this thing inside. $\endgroup$
    – My1
    Commented Mar 21, 2018 at 12:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.