Ssl&https Brief Introduction

This is a recent look at SSL and HTTPS summary of a simple, and most of the content is the reference network content, self-summed up the next.

SSL Introduction

HTTPS describes the HTTP request data workflow:

Users enter URLs in the browser and tell the browser what they need;

The browser parses the URL and records what the user needs as a list;

The browser sends a message to the server, and lists it to tell the server that it needs the information;

L The server receives the information sent by the browser, and returns the corresponding information and list back;

L server sends information to the browser;

L The browser gets the information and checks the information according to the list;

L Display the information to the user.

One problem is that neither the browser nor the server verifies the validity of the manifest information and the identity of the other person. What if someone in the middle of the way to pass the browser (server) to the server (browser) to intercept the information, and then to replace the list of information, or directly forge a message request in lieu of the original request sent to the service side of this situation.

HTTPS

Because HTTP requests have these security issues, HTTPS was born.

HTTPS (full name: Hyper Text Transfer Protocol over secure Socket Layer) is a security-targeted HTTP channel and is simply a secure version of HTTP. That is, the SSL layer is added under HTTP, the security base of HTTPS is SSL, so the detailed content of encryption requires SSL, and its general way is as follows:

1. The client requests a public key from the server and then encrypts the information using the public key

2. The server receives the encrypted information and decrypts it with its own private key.

Public key passwords and algorithms are public, while private keys are confidential. The public key used by encryption and the private key used for decoding are not the same, so this is an asymmetric encryption algorithm.

Symmetric and asymmetric encryption symmetric encryption

Symmetric encryption is the fastest and simplest way to encrypt encryption (encryption) and decryption (decryption) with the same key (secret key). Symmetric encryption has many algorithms, and because of its high efficiency, it is widely used in the core of many cryptographic protocols.

Symmetric encryption typically uses a relatively small key, typically less than the size of a bit. The greater the key, the stronger the encryption, but the slower the encryption and decryption process. If you use only 1 bit to do this key, the hacker can first try to decrypt with the word, no, then use 1 solution, but if your key is 1 MB large, hackers may never crack, but the encryption and decryption process takes a long time.

Asymmetric encryption

Asymmetric encryption provides a very secure way to encrypt and decrypt data, using a pair of keys, public key, and private key. The private key can only be safely kept by one party and cannot be compromised, while the public key may be sent to any person requesting it. Asymmetric encryption uses one of these keys to encrypt, while decryption requires another key. For example, you ask the bank for the public key, the bank sends you the public key, you encrypt the message using the public key, then only the holder of the private key-the bank can decrypt your message. Unlike symmetric encryption, the bank does not need to send the private key over the network, so security is greatly improved.

Digital certificates

Because the internet is unsafe, the public key is also part of the information, and there is a risk of tampering. So the introduction of the Internet authority-CA institutions, also known as Certificate Authority (Certificate Authority) institutions, the browser will be built into these "trusted Root Certification Authorities" (that is, CAs).

Service end to the authority of the identification of the CA institutions to apply for digital certificates, CA institutions verified the site, the site will be entered into the internal list, using a Hash of the server to generate a summary of some relevant information, and then the CA agency with its own private key, the service side of the public key and related information encrypted together, A digital certificate is then issued to the server requesting the certificate, which is used by other clients (such as browsers) to authenticate the public key of the site.

Client through the server issued by the certificate, find the corresponding CA, and then to the CA verify that the certificate is valid, after the CA authentication passed, the public key of the server is issued.

Because the CA is authoritative and trustworthy, the client (browser) trusts the CA, and the CA trusts the authenticated server, so the client (browser) trusts the server, which is the trust chain (Chain of trusts).

A CA-issued digital certificate typically contains this information:

Simply put: to ensure that the public key is secure, the public key is verified by a digital certificate.

SSL Introduction

SSL (securesockets layers, Secure Sockets Layer) and its successor Transport Security layer (Transport layer SECURITY,TLS) is a security protocol that provides security and complete data integrity for network communications. TLS encrypts the network connection with SSL at the transport layer.

The current version of TLS is 1.2 (also marked as SSL3.3) and is supported by the current mainstream browser.

Three features of the SSL protocol:

Confidentiality: All messages are encrypted after the session key is defined in the Handshake Protocol;

L Identification: Optional client authentication, and mandatory server-side authentication;

L Integrity: Messages that are transmitted include message integrity checks.

How SSL works:

Handshake Protocol (Handshake Protocol)

Recording Protocol (record Protocol)

Alarm Protocol (Alert Protocol)

Handshake Protocol

The handshake protocol is the first sub-protocol used by both the client and the server to communicate with SSL connections, which includes a series of messages between the client and the server. The most complex protocol in SSL is the handshake protocol. This protocol allows the server and client to authenticate each other, negotiate encryption and Mac algorithms, and a secret key to protect the data sent in the SSL record. The handshake protocol is used before the application's data transfer.

Each handshake protocol consists of the following 3 fields
(1) Type: represents one of 10 message types
(2) Length: Indicates the length of the message bytes
(3) Content: message-related parameters

4 Stages of a handshake protocol

