Take Baidu website as an example:

DNS resolution

DNS resolution target domain namewww.baidu.com

Redirection 302

If accessedhttp://www.baidu.comReturn 302 to redirect to HTTPS

Use HTTPS protocol for communication, port 443, and handshake three times to establish TCP link:

1. the server is in listen status

2. the client sends syn=1 initial random sequence number seq=0 (x) for the first time, and the client enters the syn-sent state

3. the server agrees to establish a connection, returns the syn=1 ack=1 ack=x+1 initial random sequence number seq=0 (y), and enters the syn-rcvd status

4. after the client receives the confirmation of acceptance, it sends a confirmation to the server again. It sends ack=1, ack=y+1, and its serial number seq=x+1. The client enters the established state. After the service receives the confirmation, it enters the established state.

Note: if there is no confirmation message from the client, it is a second handshake. After the server sends the confirmation message, a new link will be established. At this time, the connection request from the client is delayed for a long time because of the network node (reaching the server at the time point after the link is released). Then the service sends another confirmation. The client ignores it and will not send data. The server establishes a new link, and the server is waiting to receive data, Consume server-side resources.

After the TCP link is established, start tls/ssl interaction:

The client sends the client Hello, carries the version information and the random number (used for subsequent symmetric encryption), and provides all available encryption protocols in cipher suites. Session ID length=0 indicates a new session. The server will return a session ticket later

The server returns an ACK confirmation message, seq=1 (indicating that the data flow starts from 1, and the data length is 0, which indicates that the server has not sent data) ack=518 (receiving 517 bytes of data sent by the client, and the next data flow of the client starts from 518 bits)

The server receives the client hello and returns the server Hello, carrying the TLS version information used, the number of random (for subsequent symmetric encryption) and the encryption protocol

Seq=1, len=68 (indicates that the data stream starts from 1 and sends 68 length data), ack=518 (accepts 517 bytes of data sent by the client, and the next data stream of the client starts from 518 bits). The same is true for certificate sending.

Server key exchange: not required. It depends on the encryption algorithm selected by the server. Here is TLS_ ECDHE_ RSA_ WITH_ AES_ 128_ GCM_ Sha256 (the current mainstream), that is, the certificate is only used to prove the server identity. The server key exchange sends Pb and elliptic curve name (as shown in the figure secp256r1)

Note: if the server side needs to verify the identity of the client side, it needs to initiate a certificate request before sending Hello done, and the client side will send certificates and client public keys like the server side (generally, the certificates and public keys of the client side are mainly provided through the U shield mode, which is used in online banking and other scenarios with high security requirements)

The client exchange client sends PA in the DH algorithm (since the client identity is not verified, the client does not need to pass a signature). Both parties generate the pre master key through PA and Pb due to symmetric encryption (GCM mode of aes128) (or select tls\u rsa\with… According to the server Hello algorithm. Send the third random number, which is encrypted by the public key in the certificate, and is randomly named pre master key. The websites captured here are tls\ecdhe\rsa\with\aes\128\gcm\sha256)

Change cipher spec has completed all negotiations on behalf of the client, and the next data packets will be encapsulated and transmitted using TLS.

The server replies to new session ticket, change cipher spec protocol

Session ticket is used to reconnect the session after TLS interruption

Change cipher spec, on behalf of the server, informs the client that the next message will be transmitted using TLS encryption

Certificate verification:

After the browser obtains the certificate, it will obtain the public key from the certificate of the superior Ca, decrypt the signature signature of the server certificate through the public key, obtain the signature summary information, and calculate the certificate information TBS_ The summary information of certificate (certificate information without signature). Compare the two summary information. If they are the same, the certificate is indeed issued by the superior ca. now it is generally in the form of certificate chain. There are multiple levels of Ca, and each level of Ca is responsible for verifying the subordinate certificate.

Certificate category:

End user: such as baidu Com contains the certificate of the public key used to encrypt the transmitted data. It is the certificate used in HTTPS

Intermediates: the certificate used by CA to authenticate the identity of the public key holder, that is, to confirm that the end-user certificate used by HTTPS belongs to baidu Com. Such intermediates certificates can even have many levels.

Root: the certificate used to verify that the inermedia certificate is a legal certificate.

Certificate chain:

The organizational structure of Ca is a tree structure. A root CAS contains multiple intermediates CAS, and intermediates can contain multiple intermediates CAS. Both root CAS and intermediates CAS can issue certificates to users. The certificates issued are root certificates and intermediates certificates respectively. The certificates used by end users to authenticate public keys are called end-user certificates.

If the private key of intermediates certificates is leaked, or the certificate issued by intermediates certificates becomes untrusted, it will only affect the certificate issued by intermediates certificates, and will not affect the certificates issued under other intermediates certificates. If all certificates are issued by root, their private key is leaked or becomes untrusted, and all certificates issued will be affected.

verification

Manually verify Baidu’s digital certificate using Python:

import hashlib

from cryptography import x509

from cryptography.hazmat.primitives import serialization

import rsa

#Read PEM format data of level 2 Certificate

with open(“rsaenc/rsa1.0/root2.pem”,”rb”) as f:

    ca_bytes = f.read()

#Instance x509 object

ca2 = x509.load_pem_x509_certificate(ca_bytes)

#Return certificate public key object

ca2_pb = ca2.public_key()

#Encoding enumeration member PEM

enum_enc = serialization.Encoding.PEM

#Publicformat enumeration member pkcs1

enum_format = serialization.PublicFormat.PKCS1 

#Serialize public key

ca2_pb_bytes = ca2_pb.public_bytes(enum_enc,enum_format)           

with open(“rsaenc/rsa1.0/baidu.pem”,”rb”) as f:

    ca_bytes = f.read()

cert = x509.load_pem_x509_certificate(ca_bytes)

#Get signature value

signature = cert.signature                                       

signature_int = rsa.transform.bytes2int(signature)

#Deserialize public key

pb = rsa.PublicKey.load_pkcs1(ca2_pb_bytes)

#Decrypt with public key and return large integer

text = rsa.core.decrypt_int(signature_int,pb.e,pb.n)

#Convert large integers to hexadecimal

text = hex(text)

#3031300d060960864801650304020105000420 is the summary algorithm oid,

#Filling method of pkcs1v15, oid+ encryption value combination

text = text.split(“3031300d060960864801650304020105000420”)[1]     

#Get the information of the certificate (except the signature information)

tbs_certificate = cert.tbs_certificate_bytes

#Get hash value of sha256 of certificate

dgst = hashlib.sha256(tbs_certificate).hexdigest()                 

print(text == dgst)