How HTTPS works

Target Audience: Understand HTTP protocols, symmetric and asymmetric encryption, and want to understand how the HTTPS protocol works

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 functionality does HTTPS have, and how does it implement such a feature

Brief introduction

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. This article focuses on the 1.2 version of the TLS protocol

Describes the relationship between TLS (each sub-protocol) and HTTP in the TCP/IP protocol stack

Credit:kaushal Kumar Panday from:ssl handshake and HTTPS Bindings on IIS

Where handshake Protocol,change ciper SPEC Protocol and alert protocol make up the SSL handshaking protocols.

The 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.

General overview

The SSL handshake process using the RSA algorithm is like this

Source:keyless ssl:the Nitty Gritty Technical Details

1. [Clear text] client sends a list of random numbers client_random and supported encryption methods
2. [Clear text] The server returns server_random a random number, the encryption method selected and the server certificate chain
3. [RSA] Client Authentication server certificate, using public key encryption in the certificate to send to the premaster secret service side
4. Service side uses private key decryptionpremaster secret
5. Each end client_random is passed, server_random and premaster secret generated master secret , for symmetric encryption of subsequent communication content

Certificate (Digital Certificate)

So what is a certificate?

What information is included in the certificate

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

Why the server sends 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.

Why clients want to verify the received certificate

Middleman attack

客户端<------------攻击者<------------服务端        伪造证书            拦截请求

How the client validates the received certificate

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

+---------------------+| A digital signature ||(not to be confused ||with a digital ||certificate) | +---------+ +--------+| is a mathematical |----哈希--->| 消息摘要 |---私钥加密--->| 数字签名 ||technique used | +---------+ +--------+|to validate the ||authenticity and ||integrity of a ||message, software ||or digital document. |+---------------------+

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

+---------------------+| A digital signature ||(not to be confused ||with a digital ||certificate) | +---------+| is a mathematical |----哈希--->| 消息摘要 ||technique used | +---------+|to validate the | ||authenticity and | ||integrity of a | ||message, software | 对|or digital document. | 比+---------------------+ | | | +--------+ +---------+ | 数字签名 |---公钥解密--->| 消息摘要 | +--------+ +---------+

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 to make Bob Trust Susan, and this is how 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.

TLS protocol

The TLS protocol includes TLS Record Protocol and TLS handshake Protocol. The flowchart in the overview involves only TLS handshake Protocol.

TLS Record Protocol

In the TLS protocol, there are four seed protocols running on record protocol

• Handshake Protocol
• Alert protocol
• Change Cipher Spec protocol
• Application Data Protocol

The Record protocol played such a role

• On the send side: Segment Data (Record), compress, add Mac (Message authentication Code) and encrypt
• On the receiving side: Decrypt the data (Record), verify the Mac, unzip and reorganize

It is worth mentioning that the record protocol provides data integrity and privacy guarantees, but the record type (type) and length are publicly transmitted

The Record protocol has three connection states (Connection state), and the connection state defines the compression, encryption, and Mac algorithms. All the record is processed by an algorithm determined by the current state.

TLS Handshake Protocol and Change Ciper Spec protocol cause record protocol state switching.

empty state -------------------> pending state ------------------> current state             Handshake Protocol                Change Cipher Spec

The initial current state does not specify encryption, compression, and Mac algorithms, so the client and server data are transmitted in plaintext before the TLS handshaking protocols a series of actions, and when TLS completes the handshake process, The client and server determine the encryption, compression, and Mac algorithms and their parameters, and the data (Record) is processed by the specified algorithm.

Where the record is first encrypted and then added to the MAC (message authentication code) to ensure data integrity.

TLS handshaking Protocols

Handshakeing protocols includes alert Protocol,change Ciper Spec Protocol and handshake Protocol. The alert Protocol and change Ciper Spec Protocol are not described in detail in this article.

The handshake process using the RSA algorithm is like this (already mentioned in the overview)

Source:keyless ssl:the Nitty Gritty Technical Details

The client and the server end up in the handshake hello message in plaintext Exchange client_random and server_random , using RSA public key encrypted transmission premaster secret , and finally through the algorithm, the client and the service side are computed separately master secret . Among them, the reason that does not use directly premaster secret is: Ensure the randomness of secret is not affected by either party.

In addition to using the RSA algorithm to exchange keys in the public channel, you can also pass the Diffie–hellman algorithm. The principle of the Diffie–hellman algorithm is this

by Original SCHEMA:A.J Han Vinck, University of Duisburg-essen SVG Version:flugaal [public domain], via Wikimedia Commo Ns

Processes exchanged using the Diffie–hellman algorithm premaster secret

Source:keyless ssl:the Nitty Gritty Technical Details

Summary

TLS handshaking protocols negotiates the algorithm and required parameters used by the TLS record protocol and verifies the service-side identity, and the TLS record protocol guarantees the integrity and privacy of the application-tier data after negotiation.

The core of TLS handshaking protocol is passed on the open letter path premaster secret .

Q&a Why is the transmitted content not directly using asymmetric encryption?

Performance

Does HTTPS guarantee a normal connection?

No

There is a number of ways in which a man-in-the-middle attacker can attempt to make both entities drop down to the least s Ecure method they support.

Attackers can even discard both packets directly

How does the server verify client identity?

Via Client Certificate

This message conveys the client's certificate chain to the server; The server would use it when verifying the certificateverify message (when the client authentication was based on signing) O R Calculating the premaster secret (for Non-ephemeral Diffie-hellman). The certificate must is appropriate for the negotiated cipher suite's key exchange algorithm, and any negotiated extension S.

What's the role of Alert protocol?

Closure Alerts: Preventing truncation Attack

In a truncation attack, an attacker inserts to 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 have a closing handshake, so the recipient knows the message had not ended Unti L This has been performed.

Error Alerts: Wrong handling

How the master secret is calculated

  master_secret = PRF(pre_master_secret, "master secret",                      ClientHello.random + ServerHello.random)                      [0..47];

How encryption, compression, and Mac algorithm parameters are calculated

The handshaking protocols allows the client and the server to exchange three parameters: client_random , server_random and Master_secret, to generate the parameters required by the algorithm using 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 are then split to a client write MAC key, a server wri Te MAC Key, a client write encryption key, and a server write encryption key

TLS handshake details using the Diffie-hellman algorithm

source:https://cipherstuff.wordpress.com/

Expand Reading

• Keyless
• Let ' s Encrypt
• Session Resume
• Certificate Revoke

Reference links

1. TLS1.2 specification: The Transport Layer Security (TLS) Protocol Version 1.2
2. Certificates and Digital signatures: What is a digital Signature?
3. TLS handshake:keyless ssl:the Nitty Gritty Technical Details
4. Https:https://cattail.me/tech/2015/11/30/how-https-works.html

How HTTPS works