Overview
Data transmitted over the internet is segmented by transport-layer
protocols. The most common protocol is TCP (Transmission Control
Protocol).
TCP provides:
- Reliable delivery
- Ordered packet sequencing
- End‑to‑end connectivity
However, TCP does not encrypt payload data. Any attacker with
network access can read the transmitted data.
Sensitive operations---such as payments, messaging, or email---require
confidentiality and integrity. To address this, TCP connections are
secured using SSL/TLS.
What SSL/TLS Provides
SSL (Secure Sockets Layer) and its successor TLS (Transport Layer
Security) add security to TCP connections.
They provide three core guarantees.
Encryption
Encryption prevents third parties from reading transmitted data.
- Data is transformed into ciphertext.
- Only parties with the correct cryptographic keys can decrypt it.
Integrity
Integrity ensures transmitted data cannot be altered in transit.
- Cryptographic hashes detect tampering.
- Modified data is rejected.
Authentication
Authentication verifies the identity of the communicating server.
- Servers present a digital certificate.
- Clients verify the certificate with a Certificate Authority
(CA).
This prevents attackers from impersonating the server.
Where SSL/TLS Is Used
SSL/TLS is commonly used to secure HTTP, producing HTTPS.
Example:
https://example.com
Implications:
- HTTP runs over an encrypted TCP connection.
- All browser--server traffic is encrypted.
- Attackers cannot read or modify the data in transit.
Although most commonly used with HTTP, TLS can secure any TCP-based
protocol, such as:
- SMTP
- IMAP
- FTP
- WebSockets
TLS Connection Lifecycle
A simplified TLS connection consists of three stages:
- TCP handshake
- TLS key exchange
- Encrypted data transfer
Prerequisite: Server Certificate
Before accepting TLS connections, a server must obtain a TLS
certificate.
The certificate contains:
- The server's public key
- Server identity information
- A digital signature from a Certificate Authority (CA)
When clients connect, they verify this certificate against trusted CAs.
If verification fails, the connection is rejected.
Phase 1: TCP Handshake
The client first establishes a standard TCP connection.
Client -> SYN
Server -> SYN/ACK
Client -> ACK
After this three‑way handshake, a TCP connection exists but no
encryption is active yet.
Phase 2: TLS Handshake and Key Exchange
Once TCP is established, TLS negotiates encryption keys.
Simplified flow:
- Client sends ClientHello
- Server responds with:
- ServerHello
- TLS certificate containing its public key
- Client validates the certificate using trusted CAs
- Client generates a pre‑master secret
- Client encrypts this secret using the server's public key
- Server decrypts it using its private key
Both sides derive symmetric session keys from this shared secret.
These keys are used for efficient encryption during the session.
Phase 3: Encrypted Data Transfer
After the TLS handshake:
- Both parties possess shared session keys.
- All application data is encrypted before transmission.
Data flow:
Application Data
↓
TLS Encryption
↓
TCP Segmentation
↓
Network Transmission
The receiver performs the reverse process:
Receive TCP Segment
↓
TLS Decryption
↓
Deliver to Application
Each record includes integrity checks to detect tampering.
Real TLS Implementations
The previous description is simplified.
In practice TLS includes:
- Multiple cryptographic keys
- Cipher suite negotiation
- Perfect Forward Secrecy (PFS)
- Message authentication codes
- Version negotiation and downgrade protection
The protocol evolves to address newly discovered security weaknesses.
SSL vs TLS
Protocol Status
SSL Deprecated
TLS Current standard
Key points:
- SSL is the original protocol.
- TLS replaced SSL and fixed many security issues.
- Modern systems use TLS 1.2 or TLS 1.3.
Despite this, the term "SSL" is still commonly used to refer to TLS
connections for historical reasons.
Member discussion: