No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Configuration Guide - Security

CloudEngine 8800, 7800, 6800, and 5800 V200R005C10

This document describes the configurations of Security, including ACL, local attack defense, MFF, attack defense, traffic suppression and storm control, ARP security, Port security, DHCP snooping, ND snooping, PPPoE+, IPSG, SAVI, separating the management plane from the service plane, security risks.
Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Implementation

Implementation

SSL implementation consists of two stages: the handshake process and data transmission process.

  • Handshake Process: authenticates the server and client and negotiates a key and a cipher suite including an encryption algorithm, a key exchange algorithm, and a MAC algorithm. The handshake process must be completed before data transmission starts.
  • Data Transmission Process: uses the negotiated key and cipher suite to divide data into a series of protected records and transmits the records.

Handshake Process

A client and a server set up a session using the SSL Handshake Protocol to authenticate the identities of the two parties and negotiate the key and cipher suite. Figure 16-2 shows the SSL handshake process. The Change Cipher Spec 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, and are SSL handshake messages.

NOTE:

It is optional for an SSL server to authenticate a client's identity. That is, Steps 4, 6, and 8 in Figure 16-2 are optional.

Figure 16-2 SSL handshake process
  1. An SSL client sends a Client Hello message to an SSL server to start the handshake process. The Client Hello message carries information about the SSL version and cipher suite supported by the client.
  2. The server replies to the client with a Server Hello message, carrying the specified version and cipher suite. If the server allows the client to reuse the session in subsequent communication, the server allocates a session ID for the session.
  3. The server sends a digital certificate carrying its public key information to the client, allowing the client to authenticate server identity.
  4. (Optional) The server requests that the client provide a certificate, so that the server can authenticate the client identity.
  5. The server sends a Server Hello Done message to the client, indicating that the SSL protocol version and cipher suite negotiation finishes and key exchange starts.
  6. (Optional) The client sends its certificate to the server.
  7. After verifying the validity of the digital certificate of the server, the client responds with a Client Key Exchange message carrying a randomly generated key, which is encrypted using the public key in the server's certificate.

    The randomly generated key, which is called the premaster secret, is used to calculate the symmetric key and MAC key but cannot be used to encrypt data or calculate the MAC value. The client and server use the premaster secret to calculate the same master secret and then use the master secret to calculate the symmetric key and MAC key. Therefore, the premaster secret is of great importance in calculating the symmetric key and MAC key.

  8. (Optional) The client sends a Certificate Verify message to the client, so that the server can authenticate the client identity.

    The client computes the hash value using handshake messages and the master secret, encrypts the hash value using its private key, and then sends the hash value to the server through the Certificate Verify message. The server computes the hash value using handshake messages and the master secret, decrypts the received Certificate Verify message using the public key in the client's certificate, and then compares the decrypted value with the hash value. If the two values are the same, the client passes identity authentication.

  9. The client sends a Change Cipher Spec message to notify the server that encryption and MAC computation of every subsequent message will be performed based on the key generated using the master secret and cipher suite.
  10. The client sends a Finished message to request that the server verify security of the handshake process.

    The client computes a hash value for the exchanged handshake messages, uses the negotiated key and cipher suite to process the hash value (for example, computing, adding MAC, and encrypting the value), and sends a Finished message containing the processed hash value to the server. The server computes a hash value in the same way, decrypts the received Finished message, and compares the two values. If they are the same, MAC verification succeeds and the negotiation of key and cipher suite is successful.

    NOTE:

    A hash value is a fixed-length message that is converted from an arbitrary-length message by using a hash algorithm (MD5 or SHA).

  11. The server sends a Change Cipher Spec message to notify the client that encryption and MAC computation of every subsequent message will be performed based on the key generated using the master secret and cipher suite.
  12. The server sends a Finished message to request that the client verify security of the handshake process.

    The server computes a hash value for the exchanged handshake messages, uses the negotiated key and cipher suite to process the hash value (for example, computing, adding MAC, and encrypting the value), and sends a Finished message containing the processed hash value to the client. The client computes a hash value in the same way, decrypts the received Finished message, and compares the two values. If they are the same, MAC verification succeeds and the negotiation of key and cipher suite is successful.

The SSL client completes authenticating the server identity after the handshake succeeds. Only after the SSL server with a private key decrypts the premaster secret from the Client Key Exchange message, the subsequent handshake process can be successful.

Asymmetric cryptography is used to encrypt keys and authenticate peers during the handshake process between the client and server. The computation consumes considerable system resources. To simplify the SSL handshake process, SSL supports resuming of a negotiated session, as shown in Figure 16-3. The details are as follows:

Figure 16-3 SSL handshake process when session resuming is supported
  1. The client sends a Client Hello 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 Server Hello message carrying the same session ID. The client and server can subsequently use the key and cipher suite of the resumed session without additional negotiation.
  3. The client sends a Change Cipher Spec message to notify the server that encryption and MAC computation of every subsequent message will be performed based on the key and cipher suite of the original session.
  4. The client computes a hash value for the exchanged handshake messages, uses the negotiated key and cipher suite of the original session to process the hash value, 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 Change Cipher Spec message to notify the client that encryption and MAC computation of every subsequent message will be performed based on the key and cipher suite of the original session.
  6. The server computes a hash value for the exchanged handshake messages, uses the negotiated key and cipher suite for the original session to process the hash value, and then sends a Finished message to the client so that the client can check whether the key and cipher suite are correct.

Data Transmission Process

The client and server can exchange application layer data after the handshake process completes. Data transmission is implemented using the SSL record protocol during the process.

Figure 16-4 illustrates the data transmission process. The device uses the SSL record protocol to perform the following operations:
  • Receive application layer data
  • Divide the data into manageable blocks
  • Compress the data (optional)
  • Add a MAC
  • Encrypt the data using an encryption algorithm
  • Add an SSL record header to the packet
After receiving application layer data, the device performs the operations in the following sequence: decapsulation, verification, decompression, and reassembling.
Figure 16-4 Data transmission process
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100074765

Views: 18339

Downloads: 60

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next