Cloudflare ra mắt tính năng tự động trao đổi khóa: Bảo mật hậu lượng tử cho 45 tỷ kết nối mỗi ngày

Mỗi khi Cloudflare mở một kết nối TLS 1.3 mới tới máy chủ gốc (origin server), chúng tôi phải đưa ra một dự đoán: giao thức yêu cầu chúng tôi phải cam kết sử dụng một thuật toán thỏa thuận khóa ngay trong gói tin đầu tiên được gửi đi, trước khi máy chủ gốc kịp cung cấp bất kỳ thông tin nào về bản thân hoặc những gì nó có thể hỗ trợ. Nếu dự đoán đúng, quá trình bắt tay (handshake) sẽ hoàn tất chỉ trong một vòng lặp (round trip). Nếu dự đoán sai, máy chủ gốc sẽ phản hồi bằng một HelloRetryRequest, chúng tôi phải bắt đầu lại từ đầu và kết nối sẽ tốn hai vòng lặp.

Trong nhiều năm, dự đoán của chúng tôi luôn giống nhau cho mọi máy chủ gốc trên Internet: X25519. Đây là thuật toán được hỗ trợ rộng rãi, nhưng hóa ra lại không tối ưu cho khoảng 30% các kết nối tới máy chủ gốc mà chúng tôi đã đo lường kể từ đó.

Hôm nay, chúng tôi công bố Automatic Key Exchange (Thỏa thuận khóa tự động), một phần mở rộng của Automatic SSL/TLS, giúp thay thế việc dự đoán bằng các phép đo thực tế. Chúng tôi thăm dò từng máy chủ gốc để tìm hiểu xem nó hỗ trợ và ưu tiên thuật toán thỏa thuận khóa nào, sau đó sử dụng thuật toán đó ngay trong lần thử đầu tiên, ưu tiên thuật toán lai hậu lượng tử X25519MLKEM768 bất cứ khi nào máy chủ gốc có thể đáp ứng.

Với việc triển khai Automatic Key Exchange trên các kết nối tới máy chủ gốc, tỷ lệ HelloRetryRequest đã giảm từ khoảng 52% xuống còn 3,7%, giúp cắt giảm hơn 150 ms độ trễ bắt tay kết nối ở mức p90. Ngoài ra, như một phần trong quá trình triển khai liên tục, hàng trăm nghìn tên miền hiện đã có các kết nối hậu lượng tử tới máy chủ gốc mà không cần bất kỳ ai phải cấu hình, và con số này đang tăng lên mỗi ngày.

Mặc dù các mili giây rất quan trọng, nhưng phần thứ hai có lẽ còn quan trọng hơn. Ở đâu đó ngay lúc này, một kẻ tấn công đang ghi lại lưu lượng truy cập được mã hóa mà nó chưa thể đọc được, với hy vọng rằng trong tương lai nó sẽ làm được (một cuộc tấn công được gọi là "thu thập ngay, giải mã sau" - harvest-now, decrypt-later). Cloudflare đang chạy đua để làm cho Internet trở nên an toàn trước lượng tử vào năm 2029, năm mà một số chuyên gia trong ngành ước tính các thuật toán mã hóa cổ điển có thể bị bẻ khóa. Ngày đó có một cái tên: Q-Day. Việc đạt được thời hạn này không thể phụ thuộc vào việc hàng triệu nhà vận hành trang web phải trở thành chuyên gia mật mã học. Nó phải được thực hiện tự động. Cho đến hôm nay, việc ưu tiên các kết nối hậu lượng tử đòi hỏi phải cài đặt thủ công: hoặc bạn bật chúng từ phía Cloudflare, hoặc bạn yêu cầu máy chủ gốc của mình bắt buộc sử dụng chúng. Rất dễ xảy ra sai sót. Nhưng hôm nay, mọi thứ đã trở nên… tự động!

Bắt tay TLS 1.3: dự đoán thuật toán trao đổi khóa

