TLS/HTTPS handshake — mã hoá, toàn vẹn, xác thực

TL;DR: HTTPS không chỉ là "mã hoá" — TLS giải quyết ba bài toán cùng lúc: mã hoá (không ai đọc được nội dung), toàn vẹn (không ai sửa được byte giữa đường), và xác thực (đúng server bạn muốn nói chuyện). TLS 1.3 thực hiện cả ba chỉ trong 1 RTT — nhanh hơn TLS 1.2 vốn tốn 2 RTT. Cơ chế: asymmetric crypto (chậm, tốn CPU) chỉ dùng để trao đổi khoá; symmetric crypto (nhanh) dùng cho toàn bộ dữ liệu. Khoá trao đổi xong thì bỏ (ephemeral) — đây là forward secrecy: dù sau này khoá private bị lộ, các phiên cũ vẫn không giải mã được.

TLS chạy sau TCP handshake, bên trong kết nối TCP đã mở. Đây là điểm nối trực tiếp với bài TCP 3-way handshake — ba gói SYN/SYN-ACK/ACK xong rồi, TLS mới bắt đầu.

1. Analogy — Thương lượng mã hoá như chọn khoá két sắt

Hình dung bạn cần gửi tài liệu mật cho đối tác, nhưng chưa bao giờ gặp mặt và không có khoá chung:

1. Bạn gửi cho đối tác ổ khoá mở của bạn (public key) — ai cũng thấy được, không sao.
2. Đối tác tạo một khoá két sắt ngẫu nhiên (session key), bỏ vào hộp, khoá bằng ổ khoá của bạn, gửi lại.
3. Chỉ bạn mới có chìa ổ khoá (private key) để mở hộp và lấy khoá két sắt.
4. Từ đây, cả hai dùng cùng khoá két sắt để trao đổi tài liệu — nhanh, đối xứng.

2. Ba bài toán TLS giải quyết

HTTPS không chỉ là "mã hoá dữ liệu". TLS giải quyết ba bài toán riêng biệt mà thiếu bất kỳ cái nào cũng nguy hiểm:

3. TLS 1.3 handshake — cơ chế 1-RTT

TLS 1.3 (RFC 8446, 2018) rút gọn handshake xuống còn 1 RTT bằng cách gửi key share ngay trong ClientHello thay vì chờ server confirm cipher suite trước.

sequenceDiagram
    participant C as Client
    participant S as Server
    Note over C,S: TCP da ESTABLISHED (3-way handshake xong)
    C->>S: ClientHello (TLS versions, cipher suites, key share)
    S-->>C: ServerHello (chosen cipher, key share)<br/>+ Certificate + CertificateVerify + Finished
    Note over C,S: Ca hai tinh duoc session key tu day
    C->>S: Finished
    Note over C,S: TLS ESTABLISHED — HTTP bat dau

Bước 1 — ClientHello (client gửi): Client gửi một gói chứa: (a) danh sách phiên bản TLS client hỗ trợ, (b) danh sách cipher suite ưa thích, (c) key share — phần public của Diffie-Hellman ephemeral key pair mà client vừa tạo. Gửi key share ngay từ đầu là điểm mấu chốt làm TLS 1.3 chỉ cần 1 RTT.

Bước 2 — ServerHello + Certificate + Finished (server gửi, cùng một lần bay): Server chọn cipher suite, gửi lại key share của nó (cũng ephemeral DH). Từ hai key share này, cả hai phía độc lập tính ra cùng session key mà không truyền key qua mạng — đây là phép màu của Diffie-Hellman. Server cũng gửi certificate (chứa public key và danh tính), chữ ký xác nhận nó giữ private key tương ứng, và Finished để đóng phần server của handshake.

Bước 3 — Finished (client gửi): Client xác minh certificate (xem bài 02), xác nhận server Finished hợp lệ, rồi gửi Finished của mình. Từ đây kết nối ESTABLISHED — HTTP request đầu tiên có thể đi kèm luôn gói này.

Tổng cộng: 1 RTT từ ClientHello tới khi HTTP bắt đầu. Mọi dữ liệu sau đó được mã hoá bằng AES-256-GCM (symmetric, nhanh).

4. TLS 1.2 vs 1.3 — tại sao 1 RTT quan trọng

Với RTT trong nước ~20ms, 1 RTT tiết kiệm được 20ms mỗi kết nối mới. Xuyên lục địa RTT 150ms, tiết kiệm 150ms — gần như người dùng cảm nhận được. Trên hệ thống tải cao với hàng triệu kết nối mới mỗi giờ, đây là con số không nhỏ.

TLS 1.2 cũng bị loại bỏ nhiều cipher suite yếu (RSA key exchange không forward secrecy, RC4, 3DES). TLS 1.3 chỉ còn lại các cipher suite mạnh — không còn đường tắt cho kẻ tấn công.

5. Forward secrecy — bảo vệ quá khứ

Forward secrecy (hay Perfect Forward Secrecy — PFS) là tính chất: dù private key của server bị lộ sau này, kẻ tấn công vẫn không giải mã được các phiên cũ đã bị bắt.

