Basic principles of HTTPS

Basic knowledge Preparation: Before you understand the fundamentals of HTTPS, you need to understand the basics below.

First, what is Https,tls,ssl

HTTPS, also known as HTTP over TLS. The predecessor of TLS is SSL,TLS 1.0, which is typically marked as SSL 3.1,TLS 1.1 for SSL 3.2,tls 1.2 for SSL 3.3. Describes the relationship between TLS (each sub-protocol) and HTTP in the TCP/IP protocol stack.

Ii. differences between HTTP and HTTPS protocols

1, the HTTPS protocol needs to the certification authority (Certificate authority, referred to as CA) to apply for a certificate, the general free certificate is very small, need to pay.

2, HTTP is a Hypertext Transfer Protocol, the information is plaintext transmission, HTTPS is a secure SSL encryption Transfer protocol.

3, HTTP and HTTPS use a completely different connection method, the use of the same port, the former is 80, the latter is 443.

4, the connection of HTTP is very simple, is stateless.

5, HTTPS protocol is built by the SSL+HTTP protocol can be encrypted transmission, identity authentication network protocol, than the HTTP protocol security.

As can be seen from the above, HTTPS and HTTP protocols provide a

1. Data integrity: Content Transfer Integrity check
2. Data privacy: Content is symmetric encrypted, each connection generates a unique encryption key
3. Identity authentication: Third party cannot forge service side (client) identity

Where data integrity and privacy is guaranteed by the TLS Record protocol, authentication is implemented by TLS handshaking protocols.

Third, the certificate

1. What is a certificate?

2. What information is included in the certificate

• Certificate information: Expiration time and serial number
• Owner information: Name, etc.
• Owner Public Key

3, why the server to send a certificate to the client

There are too many services on the Internet that require certificates to authenticate so that the client (operating system or browser, etc.) cannot have all of the certificates built in, and the certificate needs to be sent to the client through the server.

4. Why does the client want to verify the received certificate

Middleman attack

5. How the client validates the received certificate

In order to answer this question, we need to introduce digital signature (Signature).

Generates a digital signature after a paragraph of text is processed by hashing (hash) and private key encryption.

Suppose that message delivery occurs between Bob,susan and Pat three people. Susan sends the message along with the digital signature to Bob,bob after receiving the message, you can verify that the received message is the one that Susan sent

The premise, of course, is that Bob knows Susan's public key. More importantly, as with the message itself, the public key cannot be sent directly to Bob in an unsecured network.

At this point, a certification authority (Certificate authority, called CA) is introduced, and the number of CAS is not many, and the Bob client has a built-in certificate for all trusted CAs. The CA generates a certificate after it digitally signs Susan's public key (and other information).

After Susan sends the certificate to Bob, Bob verifies the certificate signature through the public key of the CA certificate.

Bob trusts Ca,ca to trust Susan, so Bob trusts Susan, and the Chain of Trust (Chain) is formed.

In fact, the Bob client is built with the root certificate of the CA (root Certificate), and the server in the HTTPS protocol sends the certificate chain (Certificate Chain) to the client.

Formally start the content of https:

First, the basic principle of HTTPS

From above, HTTPS is able to encrypt information so that sensitive information is not available to third parties. Therefore, many bank websites or e-mail boxes and other security-level services will use the HTTPS protocol. HTTPS is actually made up of two parts: http + SSL/TLS, which adds a layer of encryption information to the HTTP module. The transfer of information between the server and the client is encrypted through TLS, so the transmitted data is encrypted. Specifically how to encrypt, decrypt, verify, and see.

1. Client initiates HTTPS request

This is nothing to say, is the user in the browser input an HTTPS URL, and then connect to the server port 443.

2. Configuration of the server side

Servers that use the HTTPS protocol must have a digital certificate that they can make themselves or apply to the organization. The difference is that the certificate you issued requires client authentication to continue access, and the certificate requested by a trusted company does not pop up on the hint page (Startssl is a good choice, with 1 years of free service). This set of certificates is actually a pair of public and private keys. If you do not understand the public key and the private key, you can imagine a key and a lock, but the whole world only you have this key, you can give the lock to others, others can use the locks to lock up important things, and then sent to you, because only you have this key, So only you can see what is locked up by this lock.

3. Transferring certificates

This certificate is actually the public key, but contains a lot of information, such as the certificate Authority, expiration time and so on.

4. Client Resolution Certificate

This part of the work is done by the client's TLS, first verify that the public key is valid, such as the authority, expiration time, and so on, if an exception is found, a warning box pops up, prompting for a problem with the certificate. If there is no problem with the certificate, then a random value is generated. The random value is then encrypted with a certificate. As it says above, lock the random values with locks so that the locked content is not visible unless you have a key.

5. Transmitting encrypted information

This part transmits the random value that is encrypted with the certificate, the purpose is to let the server to get this random value, the client and the service side of the communication can be encrypted by this random value to decrypt.

6. Service-Side decryption information

After the server is decrypted with the private key, a random value (private key) is obtained from the client, and then the content is symmetric encrypted by this value. Symmetric cryptography is the combination of information and private keys (random values) through an algorithm, so that unless you know the private key (random value), or not get the content, and just the client and the server know the private key (random value), so long as the encryption algorithm is sturdy enough, the private key (random value) is complex enough, the data is safe.

7. Transfer of encrypted information

This part of the information is the service side with the private key (random value) encrypted information, can be restored on the client

8. Client Decryption Information

The client decrypts the message from the server using the previously generated private key (random value), and obtains the decrypted content. The process the third party, even if he hears the data, is helpless.

Ii. communication flow and handshake process for HTTPS

1, HTTPS corresponding to the communication sequence diagram:

2, HTTPS before the transfer of data requires a client (browser) and the server (website) to a handshake, during the handshake will establish the two sides encrypted transmission of data password information. TLS/SSL protocol is not only a set of encrypted transmission protocols, but also an artist-designed artwork, TLS/SSL using asymmetric encryption, symmetric encryption and hash algorithm. A specific description of the handshake process is as follows:

1. The browser sends a set of encryption rules that it supports to the Web site.

2. The website selects a set of cryptographic algorithms and hash algorithms, and sends its own identity information back to the browser in the form of a certificate. The certificate contains information such as the website address, the encrypted public key, and the issuing authority of the certificate.

3. After the browser obtains the website certificate, the browser will do the following work:

A) Verify the legality of the certificate (the issuing authority is legal, the certificate contains the address of the website is consistent with the address being accessed, etc.), if the certificate is trusted, the browser bar will display a small lock, otherwise the certificate is not trusted to prompt.

b) If the certificate is trusted, or if the user accepts an untrusted certificate, the browser generates a random number of passwords and encrypts them with the public key provided in the certificate.

c) computes the handshake message using the agreed-upon hash algorithm, encrypts the message using the generated random number, and finally sends all previously generated information to the Web site.

4. After the Web site receives the data from the browser, do the following:

A) Use your own private key to decrypt the information to remove the password, use the password to decrypt the browser's handshake message, and verify that the hash is consistent with the browser.

b) Encrypt a handshake message with a password and send it to the browser.

5. The browser decrypts and calculates the hash of the handshake message, if it is consistent with the hash of the server, at which point the handshake process ends, and all the communication data will be encrypted by the random password generated by the previous browser and using the symmetric encryption algorithm.

Basic principles of HTTPS