Mỗi lần bạn truy cập một trang web có biểu tượng ổ khóa trên thanh địa chỉ, trình duyệt và máy chủ sẽ thực hiện bắt tay TLS để thiết lập kênh mã hóa. Với TLS 1.2, quá trình này mất hai vòng giao tiếp (2-RTT), nghĩa là trình duyệt phải chờ hai lượt gửi-nhận trước khi bắt đầu truyền dữ liệu thật. TLS 1.3 cắt giảm xuống còn một vòng duy nhất (1-RTT), tiết kiệm 30-50% thời gian thiết lập kết nối. Nghe có vẻ nhỏ, nhưng khi nhân lên hàng tỷ kết nối mỗi ngày trên toàn cầu, đây là một bước tiến cực kỳ quan trọng.

Handshake từng bước: ClientHello đến Finished

Bước 1: Client gửi thông điệp ClientHello, chứa danh sách cipher suite mà máy khách hỗ trợ, kèm một key share cho Diffie-Hellman (DH). Đây là điểm khác biệt lớn nhất so với TLS 1.2: thay vì chờ máy chủ chọn thuật toán rồi mới gửi khóa, máy khách gửi luôn key share ngay từ lượt đầu tiên. Nếu server chấp nhận thuật toán mà client đề xuất, cả hai bên có thể tính toán khóa chung ngay lập tức mà không cần thêm vòng giao tiếp nào.

Bước 2: server phản hồi bằng ServerHello, chọn cipher suite và gửi key share của mình. Ngay sau đó, máy chủ gửi tiếp EncryptedExtensions. Đây là thông điệp đầu tiên được mã hóa bằng khóa phiên vừa tạo ra. Từ thời điểm này, mọi thứ trong handshake đều được mã hóa, bao gồm cả chứng chỉ số (certificate) của server. Trong TLS 1.2, chứng chỉ số được gửi dưới dạng bản rõ, nên bất kỳ ai nghe lén cũng biết bạn đang kết nối tới trang web nào.

Bước 3: Cả hai bên gửi thông điệp Finished để xác nhận quá trình bắt tay đã hoàn tất. Sau đó, client có thể gửi dữ liệu ứng dụng, và toàn bộ quá trình chỉ mất 1-RTT.

Tính bảo mật chuyển tiếp là bắt buộc: Không còn RSA tĩnh

TLS 1.2 cho phép sử dụng RSA key exchange, trong đó client mã hóa pre-master secret bằng public key của server. Nếu kẻ tấn công lấy được khóa riêng của máy chủ, chẳng hạn qua một vụ tấn công, lệnh tòa án hoặc rò rỉ, họ có thể giải mã toàn bộ lưu lượng đã bị ghi lại trước đó. TLS 1.3 loại bỏ hoàn toàn RSA key exchange và bắt buộc sử dụng ephemeral Diffie-Hellman (DHE hoặc ECDHE). Mỗi phiên kết nối tạo ra một cặp khóa DH tạm thời, dùng xong là xóa. Ngay cả khi private key dài hạn của server bị lộ, kẻ tấn công vẫn không thể giải mã các phiên cũ. Đây chính là forward secrecy, và trong TLS 1.3, nó không phải tùy chọn mà là yêu cầu bắt buộc.

Cipher suite được giản lược: Từ hàng trăm xuống còn năm

TLS 1.2 hỗ trợ hơn 300 tổ hợp cipher suite khác nhau, nhiều trong số đó đã lỗi thời hoặc có lỗ hổng bảo mật đã biết (RC4, 3DES, CBC mode padding oracle). Sự đa dạng này tạo ra bề mặt tấn công lớn và khiến việc cấu hình an toàn trở nên phức tạp. TLS 1.3 cắt giảm triệt để, chỉ giữ lại các cipher suite sử dụng AEAD (Authenticated Encryption with Associated Data): AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, cùng hai biến thể AES-CCM. Tất cả đều cung cấp đồng thời mã hóa và xác thực toàn vẹn dữ liệu trong một thao tác duy nhất, loại bỏ các lớp tấn công như BEAST, POODLE, và Lucky 13 từng gây nhức nhối cho TLS 1.2.

Khôi phục kết nối 0-RTT: Nhanh hơn, nhưng có đánh đổi

Khi client đã từng kết nối với server trước đó, TLS 1.3 cho phép gửi dữ liệu ứng dụng ngay trong message đầu tiên, không cần chờ phản hồi (0-RTT). Máy chủ cấp cho client một session ticket ở phiên trước, và client dùng nó để mã hóa dữ liệu gửi sớm kèm theo ClientHello ở phiên tiếp theo.

Tuy nhiên, 0-RTT có một rủi ro mà mọi nhà phát triển cần biết: dữ liệu gửi sớm có thể bị phát lại. Kẻ tấn công có thể chặn bắt gói tin 0-RTT và gửi lại cho server, khiến server xử lý cùng một yêu cầu hai lần. Hãy tưởng tượng yêu cầu "chuyển 1.000 USD cho A" bị phát lại, A sẽ nhận được 2.000 USD. Vì lý do này, 0-RTT chỉ nên dùng cho các yêu cầu idempotent như GET hoặc HEAD, tuyệt đối không dùng cho POST hay các thao tác làm thay đổi trạng thái.

Vì sao TLS 1.3 quan trọng với nhà phát triển?

Nếu bạn đang vận hành bất kỳ dịch vụ nào trên internet, TLS 1.3 không chỉ nhanh hơn mà còn "an toàn mặc định" hơn. Nhiều cấu hình yếu từng góp phần dẫn tới các sự cố bảo mật lớn đã bị loại bỏi bỏ khỏi chuẩn mới. SSLv2) đã bị loại bỏi bỏ hoàn toàn khỏi đặc tả. Bạn không thể vô tình chọn sai cipher suite vì không còn cipher suite nào sai để chọn. Hiện tại, mọi trình duyệt hiện đại và phần lớn các thư viện TLS phổ biến (OpenSSL 1.1.1+, BoringSSL, GnuTLS) đều hỗ trợ TLS 1.3 đầy đủ. RFC 8446 đã được phê chuẩn từ tháng 8/2018, và sau gần tám năm, TLS 1.3 đã trở thành tiêu chuẩn thực tế của internet hiện đại.