SSL hoạt động như thế nào giữa trình duyệt và Web Server

1. SSL là gì?

SSL (Secure Sockets Layer) hay phiên bản mới hơn là TLS (Transport Layer Security) là một giao thức mã hóa giúp bảo vệ dữ liệu truyền qua mạng internet. Khi bạn truy cập một trang web có https://, nghĩa là website đó đang dùng SSL/TLS để bảo mật kết nối giữa trình duyệt (client)server web (server).

2. Cách SSL hoạt động giữa Trình duyệt và Web server

Quá trình này thường được gọi là SSL/TLS handshake.
Diễn ra theo các bước:

  • Client Hello
    • Trình duyệt gửi một tin nhắn “Xin chào”, kèm theo:
      • Danh sách các giao thức SSL/TLS nó hỗ trợ (ví dụ: TLS 1.3, TLS 1.2…).
      • Các thuật toán mã hóa (cipher suites) nó hỗ trợ.
      • Một số dữ liệu ngẫu nhiên (random data) để bắt đầu phiên.
  • Server Hello
    • Web server phản hồi lại:
      • Giao thức SSL/TLS mà cả 2 cùng hỗ trợ.
      • Thuật toán mã hóa được chọn.
      • Certificate SSL (chứng chỉ số của server).
  • Xác thực Certificate
    • Trình duyệt kiểm tra:
      • Chứng chỉ có được cấp bởi một CA (Certificate Authority) đáng tin cậy không?
      • Chứng chỉ còn hạn không?
      • Tên miền có khớp không?
  • Trao đổi khóa
    • Hai bên dùng kỹ thuật mật mã public key (Public Key Cryptography) để tạo ra Shared Secret (private key chung).
    • Sau đó chuyển sang mã hóa đối xứng cho phiên truyền dữ liệu.
  • Hoàn tất Handshake
    • Hai bên bắt đầu truyền dữ liệu đã mã hóa.

Sơ đồ luồng hoạt động:

Trình duyệt (Client)                         Web Server
      |                                           |
      |---------->  Client Hello (chào + list cipher)   |
      |                                           |
      |<---------  Server Hello (chọn cipher + cert)   |
      |                                           |
      |--- Kiểm tra chứng chỉ ---                 |
      |                                           |
      |----------> Trao đổi khóa mã hóa            |
      |                                           |
      |<---------- Chấp nhận và hoàn tất handshake |
      |                                           |
      |=== Truyền dữ liệu đã mã hóa (HTTPS) ===>   |

3. Các loại hoạt động SSL/TLS hiện nay

3.1. TLS 1.2 handshake (kiểu truyền thống)

  • Gồm nhiều bước trao đổi: Client Hello → Server Hello → Certificate → Key Exchange…
  • Tốn 2 Round-Trip Time (RTT) để hoàn tất.

3.2. TLS 1.3 handshake (tối ưu hơn)

  • Chỉ cần 1 RTT để hoàn tất handshake.
  • Một số trường hợp dùng 0-RTT (nếu đã từng kết nối trước đó) => cực nhanh.

So sánh:

Phiên bản TLSSố lần Round Trip (RTT)Tốc độ
TLS 1.22 RTTChậm hơn
TLS 1.31 RTT (hoặc 0 RTT)Nhanh hơn

4. Mỗi request có phải đều check SSL Handshake lại không?

SSL handshake KHÔNG diễn ra cho mỗi request nếu kết nối TCP/SSL được giữ.
Nếu kết nối TCP giữa clientserver còn sống (Keep-Alive), các request HTTP tiếp theo sẽ dùng chung kết nối đó và không cần thực hiện lại SSL handshake.

Trường hợpSSL handshake lại không?
Cùng kết nối TCP, cùng phiên SSL (Keep-Alive)❌ Không handshake lại
Mỗi lần mở kết nối TCP mới✅ Phải handshake SSL mới

5. Có cơ chế cache SSL không?

SSL/TLS hỗ trợ 2 cơ chế giúp cache thông tin kết nối để lần sau không cần bắt tay SSL đầy đủ nữa:

5.1. Session Resumption (Khôi phục phiên SSL)

Giải thích nôm na:

  • Khi kết nối SSL thành công, server gửi cho client một “Session ID” hoặc “Session Ticket”.
  • Client lưu lại thông tin này.
  • Khi client mở kết nối TCP mới về sau, nó gởi lại Session ID/Session Ticket → server xác nhận nhanh → không cần handshake đầy đủ lại.

➡️ Quá trình handshake lần sau sẽ nhanh hơn rất nhiều vì:

  • Không cần kiểm tra lại certificate.
  • Không cần trao đổi khóa lại từ đầu.

Có 2 dạng cụ thể:

LoạiCách hoạt động
Session IDServer lưu thông tin session, client chỉ nhớ ID.
Session TicketClient lưu trữ toàn bộ thông tin session, server không cần lưu.

Ví dụ dòng lưu Session Resumption trong log:

SSL session reused

