RFC 2818 - HTTP Over TLS (HTTPS)

Status: Informational
Author: E. Rescorla (RTFM, Inc.)
Date: May 2000

Abstract

This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817].

Importance

RFC 2818 is the cornerstone of Web security:

• 🔒 Defines the basic mechanism of HTTPS
• 🌐 Foundation of security for all modern websites
• 🔑 Certificate validation and identity verification
• ⚡ Secure connection establishment and closure

---

1. Introduction

HTTP [RFC2616] was originally used in the clear on the Internet. However, increased use of HTTP for sensitive applications has required security measures. SSL, and its successor TLS [RFC2246] were designed to provide channel-oriented security. This document describes how to use HTTP over TLS.

Core Concept

HTTPS = HTTP + TLS

┌────────────────────────────────────────┐
│         HTTP/1.1 Protocol              │
│    (Application Layer Protocol)        │
├────────────────────────────────────────┤
│         TLS/SSL Protocol               │
│      (Transport Layer Security)        │
├────────────────────────────────────────┤
│         TCP Protocol                   │
│    (Transmission Control Protocol)     │
└────────────────────────────────────────┘

1.1. Requirements Terminology

Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].

---

2. HTTP Over TLS

Core Principle

Conceptually very simple: HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP.

2.1. Connection Initiation

Process:

1. Client → Server: Establish TCP connection (port 443)
2. Client → Server: Send TLS ClientHello
3. ↔ TLS Handshake Process ↔
4. After handshake complete: Client may initiate first HTTP request

Requirements:

• ✅ HTTP client acts as TLS client
• ✅ Connect to appropriate port (default 443)
• ✅ Send TLS ClientHello to begin handshake
• ✅ All HTTP data MUST be sent as TLS "application data"

Example Flow:

Client:
1. TCP connect to www.example.com:443
2. Send ClientHello

Server:
3. Respond ServerHello + Certificate
4. ServerHelloDone

Client:
5. ClientKeyExchange
6. ChangeCipherSpec
7. Finished

Server:
8. ChangeCipherSpec
9. Finished

← TLS Handshake Complete →

Client:
10. Send encrypted HTTP request:
    GET / HTTP/1.1
    Host: www.example.com

2.2. Connection Closure

TLS provides a facility for secure connection closure.

Closure Alert

Definitions:

• Valid Closure: Received proper closure alert
• Incomplete Close: Close connection immediately after sending closure alert
• Premature Close: Connection closed without receiving closure alert

Requirements:

• ✅ Implementations MUST initiate closure alert exchange before closing connection
• ⚠️ Implementations MAY close connection after sending closure alert (without waiting)
• ❌ Connections with premature close MUST NOT reuse session

2.2.1. Client Behavior

Issue: HTTP uses connection closure to signal end of server data.

Client MUST:

• ✅ Treat any premature close as error
• ✅ Treat received data as potentially truncated
• ✅ Send closure alert before closing connection

Special Cases:

1. Response without Content-Length:

HTTP/1.1 200 OK
Content-Type: text/html
[Connection close indicates end]

← Premature close cannot distinguish server from attacker →

2. Content-Length present but not fully read:

HTTP/1.1 200 OK
Content-Length: 1000
[Only 500 bytes received before close]

← Cannot determine if server error or attack →

Exception: If received data matches Content-Length, should treat as complete.

Client Example:

✅ Normal closure:
Client: Send closure_alert
Wait for server closure_alert
Close connection