Mọi kết nối web bảo mật đều bắt đầu bằng một quá trình bắt tay TLS, giúp xác thực máy chủ và tạo ra một khóa bí mật chung. Các bài viết blog trước đây của chúng tôi về Automatic SSL/TLS đã đề cập chi tiết về quy trình này.

Vì Cloudflare hoạt động như một reverse proxy, những gì trông giống như một kết nối bảo mật duy nhất thực chất lại là hai kết nối: một giữa khách truy cập và Cloudflare, và kết nối thứ hai giữa Cloudflare và máy chủ gốc. Mỗi kết nối hoạt động độc lập với quá trình bắt tay, kiểm tra danh tính và khóa mã hóa riêng.

Automatic Key Exchange ảnh hưởng đến kết nối thứ hai. Khi Cloudflare kết nối với máy chủ gốc, Cloudflare đóng vai trò là TLS client và phải bắt đầu quá trình bắt tay. Chúng tôi khởi tạo kết nối bằng cách gửi thông điệp ClientHello chứa tên máy chủ (hostname) và danh sách các thuật toán thỏa thuận khóa được hỗ trợ.

Trong trường hợp thuận lợi, TLS 1.3 có thể thiết lập một kết nối mã hóa mới chỉ trong một vòng lặp mạng (hiển thị ở bên trái trong sơ đồ trên). Trong trường hợp này, Cloudflare gửi một ClientHello liệt kê các thuật toán thỏa thuận khóa được hỗ trợ, cùng với một hoặc nhiều keyshare của client. Nếu máy chủ gốc chấp nhận lựa chọn đó, nó sẽ phản hồi và quá trình bắt tay hoàn tất. Việc trao đổi khóa dự đoán này là một cải tiến của TLS 1.3 và là lý do chính khiến nó nhanh hơn TLS 1.2.

Ngược lại, nếu máy chủ gốc ưu tiên một tùy chọn khác, nó sẽ gửi một HelloRetryRequest (HRR) và yêu cầu Cloudflare thử lại (quy trình ở bên phải trong sơ đồ trên). Sau đó, Cloudflare gửi một ClientHello thứ hai, tạo ra một keyshare client mới dựa trên thuật toán thỏa thuận khóa do máy chủ gốc chỉ định. Kết nối vẫn thành công, nhưng việc thử lại này làm tăng thêm một vòng lặp mạng đầy đủ trước khi Cloudflare có thể lấy nội dung. Điều này giống như việc bỏ lỡ một lối tắt trong Mario Kart: bạn vẫn về đích, nhưng bạn mất đi khoảng thời gian mà lối tắt đó lẽ ra đã giúp bạn tiết kiệm.

Dù bằng cách nào, sử dụng keyshare của client, máy chủ sẽ tạo ra khóa chung. Sau đó, máy chủ trả về một keyshare của server để client cũng có thể tính toán khóa chung. Khóa chung này được sử dụng để bảo vệ phần còn lại của kết nối bằng mật mã đối xứng, chẳng hạn như AES.

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

Trong nhiều năm, dự đoán keyshare client ban đầu của chúng tôi cho các kết nối tới máy chủ gốc sử dụng TLS 1.3 là tĩnh; chúng tôi luôn gửi X25519 trong khi vẫn quảng bá hỗ trợ cho các thuật toán thỏa thuận khóa khác. Đây là một chiến lược an toàn vì hơn 95% các máy chủ gốc hỗ trợ X25519, và bất kỳ máy chủ gốc nào không hỗ trợ đều có thể gửi HelloRetryRequest (HRR) mà không làm gián đoạn kết nối.