5.2. TLS 1.3 0-RTT (Zero Round Trip Time Resumption)

  • Ở TLS 1.3, client còn có thể gửi ngay dữ liệu trong lần đầu tiên của handshake (gọi là 0-RTT).
  • Cực kỳ nhanh cho các hệ thống cần tối thiểu độ trễ.

Nhược điểm:
0-RTT dễ bị Replay Attack nếu không thiết kế kỹ, nên không phải lúc nào cũng bật full.

6. Sơ đồ tóm tắt cơ chế Cache SSL

Lần đầu:
[Client] -> [Server]
Handshake SSL đầy đủ 🔄
-> Server gửi Session ID/Ticket

Lần sau (nếu mở kết nối mới):
[Client] --Session ID--> [Server]
Xác nhận nhanh ✅
Không cần handshake lại!

Một số lưu ý thực tế:

  • Trình duyệt hoặc HTTP client (ví dụ: curl, axios…) quản lý tự động session cache.
  • Server (ví dụ nginx, apache, minio…) phải được bật Session Resumption thì client mới cache được.
  • Kết nối HTTP/2 giúp tối ưu mạnh hơn nữa vì 1 connection chia sẻ nhiều request song song (multiplexing) => SSL handshake rất ít xảy ra.

7. Cách tối ưu SSL trong hệ thống chịu tải lớn (ví dụ như Object Storage)

Ở những hệ thống lớn cần chịu lượng request cực lớn (ví dụ như Amazon S3, MinIO, Ceph Object Gateway…), việc handshake SSL liên tục có thể gây:

  • Tăng độ trễ
  • Hao tốn CPU (vì mã hóa/giải mã)
  • Tắc nghẽn tài nguyên (nhất là SSL handshake chiếm nhiều CPU)

Các cách tối ưu:

a. Sử dụng TLS 1.3

  • TLS 1.3 nhanh hơn TLS 1.2.
  • Chỉ 1 RTT hoặc 0-RTT (nếu client đã từng bắt tay).
  • Hỗ trợ tốt trong hầu hết các trình duyệt hiện đại (Chrome, Firefox, Safari…).

Ví dụ:
Đảm bảo web server/nginx/load balancer bật TLS 1.3.

NGINX config:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_prefer_server_ciphers off;

b. Bật Keep-Alive và Session Resumption

  • Keep-Alive: Giữ kết nối TCP/SSL mở lâu hơn, không phải handshake lại mỗi lần request.
  • Session Resumption: Cho phép client “nhớ” session SSL đã bắt tay trước đó.

Có 2 loại session resumption:

  • Session ID: server gửi session ID, client lưu lại cho kết nối sau.
  • Session Ticket: server gửi session ticket cho client lưu.

Ví dụ minh họa:

Client -> Server: Xin dùng lại Session ID 12345
Server: OK, xác thực nhanh chóng

Trên NGINX bật thế nào?

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets on;

c. Offload SSL lên Load Balancer

  • Thay vì webserver phải tự làm SSL handshake, ta đẩy việc này sang Load Balancer (ví dụ Nginx, HAProxy, AWS ELB, Cloudflare…).
  • Webserver chỉ giao tiếp qua nội bộ (giao tiếp nội bộ có thể không cần SSL hoặc SSL nhẹ).

Sơ đồ ví dụ:

Client --> Load Balancer (SSL termination)
Load Balancer --> WebServer (HTTP hoặc HTTPS nội bộ)

d. Tối ưu cấu hình Cipher Suites

  • Chọn những cipher mạnh và nhanh (ví dụ: AES-GCM, ChaCha20).
  • Bỏ cipher cũ, yếu để giảm tải.

Ví dụ tối ưu Cipher:

ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
ssl_prefer_server_ciphers on;

8. Kết luận

  • SSL là nền tảng bảo mật không thể thiếu khi truyền dữ liệu trên Internet.
  • Cách hoạt động SSL gồm handshake ban đầu để xác thực và trao đổi khóa.
  • Có thể tối ưu thời gian SSL bằng cách:
    • Dùng TLS 1.3
    • Bật Keep-Alive + Session Resumption
    • Offload SSL ra Load Balancer
    • Tối ưu Cipher Suites

✅ Không phải mỗi request đều SSL handshake lại.
✅ Nếu giữ kết nối hoặc dùng Session Resumption, việc check SSL cực nhanh.
✅ Nếu hệ thống có nhiều request, nên:

  • Bật Keep-Alive lâu.
  • Bật SSL Session Resumption.
  • Dùng HTTP/2 hoặc TLS 1.3 để tối ưu mạnh hơn.

Trong các hệ thống lớn như Object Storage, tối ưu SSL đúng cách sẽ giúp tiết kiệm rất nhiều CPU và cải thiện tốc độ phục vụ hàng triệu request mỗi ngày.

Bài viết gần đây

spot_img

Related Stories

Leave A Reply

Please enter your comment!
Please enter your name here

Đăng ký nhận thông tin bài viết qua email