httpNot safe?

HTTP is a plaintext transmission protocol. Data is not encrypted in the process of data interaction between the client and the server, and there is no authentication verification between the communication parties. Therefore, it is easy to be hijacked, monitored and tampered with.

The transmission process is as follows:

When pharaoh (client) to Lao li (server) messenger, in the process of mail, many Courier are handled, which leads to a large number of Courier can view messages content (content clear, so I can see), if the letter contains the bank card number and password, or other account password, can be seen among a large number of Courier, security is low.

HTTP must be insecure?

We cannot change the HTTP plaintext transmission, so we can add certain verification to the transmission parameters, this verification can be the client and server oral agreement on a certain processing algorithm, such as: http://baidu.com?name= Laowang&age =31&hash=560bec183a4da191, the hash field is simply processed into the md5 encrypted ciphertext of name Laowangage31, when hijacked by the middleman, the middleman does not know our encryption algorithm, It can only change the hash value of name= ollie &age=100, which the middleman cannot calculate correctly. When receiving the message, the server discards the message if the hash parameter value is inconsistent with the calculated one.

After the verification algorithm filtering, ordinary middleman has been unable to attack the server directly. So is there a safer way?

https

To solve the plaintext problem of HTTP, we need to introduce encrypted identity and authentication mechanisms.

If the message sent from the server to the client is ciphertext, only the server and client can understand it, ensuring data confidentiality. At the same time, before the exchange of data to verify the legal identity of the other party, you can ensure the security of both sides of the communication, then the problem comes, the server encrypted data client how to decrypt? At this time, the server must tell the symmetric encryption key to the client, the client can use of symmetric key to solve the content of the cipher text, but the server will definitely symmetric key is sent to the client, the middleman can also be hijacked, but if the server in cipher way to send to the client, the client is how to solve the cipher?

In TLS handshake phase, the server sends the public key to the client in plaintext. The client encrypts the symmetric key to the server using the public key. Subsequent data transmission is encrypted using the symmetric key.

This may seem lax, but in the three-way handshake the client request is hijacked by a middleman, who can also intercept the public and symmetric keys to tamper with the data. So how to solve this problem?

Middlemen received the server sends to the client’s public key and not sent to the client, but the middleman to save announcement, forged false public key transmission to the client, and then after that, the client the symmetric key used fake public-key encryption transmission, middlemen can view of the symmetric key after hijacked after decryption, The middleman then encrypts the decrypted data using the real public key and sends it to the server, who decrypts it using the private key. This completes the communication.

As shown in the figure:

In order to solve such problem, the concept of digital certificates, the server generates the public and private key, provide the public key to the relevant institutions (CA), CA public key in a digital certificate and digital certificate issued to the server, the server is not simple to give the client public key, but to give the client a certificate, a digital certificate to join some of the digital signature mechanism, This ensures that the digital certificate must be sent from the server to the client. The middleman’s forged certificate is not authenticated by the CA, at which point the client and server know the communication has been hijacked.

In summary symmetric encryption (public and private keys) exchange symmetric keys + digital certificate authentication (to verify whether the public key is forged) + use symmetric keys to encrypt subsequent data transmission == security.

TCP three-way handshake

As shown in the figure, the three-way handshake is:

  1. The client sendsSYN=1,seq=xTo the server, the client comes inSYN_SENTstate
  2. The server receivesSYN=1,Know the request to connect, and then sendSYN=1,ACK=q,seq=y,ack=x+1Here,ACK=1Indicates a confirmation packetAck field is valid.ack=x+1Indicates that it has been receivedxandxPrevious package, please send next timex+1Give it to me.SYN=1Request connection,TCPIt is full-duplex. If the client connects to the server, the server also connects to the client. But isSYN=1andACK=1Merged into one package. In this case, the server isSYN_REVDState.
  3. The client receivesSYN=1,ACK=q,seq=y,ack=x+1Data, know that the server has been connected, but need to tell the server, oneself (client) can also receive the server data, sendACK=1,seq=x+1,ack=y+1. At this point the client is inESTABLISHEDState.
  4. The server receives a message from the clientACK=1,seq=x+1,ack=y+1Then the client knows it has been receivedseq=yThe handshake is complete. The server is inESTABLISHEDState.

I found a dynamic map on the Internet. It looks good

Caught validation

The Wireshark is used to capture packets and verify the TCP three-way handshake.

If IP =161.117.186.50, all interactions with this IP address are filtered out.

The client sends SYN

First the client sends SYN=1,seq=0 to the server.

The first random SEQ is 0, so the message is sentSYN=1,seq=0.

