Cloudflare ra mắt Automatic Key Exchange: giảm HelloRetryRequest từ 52% xuống 3,7%

Cloudflare vừa công bố Automatic Key Exchange (AKE) — một phần mở rộng của Automatic SSL/TLS giúp thay thế việc "đoán mò" thuật toán trao đổi khóa bằng cách đo lường thực tế khả năng của từng máy chủ gốc. Kết quả ban đầu rất ấn tượng: tỷ lệ HelloRetryRequest (HRR) giảm từ khoảng 52% xuống 3,7%, cắt giảm hơn 150 ms độ trễ bắt tay TLS ở mức p90.

Đây không chỉ là câu chuyện về tốc độ. AKE còn đưa hàng trăm nghìn tên miền lên kết nối kháng lượng tử (post-quantum) mà không cần bất kỳ cấu hình thủ công nào — một bước tiến quan trọng trong bối cảnh mối đe dọa "thu thập trước, giải mã sau" (harvest-now, decrypt-later) ngày càng hiện hữu.

Vì sao TLS 1.3 lại phải "đoán" thuật toán khóa?

Sơ đồ bắt tay TLS 1.3 của Cloudflare

Mỗi kết nối web an toàn đều bắt đầu bằng một TLS handshake để xác thực máy chủ và tạo khóa bí mật chung. Khi Cloudflare hoạt động như reverse proxy, một kết nối tưởng chừng đơn lẻ thực chất là hai kết nối: một giữa người dùng với Cloudflare, và một giữa Cloudflare với máy chủ gốc.

Automatic Key Exchange tác động đến kết nối thứ hai. Khi Cloudflare đóng vai trò TLS client, nó phải gửi ClientHello — trong đó có danh sách các thuật toán trao đổi khóa được hỗ trợ — trước khi biết bất cứ điều gì về máy chủ gốc.

• Đoán đúng: handshake hoàn tất chỉ trong một vòng khứ hồi (1 RTT).
• Đoán sai: máy chủ gốc trả về HelloRetryRequest, Cloudflare phải gửi lại ClientHello, tốn thêm một vòng khứ hồi (2 RTT).

Ví dụ dễ hình dung: giống như bạn rẽ nhầm lối trong Mario Kart — vẫn về đích, nhưng mất hết thời gian mà đường tắt lẽ ra tiết kiệm được.

Cái giá của việc "đoán an toàn"

Trong nhiều năm, Cloudflare luôn mặc định gửi X25519 làm keyshare đầu tiên cho mọi máy chủ gốc trên Internet. Chiến lược này an toàn vì hơn 95% máy chủ gốc hỗ trợ X25519, và những máy chủ không hỗ trợ vẫn có thể phản hồi bằng HRR mà không làm hỏng kết nối.

Tuy nhiên, X25519 có thể bị phá bằng máy tính lượng tử. Từ tháng 9/2023, Cloudflare đã quảng bá hỗ trợ trao đổi khóa hậu lượng tử, nhưng chỉ ở dạng "có hỗ trợ" — chứ chưa gửi keyshare thực tế.

Lý do khá kỹ thuật: keyshare X25519MLKEM768 có kích thước lên tới 1.216 byte, so với vỏn vẹn 32 byte của X25519. Điều này đẩy ClientHello vượt qua kích thước một gói mạng duy nhất, và một số middlebox cũ hoặc máy chủ gốc không xử lý nổi ClientHello bị chia thành nhiều gói TCP. Theo khảo sát trước đây của Cloudflare, khoảng 0,34% máy chủ gốc bị lỗi handshake khi nhận keyshare hậu lượng tử đầu tiên.

Vì vậy, trong giai đoạn 2023–nay, Cloudflare dùng HRR như một "van an toàn": chỉ quảng bá hỗ trợ hậu lượng tử, gửi keyshare cổ điển, và buộc máy chủ gốc muốn dùng hậu lượng tử phải yêu cầu qua retry. Cách này an toàn nhưng lại tốn thêm một vòng khứ hồi không cần thiết.

