2

TLS negotiates a ciphersuite and TLS version to use during handshake. It confirms the handshake was not tampered with and the ciphersuite and TLS version were not downgraded using the negotiated ciphers, as explained here. However, this verification relies on the ciphers negotiated on the handshake, so if the ciphers the attacker chosen were sufficiently weak to break quickly, he may be able to send these confirmation messages as well.

My question is, why doesn't the server use its private key to sign its ciphersuite and TLS version (and timestamp of validUntil) so the client can detect downgrade attacks? While the client does not have the public key at the time, the signature can be kept by the client until the certificate is validated and then verified. Why is this not done by the TLS protocol?

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
Peter Harmann
  • 7,778
  • 5
  • 20
  • 28
  • 4
    This is because at the time when server sends its own list of ciphers, server is not yet authenticated and its certificate is not yet validated. As the result, client doesn't have reliable trusted public key to verify signature. – Crypt32 Apr 27 '18 at 13:17
  • @Crypt32 well thank you for actually answering, unlike some people marking this duplicate when it is not. But can't it send the signature anyway and verify it after the certificate is validated? Sounds better then truating the crypto that might have been downgraded. – Peter Harmann Apr 27 '18 at 14:54
  • 1
    @PeterHarmann: I was the one who marked your question as duplicate before you've incorporated the information from the question I've pointed out as answer into your own question. Anyway, if you read the other answer you might notice that *"The only way ... would be to __force the client and server to use a cipher suite that is so weak__ that the attacker can totally break it right away"*. Thus, both client and server would need to support such a weak cipher in the first place which means that both are insecure anyway. And as Crypt32 pointed out - there would also be no way to sign the ciphers. – Steffen Ullrich Apr 28 '18 at 13:31
  • @SteffenUllrich Wait a second, what? The server does have the private key, it can sign it right? I am talking about the server signing, not the client. – Peter Harmann Apr 28 '18 at 16:50
  • @SteffenUllrich And I read that part in the answer, but I was expecting an answer here of the style: It would be slower, it would increase the size of handshake, the key shouldn't be reused for both signing and encrypting etc. I just did assume it is still better to have no way of exploiting than having an unlikely way to exploit. – Peter Harmann Apr 28 '18 at 16:56
  • 1
    TLS 1.3, which is the first opportunity to make a breaking change like this, effectively proposes to do so (at least in most cases) by making server's CertVerify cover the whole transcript (like client's rarely used one already does). But 1.3 has been in draft four years without reaching consensus, and even assuming it does get approved sometime, history indicates it will take several years to a decade for implementations to reach wide usage. – dave_thompson_085 Apr 29 '18 at 08:57
  • @dave_thompson_085 So I understand it is actually reasonable, just did not make it into the standard yet, because it is a breaking change yes? If that is it, it is the kind of answer I was looking for. If you write it as an answer, I will accept it. – Peter Harmann Apr 29 '18 at 13:09

1 Answers1

3

The server does sign the ciphersuite. The whole protocol negotiation (covering the ciphersuite, the keys, etc.) is signed. That's the last thing in the handshake: the Finished message. See What stops an attacker from tampering with data sent during the SSL/TLS handshake? and How does SSL/TLS work? for more details.

You note:

this verification relies on the ciphers negotiated on the handshake, so if the ciphers the attacker chosen were sufficiently weak to break quickly, he may be able to send these confirmation messages as well.

and ask:

why doesn't the server use its private key to sign its ciphersuite and TLS version (and timestamp of validUntil) so the client can detect downgrade attacks?

Once again, the server does use its private key to sign the ciphersuite and the client does verify it. It happens at the end of the handshake because it can't happen until the client and the server have agreed on what the server's key is and why it should be trusted.

You're worried about an attacker convincing the client to use a weak ciphersuite for which they can forge a signature. Well, there are two cases.

  • The client knows that the ciphersuite is weak and refuses to use it. Then there's no problem. The client will close the connection.
  • The client doesn't know that the ciphersuite is weak. Then there's nothing to do. The whole conversation happens with the attacker. The legitimate server is not involved at all. There's no way the legitimate server can protect the client against an attack when the legitimate server does not even participate in the protocol.
Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
  • I am very confused. As I understand TLS, the client and server establish a shared secret to be used with the negotiated ciphersuit. Then the standard channel is used to confirm the ciphersuit and version, using the negotiated cipher and shared secret. I was asking why the RSA/EC private key is not used instead. The reasoning for me is, that some ciphers are very old weak, such as 3DES. Therefore, using RSA signature would be safer (if RSA is broken, it does not matter anyway, but if 3DES is, most servers would not pick it without downgrade attack). Am I wrong? Is the RSA key used directly? – Peter Harmann Apr 28 '18 at 23:02
  • 1
    @PeterHarmann: Although moderately old, 3DES is not weak in itself, although it is inefficient and unfashionable; 3DES-CBC (as used in SSL/TLS) is at risk for 'birthday' repetition after about 32 billion bytes, and the encrypted portion of the handshake is about 40 bytes, which is reliably quite a bit less than 32 billion. But Finished doesn't actually depend on the data cipher for security anyway. – dave_thompson_085 Apr 29 '18 at 08:59