SYN is set. If the SYN bit is not set, it indicates that the packet is synchronous and requests to establish a link.

The service side

The server receives the link request, naturally agrees and sends itACK=1,ack=1TCP is full-duplex, so the server also needs to request the client resume link, also sentSYN=1,seq=0, combined together, isSYN=1,ACK=1,seq=0,ack=1, as shown in the figure below:

Shake hands to complete

When the client receives a SYN=1,ACK=1, SEQ =0, ACK=1 packet from the server, it knows that it is connected to the server. If the server links to itself, the client needs to send ACK=1 again to the server to let the server know. Therefore, the client sends ACK=1, ACK=1, seq=1 to the server, and the server starts to listen to the port of the client. The handshake is complete.

Four times to wave

After the three handshakes, I’m sure you should review the four waves.

This diagram is funny and easy to understand. When the client no longer needs to transfer data to the server, it needs to disconnect.

The two parties are in the ESTABLISHED state before the connection is disconnected.

  1. The client sends FIN=1,seq=x to the server, and the client is in FIN_WAIT1 state.

  2. After receiving the disconnected request, the server will tell the client that IT has been received and send ACK=1, SEq =y, ACK= x+1 to indicate that it has received your disconnected request. The server is in CLOSE_WAIT state and the client is in FIN_WAIT2 state.

  3. If the server no longer needs to transmit data to the client, it sends FIN=1, SEq = Z, ACK =x+1 to the client. Then the client enters the LAST_ACK state.

  4. After receiving the disconnection request, the client sends ACK=1, ACK= Z +1,seq=x+2, indicating that the client has accepted the disconnection request from the server. The four waves are complete.

In the fourth step, if the server does not receive the ACK packet from the client, it will start a timer that counts 2MSL(Maximum Segment Lifetime). If the server does not receive a response after 1MSL, it will send a FIN=1 seq=z, ACK =x+1. After 2MSL, the link will be discarded.

Verify four waves

  1. The client actively disconnects and sendsFIN=1,ACK=1,seq=706,ack=1244.

  1. When the server receives an active disconnection request from the client, it sends a confirmation packet and a termination packet.FIN=1,ACK=1,seq=1244,ack=707.

  1. The client receives the confirmation packet and disconnection request from the server and sends the confirmation packet to the server:ACK=1,seq=707,ack=1245.

Complete with four waves.

Do you have to disconnect 4 times?

Not necessarily. When the server receives the disconnection request from the client, FIN=1,ACK=1, SEq =y, ACK= x+1 can be transmitted to the client at the same time. Then the second and third steps in the figure are combined into one packet.

The TLS handshake

The TLS handshake takes place after the three-way handshake, because the two parties want to send data verification on the basis that they can communicate with each other, and communication must take place after the handshake is completed.

1. client hello

Client step 1client helloTo generate thesession ID, and support 26 encryption algorithms, let the server choose.

1.1 random_c

In the client greeting, the first four bytes are the timestamp, and the 28-byte random number (random_c) is used later.

1.2 the session ID

Session ID To reduce the number of handshakes, you can carry the ID the second time, unless you need to re-shake the handshake for other reasons. Session ids are supported by most servers. However, session ids are reserved on only one server. When a client sends a session ID to another server, the session ID cannot be resumed.

1.3 Cipher Suites

This test Chrome browser supports 26 encryption algorithms, they are usually written as key exchange algorithm + symmetric encryption algorithm + hash algorithm TLS_AES_128_GCM_SHA256 as an example:

During the handshake, TLS protocol is used for key exchange, RSA signature and identity authentication are used. After the handshake, AES symmetric algorithm is used for communication, the key length is 128 bits, the grouping mode is GCM, and the abstract algorithm is SHA384 for message authentication and random number generation.

Speaking of TLS, we have to talk about OpenSSL, which is a famous open source cryptography engineering library and toolkit, almost supports all public encryption algorithms and protocols, has become a de facto standard, many software will use it to achieve TLS functions, including Apache, Nginx and so on.

1.4 Server Name Extension

When we visit a site, we must first resolve the corresponding IP address of the site through THE DNS, through the IP address to access the site, because most of the time an IP address is given to many sites public, so if there is no server_name field, the server is unable to give the corresponding digital certificate to the client. The Server_name extension allows the server to grant corresponding certificates to browser requests.

Server receives the client hello will reply Server hello/Certificate/Certificate Status three packets.

2. Server hello

2.1 We get server UTC in Unix time format and 28 bytes random number (random_S)

2.2 Seesion ID, the server generally has three options for the session ID (we will see later that this session ID is used for the second packet capture after half a minute) :