Đáng chú ý, tỷ lệ máy chủ gốc hỗ trợ trao đổi khóa hậu lượng tử đã tăng từ 0,5% lên 12,8% trong khoảng thời gian đó.

Cách Automatic Key Exchange hoạt động

Bảng so sánh các thuật toán trao đổi khóa

Thay vì suy đoán, Cloudflare đo lường trực tiếp. Với mỗi máy chủ gốc hỗ trợ TLS 1.3, hệ thống chạy một loạt handshake nhẹ, mỗi lần chỉ đề xuất đúng một nhóm thuật toán: X25519, P-256, P-384, P-521 hoặc X25519MLKEM768.

Toàn bộ quá trình quét diễn ra ngoài đường truyền lưu lượng thật, nên Cloudflare có thể xác nhận cả máy chủ gốc lẫn hạ tầng mạng ở giữa đều xử lý được thuật toán mạnh hơn trước khi lưu lượng thực sự phụ thuộc vào nó.

Một số điểm đáng chú ý trong thiết kế:

• Đánh giá theo tên miền phụ: Một tên miền thường trỏ đến nhiều máy chủ gốc khác nhau. Cloudflare đánh giá từng tên miền phụ riêng biệt và cân theo lưu lượng thực tế, để một subdomain ít dùng không kéo lùi cả tên miền.
• Thứ tự ưu tiên nghiêm ngặt: Ưu tiên hybrid hậu lượng tử (X25519MLKEM768) trước, sau đó mới đến các thuật toán cổ điển nhanh nhất mà máy chủ gốc chấp nhận.
• Triển khai dần và giám sát: Cấu hình mới chỉ áp dụng cho một phần nhỏ lưu lượng trước. Nếu tỷ lệ HRR tăng vượt ngưỡng cơ sở, hệ thống tự động rollback. Trường hợp xấu nhất chỉ tốn thêm một vòng khứ hồi, không làm hỏng kết nối TLS.
• Quét lại hằng ngày: Cấu hình máy chủ gốc thay đổi liên tục — nâng cấp load balancer, cập nhật thư viện TLS... nên Cloudflare quét lại mỗi ngày để cập nhật ưu tiên mới.

Cấu hình linh hoạt cho doanh nghiệp

AKE bật mặc định cho mọi tên miền hiện có và mới. Phần lớn người dùng không cần làm gì cả. Tuy nhiên, Cloudflare bổ sung cài đặt Compliance requirements phục vụ các tổ chức có yêu cầu tuân thủ nghiêm ngặt:

• Post-quantum hybrid: Chỉ cho phép các thuật toán khóa hậu lượng tử hybrid (X25519MLKEM768). Mọi kết nối TLS 1.3 tới máy chủ gốc đều đảm bảo an toàn lượng tử.
• FIPS (Federal Information Processing Standards): Chỉ cho phép các thuật toán tuân thủ chuẩn FIPS.

Lưu ý quan trọng: Bật cưỡng chế hậu lượng tử trên một máy chủ gốc chưa hỗ trợ X25519MLKEM768 sẽ khiến toàn bộ kết nối TLS 1.3 thất bại, vì không còn thuật toán nào được cả hai bên chấp nhận. Trừ khi bạn có nghĩa vụ chính sách bắt buộc, hãy để cả hai tùy chọn này không được chọn.

Kết quả thực tế sau khi triển khai

Biểu đồ tỷ lệ HelloRetryRequest trước và sau AKE

Với hơn một triệu tên miền đã được gán ưu tiên trao đổi khóa, Cloudflare công bố những con số đáng chú ý:

• 52% → 3,7%: tỷ lệ kết nối gốc phải dùng HRR, giảm hơn 150 ms độ trễ p90.
• 0% → 99,2%: tỷ lệ kết nối TLS 1.3 gốc hậu lượng tử hoàn tất chỉ trong một vòng khứ hồi (không cần HRR).
• 25 tỷ → 45 tỷ: số kết nối gốc hậu lượng tử mỗi ngày.
• ~9.000 tên miền/ngày được đặt ưu tiên trao đổi khóa khác X25519, phần lớn chuyển thẳng sang hậu lượng tử.
• 64% tên miền vẫn giữ X25519 cổ điển, 33% chuyển sang X25519MLKEM768, 3% còn lại chọn đường cong cổ điển khác như P-384, P-256 hoặc P-521.

Một phát hiện thú vị: nhiều máy chủ gốc hỗ trợ nhiều thuật toán mà không ưu tiên thuật toán nào cụ thể. Vì vậy, quan sát thụ động không thể tiết lộ đầy đủ khả năng của máy chủ — chỉ có thăm dò chủ động (active probing) mới phát hiện được hàng nghìn máy chủ gốc có khả năng hậu lượng tử mà lưu lượng thực tế chưa từng thể hiện.

Kiểm tra máy chủ gốc của bạn

Cloudflare cung cấp công cụ miễn phí qua Cloudflare Radar để kiểm tra xem máy chủ có hỗ trợ trao đổi khóa TLS hậu lượng tử hay không. Nhập hostname hoặc địa chỉ IP, công cụ sẽ kiểm tra và đặc biệt còn phát hiện các lỗi triển khai hậu lượng tử — thường bắt nguồn từ middlebox cũ, tường lửa, hoặc buffer máy chủ làm rơi ClientHello bị chia gói.

Nếu máy chủ gốc của bạn chưa hỗ trợ hậu lượng tử, bạn có hai lựa chọn:

1. Dùng Cloudflare Tunnel: kết nối giữa cloudflared và Cloudflare đã dùng trao đổi khóa hậu lượng tử sẵn. Đây là lựa chọn đơn giản nhất.
2. Nâng cấp TLS endpoint: Cập nhật thư viện TLS mới (nhiều framework hiện bật X25519MLKEM768 mặc định). Lưu ý kiểm tra toàn bộ thiết bị kết thúc hoặc kiểm tra TLS — load balancer, thiết bị WAF, middlebox.

Những gì sắp tới

Cloudflare cho biết AKE chỉ là bước thứ hai trong lộ trình dài, không phải điểm kết thúc. Ba hạng mục đang được phát triển:

• Ưu tiên theo từng máy chủ gốc: Hiện tại quyết định ở cấp tên miền. Một máy chủ gốc cấu hình lỗi thời có thể kìm hãm cả tên miền. Cloudflare đang chuyển sang mức chi tiết theo subdomain/origin.
• Quét theo yêu cầu: Cho phép kích hoạt quét lại ngay từ dashboard hoặc API, không phải chờ lịch quét định kỳ. Tính năng này cũng sẽ đóng vai trò công cụ chẩn đoán.
• Xác thực gốc hậu lượng tử tự động: Trao đổi khóa hậu lượng tử bảo vệ lưu lượng hôm nay khỏi bị giải mã trong tương lai, nhưng không ngăn kẻ tấn công dùng máy tính lượng tử giả mạo chứng chỉ máy chủ gốc. Cloudflare dự định mở rộng quét để phát hiện hỗ trợ chứng chỉ ML-DSA, từ đó tự động vô hiệu hóa fallback cổ điển cho khách hàng muốn bảo vệ nghiêm ngặt.

Với mục tiêu biến Internet thành an toàn lượng tử vào năm 2029 — thời điểm mà một số chuyên gia ước tính thuật toán mã hóa cổ điển có thể bị phá vỡ (ngày được gọi là Q-Day) — Cloudflare nhấn mạnh rằng bảo mật mạnh không thể phụ thuộc vào việc hàng triệu chủ website tự trở thành chuyên gia mật mã học. Nó phải diễn ra tự động, mặc định và miễn phí — đúng tinh thần mà Universal SSL từng làm được cho kết nối trình duyệt đến Cloudflare.