The first phase of the ability to establish secure links

The first phase of the SSL handshake initiates a logical connection that establishes the security capability of the connection. First the client sends a client Hello message to the server and waits for the server to respond, and then the server returns a Serverhello message to the client confirming the information in the client Hello message.

ClientHello the customer to send Cilenthello information, including the following content:

(1) The maximum number of SSL versions a client can support

(2) A random number used to generate the master key.

(3) A session ID that determines the session.

(4) A list of cipher suites that a client can support.

(5) A list of compression algorithms that a client can support.

Serverhello Server uses Serverhello information to answer customers, including the following content

(1) An SSL version number. The highest version number supported by the client and the lower of the highest version number supported by the server.

(2) A random number used to generate the master key.

(3) Session ID

(4) A cipher suite selected from the client's cipher suite list

(5) Compression method selected from the list of compression methods of the client

After this phase, the client server knows the following:

(1) SSL version

(2) Key exchange, information verification and encryption algorithm

(3) Compression method

(4) About two random numbers generated by the key.

Second stage server authentication and key exchange

The server initiates the SSL handshake phase 2nd, which is the only sender of all messages at this stage, and the client is the only recipient of all messages. This phase is divided into 4 steps:

(a) Certificate: The server sends the digital certificate and the entire chain to the root CA to the client, enabling the client to authenticate the server with the server's public key in the server certificate.
(b) Server key exchange (optional): This depends on the key exchange algorithm
(c) Certificate request: The server may require the customer to authenticate itself.
(d) Server handshake completion: End of second phase, signal starting at phase three

The preceding (a) certificate and (b) Server key exchange in this phase are based on the key exchange method. There are 6 types of key exchange algorithms in SSL: Invalid (no key exchange), RSA, anonymous Diffie-hellman, temporary diffie-hellman, fixed Diffie-hellman, Fortezza.

In Phase 1, the process client negotiates with the server to determine which key exchange algorithm to make.

If the RSA Exchange key is determined during negotiation, the process is as follows:

In this method, the server sends the RSA encryption/decryption public key certificate in its first message. However, because the master secret is generated and sent by the client at the next stage, the second message is empty. Note that the public key certificate is validated from the server to the client. When the server receives a prestaged master secret, it uses the private key to decrypt it. Having a private key on the server side is an evidence that it is a required entity in the public key certificate it sends in the first message.

The third stage client authentication and key exchange

The client initiates the SSL handshake phase 3rd, which is the only sender of all messages at this stage, and the server is the only recipient of all messages. This phase is divided into 3 steps:

(a) certificate (optional): In order to prove itself to the server, the customer sends a certificate information, which is optional and can be configured in IIS to enforce client certificate authentication.

(b) Client key exchange (Pre-master-secret): Here the client sends the master key to the server, noting that it is encrypted using the server's public key.

(c) certificate validation (optional), signing of the pre-secret and random number to prove that the public key of the certificate has (a).

The following also focuses on the RSA method of client authentication and key exchange.

In this case, there is no certificate information unless the server explicitly requests it in phase II. The client key exchange method includes the preliminary master key that is received by the RSA public key in Phase II.

After Phase III, the customer has to have the server to authenticate, and the client and the server are aware of the prestaged master key.

Phase IV Completed

At this stage, both the client and the server have three data-client random number, server-side random number, and preliminary master key.

Then the client and the server in accordance with the previously agreed encryption method, generated the "Same" session key, then the client and the service side of the information transmission or through the HTTP protocol to transmit, but the content of the information is through the session key encryption processing, only with the same key to decrypt, to be able to obtain the content.

In this way, the handshake protocol between the client and the server is completed, and a secure information transmission channel is established.

Recording protocol

The logging protocol is used after the client and server handshake are successful, that is, after the client and server authenticate each other and determine the algorithm used for secure information exchange, enter the SSL logging protocol, which provides two services to the SSL connection:

(1) Confidentiality: implementation of secret keys defined using handshake protocol

(2) Integrity: Handshake protocol defines MAC for guaranteed message integrity

The process of documenting the protocol:

The first step is a shard

Each user wants to send a message over SSL will be cut to a maximum of 214B (or 16364B) size of the Shard, then you can choose whether to perform the compression step.

In the process of compression, there must be no loss of compression, which means that the original complete message can be obtained after decompression. In addition, the compressed content should not exceed the original length of more than 1024 bytes (of course, we hope that the compressed data can be smaller, rather than increased.) However, for some very small shards, it is possible that the compression algorithm will result in longer than the original data because of the requirements in the format of the compress algorithms. In SSLv3 (and the existing version of TLS), there is no compression algorithm specified, so the default additive algorithm is null.

The second step is to add a Mac (Message authentication cores)

Message authentication code (hash function with key): In cryptography, a kind of authentication mechanism used by both sides of the communication entity to guarantee the integrity of the message data. The construction method is proposed by M.bellare, and the security relies on the hash function, so it is also called the hash function with the key. The message authentication code is a value obtained based on the key and message digest, which can be used for authentication and integrity checking of the data source.