Tuy nhiên, X25519 dễ bị tổn thương trước máy tính lượng tử. Kể từ tháng 9 năm 2023, chúng tôi đã quảng bá hỗ trợ thỏa thuận khóa hậu lượng tử cho các máy chủ gốc: ban đầu là X25519Kyber768Draft00 và ngày nay là X25519MLKEM768 (phiên bản chuẩn hóa của thuật toán). Điều quan trọng là việc quảng bá hỗ trợ khác với việc dẫn đầu bằng một keyshare trong ClientHello. Một keyshare X25519MLKEM768 có kích thước 1.216 byte so với 32 byte của X25519, khiến ClientHello vượt quá một gói tin mạng duy nhất. Mặc dù chuẩn TLS cho phép các phân đoạn đa gói tin, một số middlebox và máy chủ gốc cũ có thể gặp lỗi khi nhận các thông điệp ClientHello bị chia tách thành nhiều gói. Trong nghiên cứu trước đây của chúng tôi, khoảng 0,34% các máy chủ gốc được quét đã không thể hoàn tất quá trình bắt tay TLS khi nhận keyshare hậu lượng tử trước, trong khi đại đa số các máy chủ gốc vẫn dựa vào X25519 cổ điển.

Do đó, để ngăn chặn bất kỳ sự cố kết nối nào có thể xảy ra, chúng tôi đã sử dụng HRR như một van an toàn. Chúng tôi chỉ quảng bá hỗ trợ hậu lượng tử, gửi một keyshare X25519 cổ điển và yêu cầu các máy chủ gốc có khả năng phải yêu cầu trao đổi hậu lượng tử thông qua việc thử lại. Đối với các máy chủ gốc không hỗ trợ quy trình HRR, khách hàng có tùy chọn thủ công để ưu tiên sử dụng keyshare X25519MLKEM768. Từ năm 2023 đến nay, tỷ lệ các máy chủ gốc hỗ trợ thuật toán thỏa thuận khóa hậu lượng tử đã tăng từ 0,5% lên 12,8%, và chúng tôi hy vọng con số này sẽ tiếp tục tăng khi các hạ tầng lưu trữ nâng cấp lên các thuật toán an toàn với PQ.

Mặc dù an toàn, việc mặc định chỉ nâng cấp lên các kết nối an toàn hậu lượng tử thông qua thử lại đã làm tăng độ trễ không cần thiết vì hai lý do:

Để loại bỏ những vòng lặp lãng phí này, chúng tôi bắt đầu quét các máy chủ gốc để lập bản đồ chính xác khả năng thỏa thuận khóa của chúng như một phần của Automatic SSL/TLS. Sử dụng kết quả quét này, chúng tôi tự động điều chỉnh keyshare ban đầu trên cơ sở từng máy chủ gốc: tối đa hóa các kết nối hậu lượng tử mà không gây rủi ro gián đoạn trang web, đồng thời làm cho kết nối của chúng tôi nhanh hơn đối với các tên miền áp dụng.

Mở rộng Automatic SSL/TLS sang kỷ nguyên hậu lượng tử

Automatic SSL/TLS hiện đã bao gồm Automatic Key Exchange. Trên hàng triệu máy chủ gốc, việc dự đoán các keyshare khác nhau mang lại rủi ro vận hành, vì chúng tôi không biết trước cách cấu hình của từng máy chủ gốc riêng lẻ. Vì vậy, thay vì suy luận khả năng, chúng tôi đo lường trực tiếp, tái sử dụng quy trình quét vốn đã hỗ trợ Automatic SSL/TLS.

Đối với ngày càng nhiều máy chủ gốc, điều này mang lại thỏa thuận khóa hậu lượng tử ngay trong lần thử đầu tiên thiết lập kết nối, không cần thêm vòng lặp và không cần bất kỳ thiết lập thủ công nào.

Cách thức hoạt động như sau:

Đối với hầu hết khách hàng, không có gì cần cấu hình. Nếu máy chủ gốc của bạn hỗ trợ TLS 1.3, chúng tôi sẽ tự động thương lượng thuật toán trao đổi khóa mạnh nhất mà nó hỗ trợ, ví dụ: nếu máy chủ gốc hỗ trợ X25519MLKEM768, Cloudflare sẽ ưu tiên nó và có thể thiết lập thỏa thuận khóa hậu lượng tử mà không có thêm độ trễ vòng lặp nào.

