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

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
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).
Principles

Principles

This section describes the security mechanisms, protocol structure, and implementation of SSL.

Security Mechanism

The SSL protocol provides three security mechanisms as follows:
  • Identity Authentication: This mechanism uses digital-signed certificates to authenticate a server and a client that attempt to communicate with each other. Client identity authentication is optional.
  • Data Confidentiality: This mechanism uses symmetric cryptography to encrypt data to be transmitted.
  • Message Integrity Check: This mechanism uses a message authentication code (MAC) algorithm to verify message integrity during the transmission.
Identity Authentication

A client must validate the SSL server to ensure that confidential information will not be intercepted. SSL uses a digital signature to authenticate the identities of two communicating parties.

A digital signature can be calculated using an asymmetric cryptography. Data encrypted by a private key can only be decrypted by the matching public key. Therefore, if the receiver successfully decrypts the data, the receiver considers that the sender is authentic. For example, Alice encrypts a piece of information with the private key and sends the information to Bob. Bob decrypts the information using the public key of Alice. If the decrypted information is the same as the piece of information that Alice encrypts, Bob confirms that the information is sent by Alice. This process is called digital signature.

When a digital signature is used to authenticate user identity, the public key of the authenticated party must be valid. Otherwise, unauthorized users can forge the identity of the authenticated party to communicate with the authenticator. Validity of a public key can be ensured by issuing the public key through a digital certificate.

A digital certificate (certificate for short) is a file that binds a public key to a user identity. A certificate is issued by a certificate authority (CA). The CA provides a trusted-CA file when it issues a certificate to prove the CA identity and certificate validity.

When an SSL server or client wants to authenticate the identity of a peer, it must send the certificate obtained from the CA to the peer, and the peer determines certificate validity based on the trusted-CA file. After verifying validity of the certificate, the SSL server or client uses the public key in the certificate to authenticate the peer.

Data Confidentiality

Data transmitted on networks is vulnerable to eavesdropping by unauthorized users. SSL sets up an encryption channel between the two communicating parties to ensure data confidentiality.

Before sending data through an encryption channel, the sender uses an encryption algorithm and key to encrypt the data. After receiving data from an encryption channel, the receiver uses a decryption algorithm and key to obtain the plain text data. Any third-party device without the key cannot obtain the plain text data. Data confidentiality is thereby ensured.

Two types of encryption and decryption cryptography are available:
  • Symmetric cryptography: The devices use the same key to encrypt and decrypt data. This method features fast computing and is generally used to encrypt a large amount of information, for example, all packets between two communicating parties.
  • Asymmetric cryptography: The devices use different keys to encrypt and decrypt data, one public key open to peers and one private key locally kept. Data encrypted using a public (or private) key can only be decrypted using a private (or public) key. This method is typically used to encrypt and decrypt a small amount of information.

SSL uses the key exchange algorithm Rivest Shamir and Adleman (RSA), an asymmetric cryptography, to encrypt the premaster secret randomly generated by the client. The two ends use the premaster secret to generate the key for a symmetric cryptography and then use the symmetric cryptography to encrypt data to be transmitted.

Message Integrity Check

To prevent data transmitted on networks from being modified by unauthorized users, SSL uses the key-based MAC algorithm to ensure message integrity.

A MAC algorithm converts a key and arbitrary-length data into fixed-length data.
  • A sender uses the 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 that in the received message.

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

Protocol Structure

As shown in Figure 12-60, SSL functions between the application layer and transport layer. SSL is composed of two layers: the SSL Record Protocol at the bottom layer and the SSL Handshake protocol, SSL Change Cipher Spec Protocol, and SSL Alert Protocol at the upper layer.
Figure 12-60 SSL protocol stack
  • SSL Record Protocol: divides upper-layer data into blocks, computes the data, adds Message Authentication Code (MAC), encrypts the data to form record blocks, and sends the record blocks to the peer. The SSL Record Protocol implements data transmission.
  • SSL Handshake Protocol: used before application data is transmitted. The SSL Handshake Protocol negotiates a cipher suite including an encryption algorithm, a key exchange algorithm, and a MAC algorithm, authenticates server and client, and exchanges a key securely between the server and client.
  • SSL Change Cipher Spec Protocol: used by both the client and server to send a Change Cipher Spec message to notify each other that subsequent packets will be protected using the new cipher suite and key.
  • SSL Alert Protocol: reports alarms about the handshake or data transmission process to the remote end, so that the remote end can take corresponding measures. An alarm message conveys the severity of the message and description of the alarm.

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 12-61 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 12-61 are optional.

Figure 12-61 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 can the subsequent handshake process 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 12-62. The details are as follows:

Figure 12-62 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 12-63 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 12-63 Data transmission process
Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 57938

Downloads: 3621

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