(1) Recovered session ID: As mentioned in client Hello, if the session ID in client Hello is cached on the server, the server will try to restore this session.

(2) New session ID: If the session ID in client Hello is null, the server will give the client a new session ID. If the session ID in client Hello is null, the server will give the client a new session ID. If the session ID in client Hello is null, the server cannot find the corresponding cache. A new session ID is returned to the client.

(3) NULL: The server does not want this session to be recovered, so the session ID is NULL.

2.3 Provides an encryption family in Client Hello, which is selected by the serverTLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, which means that the server will adoptECDHE_RSAAlgorithm for key exchange, throughAES_128_GCMSymmetric encryption to encrypt data, usingSHA384To ensure data integrity.

3 Certificate, Server key Exchage and Server Hello Done

3.1 Certificate

In the previoushttpsTheory study, we know that in order to secure public key will be distributed to the client, the server will put public key in a digital certificate and sent to the client (digital certificate can be issued in the, but generally to ensure safety will have a dedicated CA issued by institutions), so the message is a digital certificate, the length of 3063 bytes is the certificate.

3.2 server key exchage

3.3 Server Hello Done

The bag we caught isCertificate, Server Key Exchage, and Server Hello DonePackages merged together.

4. The client verifies the certificate

The customer verifies the validity of the certificate. If the verification succeeds, subsequent communication is performed. Otherwise, the validity verification is as follows:

    1. Trusted Certificate Path;
    1. There are two types of offline CRL and OCSP for certificate revocation.
    1. Validity verification
    1. Domain name validation

5. Key exchange

The process is complicated, as follows:

  • 1. First, client utilizationCAThe certificate implements identity authentication, and the server is insercer helloAnd then, if you useECDHEThe exchange key algorithm needs to sendserver exchange keyTo the client, otherwise not.
  • 2. The client receives the messageserver exchange key, also sent to the serverclient exchange keyTo use (server exchange key client exchange key) afterECDHEAlgorithm to generate another onepre-master. Now random numbers haverandom_c,random_sandpre-master, the three random numbers can be used to generate the master key for the encryption session, calledMaster Secret.

After receiving the Client Exchange key from the client, the server also generates pre-master by using these two keys, and then generates master Secret by using PRF algorithm. When non-ECDHE algorithm is used, the client Exchange key is a random number, which is calculated by ECDHE algorithm to obtain pre-master, and then calculated with random_C and random_S to obtain Master key master-secret.

    1. The server receivespre-master, decrypt it with the private key, and take it outpre-masterI saved it beforerandom_c.random_s, using these three parameters to generate the master key, the algorithm is as follows:
master_secret = PRF(pre_master_secret,"master secret",ClientHello.random+ServerHello.random)
Copy the code

RSA handshake procedure

There are two differences between the TLS handshake:

    1. useECDHEThe algorithm implements key exchange instead ofRSA, so the server will issueServer key exchangeThe message
    1. Because the use ofECDHEThe client doesn’t have to wait until it sends backFinishedSend as soon as the handshake is confirmedHTTPMessage, save a message round trip time time waste. This is calledTLS False Start.

In the traditional TLS handshake, the server exchange key is missing. Instead of using the Server Exchange key and client Exchange key to generate pre-master, the client directly generates random numbers. Then encrypt the message with the public key of the server and send it to the server through the Client Exchange key message. The incoming server decrypts the message with the private key. After the two parties realize the shared three random numbers, the key can be generated.

All the processes are summed up in one diagram:

The Session reuse

When the connection is established for the first time, the server will store the Session ID in the queue. When the client requests the Session ID next time, it will be transmitted through the client Hello. The server will verify the Session ID. Return Change Cipher Spec, Encrypted Handshare Message, and you can use it directly. If not, repeat TLS handshake.

This will be version 1.2, so what are the optimizations for version 1.3?

The TLS 1.3

In 1.3, when the server receives the Client Hello, The ECDHE algorithm is used to calculate the pre-master according to the four parameters of Client Params, Client Random, Server Random and Server Params, and then the Client Random number C and Server is used The random number S and pre-master are calculated by HKDF to obtain the master key, and then encrypted communication can be carried out. After receiving Server Certificate, Server Random and Server Params, the client verifies the validity of the Certificate, and then uses HKDF algorithm to calculate the master key by using the above four parameters. Then the client notifies the Server that it can carry out encrypted communication.

Compared with TLS1.2, in the handshake phase, the Server sends Server/Client Key Exchange to the Client, and the number of plaintext displays is reduced. Only the plaintext Client Hello and Server Hello can be seen in the handshake phase. Other information is encrypted by the Key.

reference

  • rfc6528
  • Why A TCP connection requires three handshakes