Graphic explanation of how HTTPS works
Posted May 25, 2020 • 8 min read
Target readers:understand the HTTP protocol, symmetric and asymmetric encryption, want to understand the working principle of the HTTPS protocol
After reading this article, you can understand
- What is HTTPS, TLS(SSL), what is the relationship between TLS and HTTPS
- What are certificates and digital signatures and how do they deliver trust
- What kind of functions does HTTPS have and how does it achieve such functions
HTTPS, also known as HTTP over TLS. The predecessor of TLS is SSL, TLS 1.0 is usually marked as SSL 3.1, TLS 1.1 is SSL 3.2, and TLS 1.2 is SSL 3.3. This article focuses on the 1.2 version of the TLS protocol
The following figure describes the relationship between TLS(sub-protocols) and HTTP in the TCP/IP protocol stack
Credit:Kaushal Kumar Panday From:SSL Handshake and HTTPS Bindings on IIS
Among them, Handshake protocol, Change Ciper Spec protocol and Alert protocol constitute SSL Handshaking Protocols.
Compared with HTTPS, HTTPS provides
- Data integrity:content transmission undergoes integrity verification
- Data privacy:the content is symmetrically encrypted, and each connection generates a unique encryption key
- Identity authentication:the third party cannot forge the identity of the server(client)
Among them, data integrity and privacy are guaranteed by TLS Record Protocol, and identity authentication is implemented by TLS Handshaking Protocols.
The SSL handshake process using RSA algorithm is like this
Source:Keyless SSL:The Nitty Gritty Technical Details
- \ [ ]The client sends a random number client \ _random and a list of supported encryption methods
- \ [ ]The server returns a random number server \ _random, the selected encryption method and server certificate chain
- \ [RSA ]The client verifies the server certificate and uses the public key in the certificate to encrypt the premaster secret and send it to the server
- The server uses the private key to decrypt the premaster secret
- The master secret is generated at both ends through client \ _random, server \ _random and premaster secret, which are used to symmetrically encrypt subsequent communication content
So what is a certificate?
What information is included in the certificate
- Certificate information:expiration time and serial number
- Owner information:name, etc.
- Owner's public key
Why server sends certificate to client
There are too many services on the Internet that require certificates to verify identities, so that the client(operating system or browser, etc.) cannot build all the certificates, and the server needs to send the certificate to the client.
Why should the client verify the received certificate
Man in the middle attack
Client <------------ Attacker <------------ Server Forged certificate Intercepting the request
How does the client verify the received certificate
In order to answer this question, a digital signature(Digital Signature) needs to be introduced.
+ --------------------- + | A digital signature | |(not to be confused | | with a digital | | certificate) | + --------- + + -------- + | is a mathematical | ---- Hash ---> | Message Digest | --- Private Key Encryption ---> | Digital Signature | | technique used | + --------- + + -------- + | to validate the | | authenticity and | | integrity of a | | message, software | | or digital document. | + --------------------- +
A piece of text is encrypted by hash and private key to generate a digital signature.
Assume that messaging occurs between Bob, Susan and Pat. Susan sends the message to Bob along with the digital signature. After Bob receives the message, he can verify that the received message was sent by Susan
+ --------------------- + | A digital signature | |(not to be confused | | with a digital | | certificate) | + --------- + | is a mathematical | ---- Hash ---> | Message Summary | | technique used | + --------- + | to validate the | | | authenticity and | | | integrity of a | | | message, software | Yes | or digital document. | Than + --------------------- + | | | + -------- + + --------- + | Digital Signature | --- Public Key Decryption ---> | Message Digest | + -------- + + --------- +
Of course, this premise is that Bob knows Susan's public key. More importantly, like the message itself, the public key cannot be sent directly to Bob in an insecure network.
At this time, a Certificate Authority(CA) was introduced. The number of CAs is not large, and Bob clients have built-in certificates of all trusted CAs. The CA generates a certificate after digitally signing Susan's public key(and other information).
After Susan sends the certificate to Bob, Bob verifies the certificate signature with the public key of the CA certificate.
Bob trusts CA, and CA trusts Susan, which makes Bob trust Susan. This is how the chain of trust(Chain Of Trust) is formed.
In fact, the Bob client built-in is the CA's root certificate(Root Certificate), HTTPS protocol server will send a certificate chain(Certificate Chain) to the client.
TLS protocols include TLS Record Protocol and TLS Handshake Protocol. The flow chart in the overview only concerns the TLS Handshake Protocol.
TLS Record Protocol
In the TLS protocol, there are four seed protocols running on the Record protocol
- Handshake protocol
- Alert protocol
- Change cipher spec protocol
- Application data protocol
Record protocol plays such a role
- At the sending end:segment the data(Record), compress it, add MAC(Message Authentication Code) and encryption
- At the receiving end:decrypt the data(Record), verify the MAC, decompress and reassemble
It is worth mentioning that the Record protocol provides data integrity and privacy guarantee, but the Record type(type) and length(length) are publicly transmitted
The Record Protocol has three connection states(Connection State), the connection state defines compression, encryption and MAC algorithms. All records are processed by the algorithm determined by the current state(Current State).
TLS Handshake Protocol and Change Ciper Spec Protocol will cause the Record Protocol state to switch.
empty state -------------------> pending state ------------------> current state Handshake Protocol Change Cipher Spec
The initial current state(Current State) does not specify encryption, compression, and MAC algorithms. Therefore, before completing a series of actions of TLS Handshaking Protocols, the data of the client and the server are transmitted in clear text; The client and server determine the encryption, compression and MAC algorithms and their parameters, and the data(Record) will be processed by the specified algorithm.
Among them, Record is encrypted first, then add MAC(message authentication code) to ensure data integrity.
TLS Handshaking Protocols
Handshakeing protocols include Alert Protocol, Change Ciper Spec Protocol and Handshake protocol. This article will not detail the Alert Protocol and Change Ciper Spec Protocol.
The handshake process using RSA algorithm is like this(already mentioned in the overview)
Source:Keyless SSL:The Nitty Gritty Technical Details
The client and server exchanged client \ _random and server \ _random in the handshake hello message, using RSA public key encryption to transmit the premaster secret, and finally through the algorithm, the client and the server calculate the master secret separately. Among them, the reason for not using the premaster secret directly is to ensure that the randomness of the secret is not affected by either party.
In addition to using the RSA algorithm to exchange keys on a common channel, the Diffie Hellman algorithm can also be used. The principle of Diffie Hellman algorithm is like this
By Original schema:A.J. Han Vinck, University of Duisburg-Essen SVG version:Flugaal \ [Public domain ], via Wikimedia Commons
The process of exchanging premaster secret using Diffie Hellman algorithm
Source:Keyless SSL:The Nitty Gritty Technical Details
TLS Handshaking Protocols negotiated the algorithm and required parameters used by TLS Record Protocol, and verified the identity of the server; TLS Record Protocol ensured the integrity and privacy of application layer data after negotiation.
The core of the TLS Handshaking Protocol is to pass the premaster secret on an open channel.
Q & A
Why not use asymmetric encryption directly for transmission?
HTTPS can guarantee normal connection?
There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.
The attacker can even directly discard the data packets from both parties
How does the server verify the client's identity?
Via Client Certificate
This message conveys the client's certificate chain to the server; the server will use it when verifying the CertificateVerify message(when the client authentication is based on signing) or calculating the premaster secret(for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm, and any negotiated extensions.
What does the Alert protocol do?
Closure Alerts:Prevent Truncation Attack
In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.
Error Alerts:Error handling
How the master secret is calculated
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
How to calculate encryption, compression and MAC algorithm parameters
Handshaking Protocols make the client and server exchange three parameters:client \ _random, server \ _random and master \ _secret, and generate the parameters required by the algorithm through the following algorithm
To generate the key material, compute key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.`server_random `+ SecurityParameters.`client_random`); until enough output has been generated. Then, the key_block ispartitioned as follows: client_write_MAC_key [SecurityParameters.mac_key_length] server_write_MAC_key [SecurityParameters.mac_key_length] client_write_key [SecurityParameters.enc_key_length] server_write_key [SecurityParameters.enc_key_length] client_write_IV [SecurityParameters.fixed_iv_length] server_write_IV [SecurityParameters.fixed_iv_length]
The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key
Details of TLS handshake using Diffie-Hellman algorithm
- Let s Encrypt
- Session resume
- Certificate Revoke
- TLS1.2 specification:The Transport Layer Security(TLS) Protocol Version 1.2
- PKI specification:Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List(CRL) Profile
- Certificate and digital signature:What is a Digital Signature?
- TLS Handshake:Keyless SSL:The Nitty Gritty Technical Details
If there are errors or other problems, friends are welcome to leave comments and corrections. If you have any help, welcome to like + forward and share.
Welcome everyone to pay attention to the public number of the migrant worker brother:The technical road of the migrant worker brother