⚡ Quick closure:
Client: Send closure_alert
Close connection immediately (don't wait)
← This generates incomplete close at server →

2.2.2. Server Behavior

RFC 2616 Requirement: Servers MUST recover gracefully from client closure.

Server SHOULD:

• ✅ Be prepared to receive incomplete close from client
• ✅ Be willing to resume TLS sessions closed in this fashion
• ✅ Attempt to exchange closure alerts with client
• ⚡ MAY close connection after sending closure alert

Implementation Note:

HTTP without persistent connections:
- Server signals end of data by closing connection
- But client may have already sent closure alert and disconnected

2.3. Port Number

Default Port: 443

Rationale:

HTTP server expects: Request-Line (e.g., GET / HTTP/1.1)
TLS server expects: ClientHello

← Cannot distinguish on same port →

Solution: Use different ports
- HTTP: 80
- HTTPS: 443

Examples:

# HTTP (cleartext)
curl http://www.example.com:80/

# HTTPS (encrypted)
curl https://www.example.com:443/

2.4. URI Format

Protocol Identifier: https:// (instead of http://)

Examples:

https://www.example.com/~smith/home.html
https://api.example.com:8443/v1/users
https://192.168.1.1/admin

URI Components:

https://www.example.com:443/path?query#fragment
  ↑         ↑              ↑     ↑     ↑     ↑
scheme    host           port  path  query fragment

---

3. Endpoint Identification

3.1. Server Identity

Core Requirement: Clients MUST verify server identity to prevent man-in-the-middle attacks.

Identity Verification Process

1. Client obtains hostname from URI
   e.g.: https://www.example.com

2. Server provides certificate in TLS handshake

3. Client checks if hostname matches certificate identity

Identity Field Priority

Priority 1: subjectAltName (Subject Alternative Name)

subjectAltName extension in certificate (dNSName type):
dNSName: www.example.com
dNSName: api.example.com

← MUST use this field (if present) →

Priority 2: Common Name

CN in certificate Subject field:
CN=www.example.com

← Only use when no subjectAltName present →
← Deprecated, CAs should use dNSName →

Matching Rules

1. Wildcard Matching:

Certificate: *.example.com
✅ Matches: foo.example.com
❌ Does not match: bar.foo.example.com

Certificate: f*.com
✅ Matches: foo.com
❌ Does not match: bar.com

2. IP Addresses:

URI: https://192.168.1.1/
Certificate must contain: iPAddress subjectAltName
Value must exactly match: 192.168.1.1

3. Multiple Identities:

If certificate contains multiple dNSName:
- www.example.com
- api.example.com
- *.app.example.com

← Matching any one is acceptable →

Behavior When No Match

User-Oriented Clients (browsers):

• ✅ MUST notify user
• ⚠️ MAY give user option to continue
• Or terminate connection

Automated Clients (API clients):

• ✅ MUST log error to audit log
• ✅ SHOULD terminate connection
• ⚠️ MAY provide configuration option to disable check

Security Warning

Untrusted URI Source:

Attack Scenario:
1. User clicks link in HTTP page
2. HTTP page itself is unencrypted
3. Man-in-the-middle may have replaced URI

Protection:
Users should carefully examine server certificate

3.2. Client Identity

Typical Case: Server has no external knowledge of client identity.

If server has external knowledge (from outside HTTP or TLS):

• Should check identity as described above

Client Certificate Authentication:

Common Scenarios:
- Internal enterprise systems
- API access control
- Mutual TLS (mTLS)

Verification:
- Certificate chain rooted in appropriate CA
- Optional: Verify specific client identity

---

Security Considerations

This entire document is about security.

Key Security Points

1. Certificate Validation is Mandatory

   • Clients MUST verify server certificates
   • Prevents man-in-the-middle attacks

2. Proper Connection Closure

   • Use TLS closure alerts
   • Detects data truncation attacks

3. Hostname Verification

   • Prevents certificate substitution attacks
   • Use subjectAltName preferred over CN

4. Beware Untrusted URIs

   • URIs obtained via HTTP may be tampered
   • Users should examine certificates

---

Practical Examples

Complete HTTPS Connection

Client Operations:

1. Parse URI: https://www.example.com/page.html
   → Hostname: www.example.com
   → Port: 443 (default)

2. TCP connect to www.example.com:443

3. TLS Handshake:
   ClientHello →
   ← ServerHello + Certificate
   Verify hostname in certificate
   ...handshake complete...

4. Send encrypted HTTP request:
   GET /page.html HTTP/1.1
   Host: www.example.com

5. Receive encrypted HTTP response:
   HTTP/1.1 200 OK
   Content-Length: 1234
   ...

6. Close connection:
   Send closure_alert
   Close TCP connection

Certificate Verification Example

# Python example (conceptual)
import ssl
import socket

# Create SSL context
context = ssl.create_default_context()

# Connect to server
sock = socket.create_connection(('www.example.com', 443))
ssock = context.wrap_socket(sock, server_hostname='www.example.com')

# wrap_socket automatically verifies:
# 1. Certificate chain is valid
# 2. Hostname matches
# 3. Certificate not expired

# Get certificate information
cert = ssock.getpeercert()
print(f"Subject: {cert['subject']}")
print(f"Issuer: {cert['issuer']}")
print(f"SANs: {cert.get('subjectAltName', [])}")

Common Error Handling

Error 1: Certificate Hostname Mismatch
Certificate Hostname Mismatch
- Certificate: *.example.com
- Accessing: www.different.com
→ Terminate connection or warn user

Error 2: Certificate Expired
Certificate Expired
- Not After: 2023-12-31
- Current: 2024-01-01
→ Refuse connection

Error 3: Self-Signed Certificate
Self-Signed Certificate
- Not in trusted CA list
→ Warn user or refuse

Error 4: Incomplete Certificate Chain
Incomplete Certificate Chain
- Missing intermediate certificate
→ Cannot verify, refuse connection

---

Relationship to Modern Standards

Successors to RFC 2818

While RFC 2818 remains valid, there are updated specifications:

RFC	Title	Description
RFC 2818	HTTP Over TLS	This document (2000)
RFC 5246	TLS 1.2	Updated TLS protocol
RFC 8446	TLS 1.3	Latest TLS protocol
RFC 6125	Certificate Validation	More detailed hostname verification
RFC 7230-7235	HTTP/1.1	Updated HTTP specifications
RFC 7540	HTTP/2	HTTP/2 typically runs over TLS

Modern Practice Updates

1. TLS Versions:

RFC 2818: SSL/TLS (1.0/1.1)
Modern: TLS 1.2+ (TLS 1.0/1.1 deprecated)

2. Certificate Validation:

RFC 2818: Basic rules
RFC 6125: Detailed specifications

3. HSTS:

RFC 6797: HTTP Strict Transport Security
Forces browsers to use HTTPS

---

Quick Reference

HTTPS vs HTTP

Feature	HTTP	HTTPS
Protocol	http://	https://
Port	80	443
Encryption	❌ Cleartext	✅ TLS encrypted
Integrity	❌ No protection	✅ MAC protection
Authentication	❌ No server auth	✅ Certificate auth
Privacy	❌ Can be eavesdropped	✅ Encrypted transmission

TLS Handshake Overview

Client                           Server
  |                                |
  |--- ClientHello --------------->|
  |                                |
  |<-- ServerHello, Certificate ---|
  |<-- ServerHelloDone ------------|
  |                                |
  |--- ClientKeyExchange --------->|
  |--- ChangeCipherSpec ---------->|
  |--- Finished ------------------>|
  |                                |
  |<-- ChangeCipherSpec -----------|
  |<-- Finished -------------------|
  |                                |
  |=== Encrypted Channel =========|
  |                                |
  |--- Encrypted HTTP Request ---->|
  |<-- Encrypted HTTP Response ----|

Common Tools

# OpenSSL view certificate
openssl s_client -connect www.example.com:443 -showcerts

# Test TLS version
openssl s_client -connect www.example.com:443 -tls1_2

# View certificate details
echo | openssl s_client -connect www.example.com:443 2>/dev/null | \
  openssl x509 -noout -text

# cURL use HTTPS
curl -v https://www.example.com

---

References

Normative References

• [RFC 2119] - Key words for use in RFCs to Indicate Requirement Levels
• [RFC 2246] - The TLS Protocol
• [RFC 2459] - Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• [RFC 2616] - Hypertext Transfer Protocol -- HTTP/1.1

Informative References

• [RFC 2817] - Upgrading to TLS Within HTTP/1.1
• [RFC 5246] - The Transport Layer Security (TLS) Protocol Version 1.2
• [RFC 6125] - Representation and Verification of Domain-Based Application Service Identity
• [RFC 6797] - HTTP Strict Transport Security (HSTS)
• [RFC 7230-7235] - Hypertext Transfer Protocol (HTTP/1.1) Updated Specifications
• [RFC 8446] - The Transport Layer Security (TLS) Protocol Version 1.3

---

Glossary

Core Terms

TLS (Transport Layer Security)

• Transport layer security protocol, successor to SSL

SSL (Secure Sockets Layer)

• Predecessor to TLS, now deprecated

Certificate

• Digital document containing public key and identity information

CA (Certificate Authority)

• Certificate authority that issues trusted certificates

Closure Alert

• TLS mechanism for secure connection closure

Premature Close

• Improper TLS connection closure

Man-in-the-Middle Attack

• Attacker intercepts and potentially modifies communication

subjectAltName (Subject Alternative Name)

• Certificate extension specifying additional hostnames

Common Name

• CN field in certificate subject

---

Return: RFC Document List

Related RFCs:

• RFC 7231 - HTTP/1.1 Semantics
• RFC 3986 - URI Generic Syntax
• RFC 2119 - Key Words