How TLS provides identification, authentication, confidentiality, and integrity

During both client and server authentication there is a step that requires data to be encrypted with one of the keys in an asymmetric key pair and decrypted with the other key of the pair. A message digest is used to provide integrity.

For an overview of the steps involved in the TLS handshake, see An overview of the SSL/TLS handshake.

How TLS provides authentication

For server authentication, the client uses the server's public key to encrypt the data that is used to compute the secret key. The server can generate the secret key only if it can decrypt that data with the correct private key.

For client authentication, the server uses the public key in the client certificate to decrypt the data the client sends during step 5 of the handshake. The exchange of finished messages that are encrypted with the secret key (steps 7 and 8 in the overview) confirms that authentication is complete.

If any of the authentication steps fail, the handshake fails and the session terminates.

The exchange of digital certificates during the TLS handshake is part of the authentication process. For more information about how certificates provide protection against impersonation, refer to the related information. The certificates required are as follows, where CA X issues the certificate to the TLS client, and CA Y issues the certificate to the TLS server:

For server authentication only, the TLS server needs:
  • The personal certificate issued to the server by CA Y
  • The server's private key
and the TLS client needs:
  • The CA certificate for CA Y
If the TLS server requires client authentication, the server verifies the client's identity by verifying the client's digital certificate with the public key for the CA that issued the personal certificate to the client, in this case CA X. For both server and client authentication, the server needs:
  • The personal certificate issued to the server by CA Y
  • The server's private key
  • The CA certificate for CA X
and the client needs:
  • The personal certificate issued to the client by CA X
  • The client's private key
  • The CA certificate for CA Y

Both the TLS server and client might need other CA certificates to form a certificate chain to the root CA certificate. For more information about certificate chains, refer to the related information.

What happens during certificate verification

As noted in steps 3 and 6 of the overview, the TLS client verifies the server's certificate, and the TLS server verifies the client's certificate. There are four aspects to this verification:
  1. The digital signature is checked (see Digital signatures in SSL/TLS ).
  2. The certificate chain is checked; you should have intermediate CA certificates (see How certificate chains work ).
  3. The expiry and activation dates and the validity period are checked.
  4. The revocation status of the certificate is checked (see Working with revoked certificates ).

Secret key reset

During a TLS handshake a secret key is generated to encrypt data between the TLS client and server. The secret key is used in a mathematical formula that is applied to the data to transform plaintext into unreadable ciphertext, and ciphertext into plaintext.

The secret key is generated from the random text sent as part of the handshake and is used to encrypt plaintext into ciphertext. The secret key is also used in the MAC (Message Authentication Code) algorithm, which is used to determine whether a message has been altered. See Message digests and digital signatures for more information.

If the secret key is discovered, the plaintext of a message could be deciphered from the ciphertext, or the message digest could be calculated, allowing messages to be altered without detection. Even for a complex algorithm, the plaintext can eventually be discovered by applying every possible mathematical transformation to the ciphertext. To minimize the amount of data that can be deciphered or altered if the secret key is broken, the secret key can be renegotiated periodically. When the secret key has been renegotiated, the previous secret key can no longer be used to decrypt data encrypted with the new secret key.

How TLS provides confidentiality

TLS uses a combination of symmetric and asymmetric encryption to ensure message privacy. During the TLS handshake, the TLS client and server agree an encryption algorithm and a shared secret key to be used for one session only. All messages transmitted between the TLS client and server are encrypted using that algorithm and key, ensuring that the message remains private even if it is intercepted. Because TLS uses asymmetric encryption when transporting the shared secret key, there is no key distribution problem. For more information about encryption techniques, refer to Cryptography.

How TLS provides integrity

TLS provides data integrity by calculating a message digest. For more information, refer to Data integrity of messages.

Use of TLS does ensure data integrity, provided that the CipherSpec in your channel definition uses a hash algorithm as described in the table in Enabling CipherSpecs.

In particular, if data integrity is a concern, you should avoid choosing a CipherSpec whose hash algorithm is listed as "None". Use of MD5 is also strongly discouraged as this is now very old and no longer secure for most practical purposes.