Cấu hình Automatic Key Exchange

Automatic Key Exchange được kích hoạt mặc định cho tất cả các tên miền hiện có và tên miền mới, không yêu cầu thao tác thủ công đối với hầu hết các thiết lập. Nếu muốn, bạn có thể quản lý các cài đặt này một cách độc lập trong bảng điều khiển Cloudflare tại mục SSL/TLS > Overview > Configure > Origin connection & post-quantum encryption.

Khi bật nút gạt Automatic Key Exchange, Cloudflare sẽ quét các máy chủ gốc của bạn ngoài băng tần (out-of-band) và dẫn đầu bằng một keyshare được chọn linh hoạt. Khi tắt, quá trình quét sẽ dừng lại và Cloudflare quay trở lại thứ tự thỏa thuận khóa mặc định cố định/tĩnh.

Chúng tôi cũng đã giới thiệu một cài đặt Compliance requirements (Yêu cầu tuân thủ) mới trong Automatic Key Exchange. Bạn có thể lọc các thỏa thuận khóa mà Cloudflare được phép sử dụng và quảng bá hỗ trợ cho các kết nối tới máy chủ gốc. Khi được cấu hình, Automatic Key Exchange và tất cả lưu lượng truy cập hướng tới máy chủ gốc sẽ tuân thủ nghiêm ngặt các quy tắc này:

Việc chọn cả hai tùy chọn yêu cầu một thuật toán đáp ứng đồng thời cả hai tiêu chí; nếu không có thỏa thuận khóa nào trùng khớp, cấu hình sẽ bị từ chối. Xem tài liệu Automatic Key Exchange để biết chi tiết.

Bằng cách chọn các tùy chọn này, bạn cấu hình mục đích của mình thay vì các thuật toán cụ thể. Điều này đảm bảo rằng khi các tiêu chuẩn tuân thủ phát triển hoặc các thuật toán hậu lượng tử mới xuất hiện, cấu hình của bạn sẽ tự động được cập nhật.

Tuy nhiên, cần tiếp cận các yêu cầu này một cách cẩn thận. Chúng không cấp cho máy chủ gốc các khả năng mật mã mới, chúng chỉ thu hẹp những gì Cloudflare có thể thương lượng.

Một lưu ý quan trọng: Việc ép buộc sử dụng lai hậu lượng tử trên một máy chủ gốc thiếu hỗ trợ X25519MLKEM768 sẽ không để lại thuật toán nào được hỗ trợ chung, khiến tất cả các kết nối TLS 1.3 bị lỗi. Trừ khi bạn có nghĩa vụ chính sách nghiêm ngặt về việc ép buộc trao đổi hậu lượng tử hoặc tuân thủ FIPS trên mọi kết nối, hãy để cả hai tùy chọn không được chọn và cho phép Automatic Key Exchange thương lượng các thuật toán tối ưu một cách an toàn cho bạn.

Cùng nhau làm cho Internet an toàn và nhanh hơn

Automatic Key Exchange hoạt động cho các tên miền có máy chủ gốc hỗ trợ TLS 1.3 (vì dự đoán phương thức thỏa thuận khóa ưu tiên là tính năng chỉ có trên TLS 1.3). Nó được bật theo mặc định và quy trình quét của chúng tôi đã gán các tùy chọn trao đổi khóa cho hơn một triệu tên miền trong khi việc đăng ký vẫn tiếp tục trên phần còn lại của mạng lưới.

