SSL

Working Process

  • SSL protocol structure

    As shown in Figure 1, SSL functions between the application and transport layers. It secures data transmission for any application layer protocol based on TCP connections. SSL is divided into two layers: lower layer with the SSL record protocol and upper layer with the SSL handshake protocol, SSL change cipher spec protocol, and SSL alert protocol.

    Figure 1 SSL protocol stack
    • SSL record protocol: divides upper-layer information blocks into records, computes and adds message authentication codes (MACs), encrypts records, and sends them to the receiver.
    • SSL handshake protocol: negotiates a cipher suite including a symmetric encryption algorithm, a key exchange algorithm, and a MAC algorithm, exchanges a shared key securely between a server and a client, and authenticates the server and client. The client and server establish a session using the SSL handshake protocol to negotiate session parameters including the session identifier, peer certificate, cipher suite, and master secret.
    • SSL change cipher spec protocol: used by the client and server to send a ChangeCipherSpec message to notify the receiver that subsequent records will be protected under the newly negotiated cipher suite and key.
    • SSL alert protocol: allows one end to report alerts to the other. An alert message conveys the alert severity and description.

  • SSL handshake process

    The client and server negotiate session parameters during the SSL handshake process to establish a session. Session parameters mainly include the session identifier, peer certificate, cipher suite, and master secret. The master secret and cipher suite are used to compute a MAC and encrypt data to be transmitted in this session.

    The SSL handshake process varies according to the real-world situations. Handshake processes in three situations are described as follows:

    • SSL handshake process in which only the server is authenticated

      Figure 2 SSL handshake process in which only the server is authenticated
      As shown inFigure 2, only the SSL server, not the SSL client, needs to be authenticated. The SSL handshake process is as follows:
      1. The SSL client sends a ClientHello message specifying the supported SSL protocol version and cipher suite to the SSL server.
      2. The server responds with a ServerHello message containing the protocol version and cipher suite chosen from the choices offered by the client. If the server allows the client to reuse this session in the future, the server sends a ServerHello message carrying a session ID to the client.
      3. The server sends a Certificate message carrying its digital certificate with its public key to the client.
      4. The server sends a ServerHelloDone message, indicating that the SSL protocol version and cipher suite negotiation finishes and key information exchange starts.
      5. After verifying the digital certificate of the server, the client responds with a ClientKeyExchange message carrying a randomly generated key (called the master secret), which is encrypted using the public key of the server certificate.
      6. The client sends a ChangeCipherSpec message to notify the server that every subsequent message will be encrypted and a MAC will be computed based on the negotiated key and cipher suite.
      7. The client computes a hash for all the previous handshake messages except the ChangeCipherSpec message, uses the negotiated key and cipher suite to process the hash, and sends a Finished message containing the hash and MAC to the server. The server computes a hash in the same way, decrypts the received Finished message, and verifies the hash and MAC. If the verification succeeds, the key and cipher suite negotiation is successful.
      8. The server sends a ChangeCipherSpec message to notify the client that subsequent messages will be encrypted and a MAC will be computed based on the negotiated key and cipher suite.
      9. The server computes a hash for all the previous handshake messages, uses the negotiated key and cipher suite to process the hash, and sends a Finished message containing the hash and MAC to the client. The client computes a hash in the same way, decrypts the received Finished message, and verifies the hash and MAC. If the verification succeeds, the key and cipher suite negotiation is successful.

      After receiving the Finished message from the server, if the client successfully decrypts the message, the client checks whether the server is the owner of the digital certificate. Only the SSL server that has a specified private key can decrypt the ClientKeyExchange message to obtain the master secret. In this process, the client authenticates the server.

      • The ChangeCipherSpec message is based on the SSL change cipher spec protocol, and other messages exchanged in the handshake process are based on the SSL handshake protocol.
      • Computing a hash means that a hash algorithm (MD5 or SHA) is used to convert an arbitrary-length message into a fixed-length message.

    • SSL handshake verification

      Figure 3 SSL handshake verification
      Whether to authenticate the SSL client is determined by the SSL server. As shown by blue arrows in Figure 3, if the server needs to authenticate the client, the following operations are required in addition to the SSL handshake process in which the client authenticates the server:
      1. The server sends a CertificateRequest message to request the client to send its certificate to the server.
      2. The client sends a Certificate message carrying its certificate and public key to the server. After receiving the message, the server verifies the validity of the certificate.
      3. The client computes a hash for the master secret over handshake messages, encrypts the hash using its private key, and then sends a CertificateVerify message to the server.
      4. The server computes a hash for the master secret over handshake messages, decrypts the received CertificateVerify message using the public key in the client's certificate, and compares the decrypted result with the computed hash. If the two values are the same, client authentication succeeds.

    • SSL handshake process for resuming a session

      Figure 4 SSL handshake process for resuming a session
      Asymmetric cryptography is used to encrypt keys and authenticate peer identities when session parameters are being negotiated and a session is being established. The computation workload is heavy, consuming a lot of system resources. To simplify the SSL handshake process, SSL allows resumed sessions, as shown in Figure 4. The details are as follows:
      1. The client sends a ClientHello message. The session ID in this message is set to the ID of the session to be resumed.
      2. If the server allows this session to be resumed, it replies with a ServerHello message with the same session ID. After that, the client and server can use the key and cipher suite of the resumed session without additional negotiation.
      3. The client sends a ChangeCipherSpec message to notify the server that subsequent messages will be encrypted and a MAC will be computed based on the key and cipher suite negotiated for the original session.
      4. The client computes a hash over handshake messages, uses the key and cipher suite negotiated for the original session to process the hash, and then sends a Finished message to the server so that the server can check whether the key and cipher suite are correct.
      5. Similarly, the server sends a ChangeCipherSpec message to notify the client that subsequent messages will be encrypted and a MAC will be computed based on the key and cipher suite negotiated for the original session.
      6. The server computes a hash over handshake messages, uses the key and cipher suite negotiated for the original session to process the hash, and then sends a Finished message to the client so that the client can check whether the key and cipher suite are correct.

Security Mechanism

  • Connection privacy

    SSL uses symmetric cryptography to encrypt data to be transmitted and the key exchange algorithm Rivest Shamir and Adleman (RSA), which is one of asymmetric algorithms, to encrypt the key used by the symmetric cryptography.

    To ensure high security, do not use the RSA key pair whose length is less than 2048 digits.

  • Identity authentication

    Digital-signed certificates are used to authenticate a server and a client that attempt to communicate with each other. Authenticating the client identity is optional. The SSL server and client use the mechanism provided by the Public Key Infrastructure (PKI) to apply to a CA for a certificate.

  • Message integrity

    A keyed MAC is used to verify message integrity during transmission.

    A MAC algorithm computes a key and arbitrary-length data to output a MAC.

    • A message sender uses a MAC algorithm and a key to compute a MAC and adds it to the end of the message before sending the message to the receiver.
    • The receiver uses the same key and MAC algorithm to compute a MAC and compares the computed MAC with the MAC in the received message.

    If the two MACs are the same, the message has not been tampered during transmission. If the two MACs are different, the message has been tampered during transmission, and the receiver will discard this message.

Parent Topic: Understanding SSL
Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.