2

On this page, it says the first thing sent is the SSL settings, such as version, and cipher settings.

If the attacker, say, wanted to change the encryption method used, what makes this not possible?

Phoenix Logan
  • 482
  • 2
  • 13
  • 1
    You are thinking that a MitM could skew the cipher settings to the lowest possible in order to increase the possibility of exploiting weaknesses? That's why it's important to control which SSL settings are permitted on the client and server. Dump the old ones and stick to the more secure ones. Does that make sense as an answer? – schroeder Jun 20 '14 at 15:47
  • Yes, exactly. So there is nothing preventing this? – Phoenix Logan Jun 20 '14 at 15:47

1 Answers1

8

The cornerstone of the security against such tampering lies in the Finished messages. At the end of the handshake, client and server send to each other these messages, whose contents are a hash of the contents of all previously exchanged handshake messages. If an attacker alters anything in one of these messages, then the handshake messages, as seen by the client, won't match what the server saw, and the Finished message contents will differ. The attacker cannot reliably alter the contents of the Finished messages on the fly because they are sent after the switch to the newly negotiated cryptographic algorithm -- so they are encrypted and protected against alterations.

The only way for the attacker to pull off such an attack 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, and thus alter the Finished messages to match his previous alterations. But decent SSL implementation don't support cipher suites which are that weak (there used to be "export cipher suites" limited to 40-bit keys, but they are no longer supported by existing libraries).

For more on SSL, read this.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 1
    +1 As for "decent SSL implementations", recently, I had to configure a modern load balancer to NOT use very broken ciphers. It's not a given than new configs are 'decent'. – schroeder Jun 20 '14 at 15:51
  • "...of all previously exchanged handshake messages." - The Change Cipher Spec (CCS) message is not covered in the hash. Its not used to derive key bits either. –  Jun 20 '14 at 16:15
  • @jww: well, technically, the `Change Cipher Spec` message is not a handshake message; it is a "change cipher spec" message. Not the same record type (there are four record types: handshake, change cipher spec, alert and application data). The hash is for the _contents_ of the handshake messages, and does not include the record headers either. The `Change Cipher Spec` message is best thought of as a kind of record-level hint rather than an actual "message". – Thomas Pornin Jun 20 '14 at 16:55
  • @jww+ CCS can only be deleted which gives denial which is trivial anyway, or inserted/moved which _should_ be rejected but sometimes isn't e.g. http://www.openssl.org/news/secadv_20140605.txt . – dave_thompson_085 Jul 13 '16 at 01:47