Từ nhóm ban đầu đó, chúng tôi nhận thấy khoảng 64% trong số đó vẫn giữ X25519 cổ điển làm tùy chọn ưu tiên, vì vậy không có gì thay đổi về kết nối của họ. Khoảng 33% trong số đó hiện đã đặt tùy chọn ưu tiên là X25519MLKEM768, giúp lưu lượng truy cập đến các máy chủ gốc đó được bảo vệ khỏi các cuộc tấn công lượng tử "thu thập ngay, giải mã sau" chỉ trong một vòng lặp. 3% còn lại đã chọn một đường cong cổ điển khác mà máy chủ gốc của họ ưu tiên, chẳng hạn như P-384, P-256 hoặc P-521.

Khoảng 9.000 tên miền mỗi ngày được đặt tùy chọn thỏa thuận khóa sang một phương thức khác ngoài X25519. Hầu hết trong số này chuyển trực tiếp sang ưu tiên trao đổi khóa hậu lượng tử, trong khi số còn lại áp dụng các đường cong cổ điển khác được hỗ trợ tốt hơn bởi cấu hình TLS của máy chủ gốc.

Như chúng tôi đã đề cập trước đó, trước khi có Automatic Key Exchange, hầu như mọi quá trình bắt tay hậu lượng tử với máy chủ gốc đều yêu cầu HelloRetryRequest (HRR) vì dự đoán tĩnh ban đầu của chúng tôi mặc định là X25519 cổ điển. Kết quả là các kết nối hậu lượng tử phải trả giá bằng một vòng lặp thứ hai bắt buộc trước khi hoàn tất quá trình bắt tay TLS.

Với việc triển khai đang diễn ra, hình phạt về độ trễ đó gần như đã biến mất đối với hầu hết các máy chủ gốc có khả năng hậu lượng tử: 99,2% các kết nối TLS 1.3 hậu lượng tử của nhóm các máy chủ gốc được quét hiện nay hoàn tất trong một vòng lặp duy nhất. Ngoài việc loại bỏ vòng lặp bổ sung, chúng tôi thấy rằng trên nhóm đó, lưu lượng truy cập hậu lượng tử tới máy chủ gốc tiếp tục tăng từ khoảng 25 tỷ kết nối lên 45 tỷ mỗi ngày. Một phần đáng kể của sự tăng trưởng đó đến từ việc Automatic Key Exchange nâng cấp các kết nối cổ điển lên tùy chọn hậu lượng tử cho các máy chủ gốc đã được quét.

Nhiều máy chủ gốc hỗ trợ nhiều thuật toán thỏa thuận khóa mà không ưu tiên thuật toán nào hơn thuật toán nào. Ví dụ, một máy chủ gốc hỗ trợ thỏa thuận khóa hậu lượng tử vẫn có thể chấp nhận một keyshare cổ điển (X25519) mà không từ chối hoặc gửi HRR. Do đó, quan sát thụ động không thể tiết lộ toàn bộ khả năng của máy chủ gốc. Việc thăm dò chủ động đã cho phép Automatic Key Exchange khám phá ra hàng nghìn máy chủ gốc mà khả năng hỗ trợ hậu lượng tử của chúng chưa bao giờ xuất hiện trong lưu lượng truy cập gốc.

Khi máy quét của chúng tôi phát hiện ra các máy chủ gốc như vậy và cập nhật tùy chọn keyshare client của chúng, các kết nối hậu lượng tử nhanh chóng chiếm phần lớn lưu lượng truy cập đến các máy chủ gốc này. Các thuật toán thỏa thuận khóa cổ điển khác chiếm tỷ trọng nhỏ hơn nhiều đối với các tên miền đã nâng cấp này, chủ yếu do các thiết lập đa máy chủ gốc với sự kết hợp của các backend hậu lượng tử và chỉ hỗ trợ cổ điển. Automatic Key Exchange làm được nhiều điều hơn là chỉ thúc đẩy việc áp dụng hậu lượng tử. Nó còn giúp ghép nối các máy chủ gốc với đường cong cổ điển ưu tiên của chúng (ngoài X25519), làm giảm tỷ lệ HRR tổng thể trên tất cả các máy chủ gốc được quét.