Introduction
HTTPS is now widely used for encrypted communication, but even infrastructure engineers may not fully understand how it works. Recently, TLS 1.3 has become prevalent, bringing significant changes to the handshake process and cipher suites compared to earlier versions.
In this article, I will use Wireshark packet capture to examine the communication flow of TLS 1.3 in detail. By doing so, you will gain a deeper understanding of how HTTPS works. Let’s dive in.
Overview of HTTPS Communication with TLS
HTTPS (Hypertext Transfer Protocol Secure) is a mechanism that secures HTTP communication using TLS (Transport Layer Security). Previously, SSL was used, but due to discovered vulnerabilities, TLS has become the standard.
HTTPS communication with TLS provides three main security functions:
1. Confidentiality (Encryption)
Encrypting communication data ensures that third parties cannot understand it even if intercepted. For example, passwords or credit card information entered by users can be transmitted securely.
2. Integrity (Tamper Protection)
TLS verifies that the communication data has not been altered during transmission. Using MAC (Message Authentication Code) or AEAD ciphers (e.g., AES-GCM), any tampering—even a single bit—is detected and discarded.
3. Authentication
Server certificates verify that the connection is established with the intended website, helping prevent phishing attacks. Additionally, client certificates can be used to allow access only to specific users.
Reference: What is HTTPS? Understanding Network Protocols by WireX
Note: In the OSI model, HTTPS is often considered an application layer protocol, while TLS operates at the session and presentation layers.
HTTPS Communication Flow in TLS 1.3
Let’s look at the HTTPS communication flow in TLS 1.3. As shown in the diagram, after establishing a connection via the TCP three-way handshake and the TLS handshake, encrypted communication takes place. Let’s go through the steps in detail.
TCP Three-Way Handshake
In HTTPS communication over TLS, the TCP three-way handshake establishes the connection first. The client and server exchange SYN, SYN/ACK, and ACK packets to set up the communication path.
Using packet capture, you can confirm the communication. By filtering with tcp.stream, you can observe the packets exchanged in order (SYN → SYN/ACK → ACK), verifying that the TCP handshake is correctly established.
TLS Handshake
The TLS handshake handles key exchange, cipher suite negotiation, and server authentication. Here are the steps:
Client Hello
The first handshake message sent from the client to the server. It informs the server of supported cipher suites, signature algorithms, and TLS versions, allowing the server to select appropriate options. The client also sends its public key for key exchange.
Key information included in Client Hello:
Cipher Suites
List of available cipher suites. The server selects one from this list.
signature_algorithms
Algorithms supported for certificate verification and handshake signing.
supported_versions
TLS versions supported by the client (e.g., TLS 1.3 and TLS 1.2).
key_share
The public key used for key exchange.
Server Hello
The server responds with its selected cipher suite and TLS version based on the Client Hello. It also sends its public key for key exchange.
Key information included in Server Hello:
Cipher Suites
Selected cipher suite (e.g., TLS_AES_256_GCM_SHA384).
supported_versions
Selected TLS version (e.g., TLS 1.3).
key_share
Server’s public key for key exchange.
Certificate, Certificate Verify, Finished
The server sends the certificate chain (server certificate, intermediate CA certificate if needed), signs it, and completes the TLS handshake.
Certificate
Proves the server’s authenticity. Typically includes the server certificate and intermediate CA certificate.
Server Certificate Key Details
- Version: Usually X.509 v3.
- Serial Number: Unique ID managed by the CA.
- Signature Algorithm: Algorithm used to sign the certificate (e.g., ecdsa-with-SHA384).
- Issuer: Organization issuing the certificate (e.g., Let’s Encrypt).
- Validity: Certificate’s expiration date.
- Subject: Owner of the certificate (e.g., CN=quiz.eeengineer.com).
- Public Key Info: Public key used for encryption and authentication.
Intermediate CA Certificate Key Details
Version: X.509 v3.
Serial Number: Unique ID.
Signature Algorithm: Signing algorithm (e.g., sha256WithRSAEncryption).
Issuer: Organization issuing the certificate (e.g., ISRG Root X1 by Internet Security Research Group).
Validity: Certificate’s expiration date.
Subject: Name of the intermediate CA.
Public Key Info: Public key for verification.
Certificate Verify
The server signs the handshake messages with its private key to prove possession of the corresponding certificate’s private key. The client verifies the signature using the certificate’s public key.
・Signature
A hash of all handshake messages (ClientHello, ServerHello, Certificate, etc.) signed by the server.
Finished
The final step to verify that the handshake messages were not tampered with.
・Verify Data
HMAC calculated with the Finished key over all handshake messages. Both client and server compare these values to ensure integrity and shared keys.
Finished
The client also responds with a Finished message after receiving the Finished from the server.
On the client side, the Verify Data value is calculated in the same way, and if it matches the value sent from the server, the TLS handshake is complete. From this point onward, application communication data will be exchanged.
・Verify Data
Contains the same value as the data sent from the server.
Conclusion
This concludes the overview of HTTPS communication and the TLS 1.3 handshake. By capturing packets and examining the process with tools like Wireshark, you can concretely understand TLS handshakes and encryption mechanisms. Observing actual data in your environment is the fastest way to deepen understanding.
For more technical details on TLS 1.3 behavior, refer to:
English 
Japanese
コメント