Before the data is sent, the sender first computes its digest value using the hash function negotiated by both parties to the communication. The message verification code is obtained by the digest value under the action of the shared session key. After that, it is sent along with the data. When the receiving party receives the message, it first restores the digest value using the session key, and uses the negotiated hash function in the handshake protocol to calculate the data received locally, and then generate the digest value, and compare the two data. If the two are equal, the message passes the authentication.

The third step is to add the SSL record header

This record header contains the following fields.

(1) data type (Contenttype), 8 bits: The upper layer protocol used to process this shard.

(2) Major version number (MajorVersion), 8-bit: SSI used. The major version of the Protocol, for SSI. For the V3 protocol, this field has a value of 3.

(3) Minor version number (minorversion), 8 bit: Indicates the minor version used, and for the SSLV3 protocol, the field value is 0.

(4) Compressed data length (compressedlength), 16 bits: The length of this plaintext shard (false so that the Shard has been compressed, then the compressed length). The maximum value is (214+2048) B.

Warning protocol

SSL warning Protocol, also known as SSL alarm protocol, SSL alarm protocol, is used to pass SSL to the peer entity warning. If a party discovers any anomalies during the communication process, it needs to send a warning message to each other.

SSL alarm protocol messages are composed of two parts: severity level and warning code.

The severity level of the SSL alarm protocol is divided into fatal and warning for two kinds. Among them, the fatal level alarm is the fatal level alarm, it requires both parties to take emergency measures, and terminate the session, such as in the course of data transmission, if the wrong Mac is found, both sides need to immediately interrupt the session, while eliminating their own buffer corresponding session record , and the warning level alarm is the warning level of alarm processing, usually both sides of the communication only log records, it does not affect the communication process.

Here are some warning messages:

(1) Unexpected_message: An inappropriate message was received.

(2) Bad_record_mac: An incorrect Mac was received.

(3) Decompression_failure: The decompression function received an inappropriate input.

(4) Illegal_parameter: One of the fields in the handshake message is out of range or incompatible with other fields.

(5) Certificate_revoked: The certificate has been discarded.

(6) Bad_certificate: The certificate received is wrong.

(7) Certificate_expired: The certificate has expired.

(8) Handshake_failer: The handshake process failed.

One-way Certification

HTTPS before establishing a socket connection, a handshake is required, as follows:

1. The client sends the SSL protocol version number, the encryption algorithm kind, the random number and so on to the service side information.

2. The service side returns the SSL protocol version number, the encryption algorithm type, the random number and so on the client, also returns the server side certificate, namely the public key certificate

3. Clients use the information returned by the server to verify the legitimacy of the servers, including:

o Certificate is expired

o The CA of the hairstyle server certificate is reliable

o whether the returned public key will correctly unlock the digital signature in the returned certificate

o whether the domain name on the server certificate matches the actual domain name of the server

After the validation passes, the communication continues, otherwise, the communication is terminated

4. The client sends its own symmetric encryption scheme that can be supported by the server to choose from.

5. The server side chooses the encryption method with the highest encryption in the encryption scheme provided by the client.

6. The server returns the selected encryption scheme to the client by clear text

7. After the client receives the encryption method returned by the server, it uses the encryption method to generate a random code, which is used as a symmetric encryption key in the communication process, and encrypts the encrypted random code to the servers using the public key returned by the service side.

8. After the server receives the encrypted information returned by the client, it decrypts it with its own private key and obtains the symmetric encryption key.
In the next session, the server and client will use this password for symmetric encryption to ensure the security of the information during the communication.

Two-way authentication

Two-way authentication and the principle of one-way authentication is almost the same, except that the client needs authentication Service side, increase the service side of the client authentication, the specific process is as follows:

1. The client sends the SSL protocol version number, the encryption algorithm kind, the random number and so on to the service side information.

2. The service side returns the SSL protocol version number, the encryption algorithm type, the random number and so on the client, also returns the server side certificate, namely the public key certificate

3. Clients use the information returned by the server to verify the legitimacy of the servers, including:

o Certificate is expired

o The CA of the hairstyle server certificate is reliable

o whether the returned public key will correctly unlock the digital signature in the returned certificate

o whether the domain name on the server certificate matches the actual domain name of the server

After the validation passes, the communication continues, otherwise, the communication is terminated

4. The server requires the client to send the client's certificate, and the client sends its own certificate to the server

5. Verify that the client's certificate is validated and gets the client's public key

6. The client sends its own symmetric encryption scheme that can be supported by the server to choose from.

7. Server-side Select the most encrypted encryption method in the client-provided encryption scheme

8. Encrypt the encryption scheme by using the public key obtained before returning to the client

9. After receiving the cryptographic scheme ciphertext returned by the server, the client uses its own private key for decryption, obtains the specific encryption method, and then generates the random code of the encryption method, which is used as the key in the encryption process, and then sends it to the server after encrypting it from the public key obtained from the server certificate.

10. The server receives the message sent by the client, decrypts it with its own private key, obtains the symmetric encrypted key, and in the next session, the servers and clients will use the password for symmetric encryption to ensure the security of the information during the communication.

Ssl&https Brief Introduction