0

I'm looking at the technical docs for TLS 1.2 and it says it uses SHA (so hashing algorithms):

7.4.1.4.1. Signature Algorithms

But hashing just digests an input, to do things like user authentication.

TLS is supposed to provide "communications security." Is the info itself encrypted over with TLS? What encryption algorithm does it use?

Gilles 'SO- stop being evil'
  • 19,134
  • 4
  • 50
  • 92
calibro69
  • 3
  • 1

2 Answers2

3

You're looking at just one small part of the protocol. TLS, like any other communication protocol combines several cryptographic primitives to provide communications security. The algorithms used to secure the communication channel are described by a cipher suite, which combines a key exchange method (usually some form of Diffie-Hellman), an authentication method (usually a signature algorithm), a symmetric authenticated encryption method, and a hash algorithm which is used together with the authentication method. (This is the format of typical TLS 1.2 cipher suites. There are several variations which I won't go into here. TLS 1.3 uses the same building blocks but encodes the choice differently.)

The TLS protocol starts with a handshake where the client and the server set up a secure channel. For signature-based cipher suites, which is the most common case, the client and the server conduct a Diffie-Hellman key exchange, which lets them obtain a shared secret (the premaster secret). They then derive secret keys for authenticated encryption from this shared secret. An adversary observing the exchange cannot obtain the shared secret. However, an active man-in-the-middle can open a connection with the client and another one with the server. To prevent that, the server calculates a hash of the data exchanged during the handshake and signs it with its private key. The client calculates the hash of the data that it has exchanged and verifies the signature with the server's public key. If the two sides were talking to each other, they have seen the same data, so the signature is correct. If the two sides were each talking to a man-in-the-middle, they have seen different data, so the signature is incorrect and the client aborts the connection.

There are many different methods for authenticated encryption. In the old days (up to TLS 1.2), encryption was done with either a block cipher in CBC mode or the stream cipher RC4, and authentication of the data was done with HMAC. Since TLS 1.2, it is possible and preferred to use a proper AEAD construction such as a block cipher in GCM or CCM mode, or some other authenticated cipher (ChaCha20+Poly1305).

I've left out many parts and variants. For a more detailed overview of TLS, read How does SSL/TLS work? .

Gilles 'SO- stop being evil'
  • 19,134
  • 4
  • 50
  • 92
  • Thanks for the thorough response! The first paragraph really helped it "click" for me. – calibro69 May 08 '21 at 19:44
  • Nit: in 1.2 and earlier, server signature covers only server-KX message body and the two nonces, and is omitted if server-KX is not used e.g. plain-RSA-keytransport or 'anonymous'; client signature, if client auth is used which is rare, covers the transcript so far. In 1.3 both server (always, plain-RSA and anonymous are gone) and client (if used) sign the transcript so far. – dave_thompson_085 May 09 '21 at 02:32
1

The section you linked to is solely focused on signature algorithms. Either because they cannot do so efficiently, or cannot do so at all, digital signature algorithms do not generally operate on the full message being signed. Instead, most signature schemes use a hash function (e.g. something in the SHA family) to reduce the size of the input to something more manageable. Note that this is independent of whether the "message" being signed is private data or not, nor whether it is encrypted.

More specific to TLS, later in that section it calls out:

The semantics of this extension are somewhat complicated because the cipher suite indicates permissible signature algorithms but not hash algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules.

If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key exchange), it MUST send the signature_algorithms extension, listing the algorithms it is willing to accept.

If the client does not send the signature_algorithms extension, the server MUST do the following:

  • If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent the value {sha1,rsa}.

  • If the negotiated key exchange algorithm is one of (DHE_DSS, DH_DSS), behave as if the client had sent the value {sha1,dsa}.

  • If the negotiated key exchange algorithm is one of (ECDH_ECDSA, ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.

Note: this is a change from TLS 1.1 where there are no explicit
rules, but as a practical matter one can assume that the peer
supports MD5 and SHA-1.

This makes it clear that this extension is calling out hash algorithms in support of the more directly required key exchange parameters, the end result of which is a key that can be used to encrypt the communications to follow.

thesquaregroot
  • 1,249
  • 13
  • 23