Shulou(Shulou.com)05/31 Report--

How to carry out the theoretical analysis of Server Name Indication, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

SNI (Server Name Indication) is an extension used to improve server and client SSL (Secure Socket Layer) and TLS (Transport Layer Security). The main solution is to solve the disadvantage that a server can only use one certificate (one domain name). With the server's support for virtual hosts, multiple domain names can be provided on one server, so SNI must be supported to meet the demand.

Background of SNI production

SSL and TLS (an upgraded version of SSL) provide conditions for a secure connection between the client and the server. However, due to the technical limitations at that time, the initial design of SSL conformed to the classic public key infrastructure PKI (Public Key Infrastructure) design. PKI believed that only one server could provide services for one domain name, so only one certificate could be used on one server. In this way, when the client sends the request, it uses DNS domain name resolution, as long as the request is sent to the resolved IP address (server address), and then the server returns its unique certificate to the client for verification, and then the subsequent communication continues. Then through the negotiated encryption channel, the desired content is obtained. This means that the server can send or submit certificates during the startup phase of SSL because it knows which specific domain name it is serving.

As the HTTP server turns on virtual hosting support, each server can provide services for many domain names through the same IP address. This simple way to provide communication security for virtual hosts often leads to the use of the wrong digital certificate, because the server cannot know which domain name the client is requesting, which causes the browser to warn the user.

Unfortunately, when SSL encryption is set, the server has submitted a certificate to the client before reading the domain name in the HTTP request, that is, it has provided services for the default domain. However, a server may provide services for thousands of domain names, and it is impossible to send all certificates to the client to verify one by one and find the certificate corresponding to the requested domain name. SNI is designed to allow the server to decide which domain to serve based on the request, and this information is usually obtained from the HTTP request header.

SSL/TLS handshake

Anyone who is familiar with the SSL/TLS handshake process knows that it mainly goes through the following processes:

The client verification server based on RSA handshake and key exchange details the TLS/SSL handshake process for the example.

1 C-> S:client_hello

The client initiates a request to transmit request information in clear text, including version information, cipher suite candidate list, compression algorithm candidate list, random number, extension field and other information.

The highest TSL protocol version supported by the SSL/STL version is version, which is SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 from low to high. Currently, versions lower than TLSv1 are no longer used.

List of cipher suites cipher suites supported by the client, each cipher suite corresponds to a combination of four functions in the previous TLS principles: authentication algorithm Au (authentication), key exchange algorithm KeyExchange (key agreement), symmetric encryption algorithm Enc (information encryption) and information digest Mac (integrity check)

List of supported compression algorithms compression methods for subsequent information compression transmission

Random number random_C, used for subsequent key generation

The extension field extensions supports the relevant parameters of protocols and algorithms and other auxiliary information. The common SNI belongs to the extension field. The role of this field will be discussed separately later.

2 server_hello+server_certificate+sever_hello_done

Server_hello, the server returns the result of the negotiation, including the selected protocol version version, the selected encryption suite cipher suite, the selected compression algorithm compression method, the random number random_S, etc., in which the random number is used for subsequent key negotiation

Server_certificates, server-side configuration of the corresponding certificate chain for authentication and key exchange

Server_hello_done, notifies the client that the server_hello message is sent to an end

3 certificate verification

The client verifies the validity of the certificate, and the subsequent communication will be carried out only if the verification is passed, otherwise prompts and actions will be made according to the error conditions. Validity verification includes the following:

The trustworthiness trusted certificate path of the certificate chain, as described earlier

There are two ways to revoke revocation certificate: offline CRL and online OCSP. Different client behaviors will be different.

Validity period expiry date, whether the certificate is within the valid time range

Domain name domain, check whether the certificate domain name matches the current access domain name, and analyze the matching rules later

4 client_key_exchange+change_cipher_spec+encrypted_handshake_message

Client_key_exchange. After the validity verification is passed, the client calculates and generates a random number Pre-master, which is encrypted with the certificate public key and sent to the server.

At this point, the client has obtained all the information needed to calculate the negotiation key: two plaintext random numbers random_C and random_S and the Pre-master generated by their own calculation, and calculate the negotiation key.

Enc_key=Fuc (random_C, random_S, Pre-Master)

Change_cipher_spec, the client informs the server that the subsequent communication is encrypted using the negotiated communication key and encryption algorithm.

Encrypted_handshake_message, which combines the hash values of all previous communication parameters with other related information to generate a piece of data, encrypts it with the algorithm using the negotiation key session secret, and then sends it to the server for data and handshake verification.

5 change_cipher_spec+encrypted_handshake_message

The server decrypts the encrypted Pre-master data with the private key, and calculates the negotiation key: enc_key=Fuc (random_C, random_S, Pre-Master) based on the two plaintext random numbers random_C and random_S exchanged before.

Calculate the hash value of all previously received information, and then decrypt the encrypted_handshake_message sent by the client to verify the correctness of the data and key

Change_cipher_spec, after the verification is passed, the server also sends change_cipher_spec to inform the client that the subsequent communication is encrypted using the negotiated key and algorithm.

Encrypted_handshake_message, the server also combines all the current communication parameter information to generate a piece of data and encrypts it with the algorithm using the negotiation key session secret and sends it to the client

6 end of handshake

The client calculates the hash values of all received messages, decrypts the encrypted_handshake_message with a negotiated key, verifies the data and keys sent by the server, and then shakes hands.

7 encrypted communication

Start using the negotiation key to encrypt communication with the algorithm.

As can be seen from the above process, without SNI, the server cannot predict which domain name service the client is requesting.

SNI application

The TLS extension of SNI fixes this problem by sending the name of the virtual domain as part of the TSL negotiation. In the Client Hello phase, through the SNI extension, the domain name information is told to the server in advance, and the server obtains the corresponding certificate according to the domain name and returns it to the client to complete the verification process.

Curl

The main network interaction tool in Linux, curl 7.18.1 + & openssl 0.9.8j+ can support SNI,CentOS6.5 and below. Curl 7.15 does not support SNI,curl 7.21.3 but also supports the-resolve parameter, which can be directly located to the IP address for access. For services with multiple deployment nodes in a domain name, this parameter can be directed to access a device. The basic syntax is:

Example:

Curl-k-I-- resolve www.example.com:80:192.0.2.1 https://www.example.com/index.htmlWireShark grabs packets to verify SNI

Use curl7.15 (SNI is not supported) to capture the package result:

As you can see, the data obtained by grabbing the package using curl7.15 has no SNI extension, but the data obtained by grabbing the package with curl7.43 contains the SNI extension, which contains host information.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.