Cơ chế: TLS 1.3 bắt buộc dùng ephemeral Diffie-Hellman (ECDHE). Với mỗi phiên kết nối, client và server tạo một cặp khoá DH mới và tạm thời (ephemeral). Session key được tính từ cặp khoá này. Sau khi phiên kết thúc, cặp khoá tạm bị xoá — không lưu ở đâu cả.

Hệ quả: kẻ tấn công ghi lại traffic HTTPS hôm nay với hi vọng sau này lấy được private key của server → vô ích. Session key đã không còn tồn tại.

TLS 1.2 cho phép dùng RSA key exchange không ephemeral — session key được mã hoá bằng public key của server và gửi trực tiếp qua mạng. Ai có private key server là giải mã được mọi phiên cũ. Đây là lý do TLS 1.3 bỏ hoàn toàn RSA key exchange.

6. Session resumption và 0-RTT

Sau khi kết nối TLS đã thiết lập một lần, client và server có thể tái dùng phiên mà không phải chạy lại toàn bộ handshake.

Session resumption (1-RTT): Server cấp cho client một session ticket mã hoá. Lần sau client gửi ticket này kèm ClientHello, server giải mã lấy lại session state và bỏ qua handshake đầy đủ. Vẫn tốn 1 RTT nhưng không phải tính lại key share.

0-RTT Early Data: TLS 1.3 cho phép client gửi dữ liệu ứng dụng ngay trong lần đi đầu tiên (cùng ClientHello), không cần chờ server xác nhận handshake. Giảm xuống còn 0 RTT cho dữ liệu đầu tiên.

7. Pitfall — hiểu nhầm thường gặp

❌ Nhầm 1: "TCP handshake và TLS handshake là một thứ." ✅ Hai handshake riêng biệt, nối tiếp nhau. TCP (SYN/SYN-ACK/ACK) mở kết nối tầng Transport — xảy ra cho cả http:// lẫn https://. TLS chạy sau đó, bên trong kết nối TCP đã mở, chỉ với https://. Trong tcpdump bạn thấy 3 gói TCP trước, rồi mới tới ClientHello. Nhầm hai cái khiến bạn debug sai chặng.

❌ Nhầm 2: "HTTPS chậm hơn HTTP vì phải mã hoá." ✅ Chi phí mã hoá dữ liệu bằng AES-GCM trên CPU hiện đại là không đáng kể (phần cứng có AES-NI). Chi phí thật là handshake (1 RTT) — nhưng nó bị loại bỏ gần hết nhờ keep-alive và session resumption. Đổi lại, HTTP/2 chỉ chạy trên HTTPS và thường làm trang nhanh hơn HTTP/1.1 thuần nhờ multiplexing.

❌ Nhầm 3: "0-RTT an toàn, dùng được cho mọi request." ✅ 0-RTT Early Data thiếu forward secrecy và dễ bị replay. Chỉ an toàn cho GET/HEAD — không dùng cho POST có side effect. Nhiều framework mặc định không bật 0-RTT đúng lý do này.

8. Liên hệ các bài khác

• Bài TCP 3-way handshake: TLS bắt đầu sau khi TCP ESTABLISHED — bài đó giải thích chặng liền trước.
• Bài 02 — Certificate & CA: Trong bước ServerHello, server gửi certificate. Bài 02 giải thích certificate chứa gì, ai ký nó, và trình duyệt tin như thế nào — phần xác thực của TLS.
• Bài 03 — Bộ công cụ debug: curl -v in từng bước TLS handshake, openssl s_client bắt certificate — tools để xem TLS hoạt động thật.
• Khoá Foundations — Điều gì xảy ra khi gõ URL: TLS là chặng 3 trong bản đồ 5 chặng — bài đó cho cái nhìn tổng thể.

9. 📚 Deep Dive — tài liệu gốc

10. Tóm tắt

• TLS giải quyết ba bài toán: mã hoá (confidentiality), toàn vẹn (integrity), xác thực (authentication) — thiếu bất kỳ cái nào là không đủ an toàn.
• Asymmetric crypto (ECDH) chỉ dùng để trao đổi khoá — chậm nhưng an toàn qua mạng. Symmetric (AES-GCM) dùng cho toàn bộ dữ liệu — nhanh.
• TLS 1.3 hoàn thành handshake trong 1 RTT (TLS 1.2 tốn 2 RTT) bằng cách gửi key share ngay trong ClientHello.
• Ephemeral DH (ECDHE) bắt buộc trong TLS 1.3 — mỗi phiên có khoá riêng, không lưu lại → forward secrecy: phiên cũ không bị giải mã dù sau này private key bị lộ.
• Session resumption tái dùng phiên cũ qua session ticket (vẫn 1 RTT). 0-RTT gửi dữ liệu ngay trong ClientHello nhưng dễ bị replay — chỉ dùng cho idempotent request.
• TLS chạy sau TCP handshake, trước HTTP — nhầm thứ tự là debug sai chặng.

11. Tự kiểm tra

Bài tiếp theo: Certificate & CA — vì sao trình duyệt tin một server