1

I understand the basic steps in the TLS handshake. My question is, where and how does one-way hashing fit into the steps below? Is it the session key that is hashed? Many texts mention that the original "message" is sent to check integrity, but what is this "message" exactly? I've looked at IBM's documentation on the topic, but am still confused as to how hashing fits into the steps below. Any examples, shown within the steps below would be appreciated.

  1. Browser connects to server secured with TLS (https)
  2. Browser requests server to identity itself
  3. Server sends a copy of its TLS Certificate that includes the server’s public key
  4. Browser checks the certificate root against a list of trusted CAs
  5. If the browser trusts the certificate, it creates, encrypts and sends back a symmetric session key using the server’s public key
  6. Server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session
  7. Server and Browser now encrypts all transmitted data with the session key
  • That description is for (plain)RSA keyexchange, which was common a decade ago but is now fairly rare and planned to be eliminated entirely by the next TLS version (1.3). See the ursine epic https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work especially under the heading Key Exchange for somewhat better details, although ECDHE has now become common. – dave_thompson_085 Jul 08 '18 at 12:50

2 Answers2

4

There are several uses of hash functions within the TLS handshake.

  • Creating the master secret from the information exchanged in the key exchanged, see TLS 1.2 section 8.1. This is not using the hash function directly but a PRF (pseudo-random function) is created using hashes (see section 5).
  • Similar the key material used for symmetric encryption and HMAC is derived by using the PRF, see section 6.3.
  • And the PRF is used again in the Finished message to make sure that the TLS handshake was not tampered with.
  • On various places digital signatures are done which involve hashes too. You'll find these for example to protect the ServerDHParams for DH key exchange (section 7.4.3).
  • Another signature is done in CertificateVerify for making sure that the client actually owns the private key for the client certificate.
  • And of course digital signatures are used in the certificates itself, thus hashes are involved when validating the certificate chain.

And once the TLS handshake is done you'll again find hash functions used for the HMAC or in AE to protect the (encrypted) application data against manipulations.

Community
  • 1
Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • 1
    Although any MAC can be characterized as a keyed hash, GCM and Poly1305 use polynomial algorithms and CCM uses a cipher based algorithm that are not actually hash algorithms. – dave_thompson_085 Jul 08 '18 at 12:53
1

The TLS1.2 RFC describes the TLS handshake protocol in section 7.4 .

As the RFC states, client and server agree upon a hash/signature algorithm, that is used throughout the protocol. The algorithm is used to ensure authenticity and integrity of messages in the handshake protocol.

An example usage of the hash/signing algorithm is the signing of the server certificate (section 7.4.2):

If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension.

Furthermore, hashing is used in the Finished message of the TLS Handshake to verify that the key exchange and authentication process were successful. Therefore, the a hash of the transcript of handshake messages between client and server is included in the Finished message and must be verified by the other side (section 7.4.2).

There are surely more use cases for hash functions in the TLS Handshake. They are all described in the RFC.

Community
  • 1
fgk
  • 176
  • 5