Cloudflare nâng cấp bảo mật kết nối nguồn với chuẩn hậu lượng tử ML-DSA

Các tính năng Authenticated Origin Pulls và Custom Origin Trust Store của Cloudflare hiện đã hỗ trợ xác thực hậu lượng tử (post-quantum).

Tại đây, chúng tôi sẽ giải thích cách bạn có thể cấu hình các kết nối TLS xác thực lẫn nhau được bảo mật hoàn toàn bằng hậu lượng tử tới máy chủ gốc (origin server), đi sâu vào các chi tiết kỹ thuật về cách chúng tôi xây dựng hệ thống này, đưa ra một lời thú tội đáng xấu hổ, và cuối cùng giải thích cách công việc này phù hợp với lộ trình chuyển đổi sang hậu lượng tử tổng thể của chúng tôi.

Đạt được một cột mốc quan trọng

Trọng tâm của chúng tôi trong vài năm qua là triển khai mã hóa hậu lượng tử để bảo vệ chống lại các cuộc tấn công "thu thập ngay, giải mã sau" (harvest-now/decrypt-later), trong đó kẻ tấn công âm thầm tích trữ dữ liệu được mã hóa của bạn với hy vọng giải mã nó trong tương lai bằng máy tính lượng tử.

Tuy nhiên, những đột phá gần đây trong điện toán lượng tử và phân tích mật mã đã đẩy nhanh tiến độ nâng cấp lên mật mã hậu lượng tử trên toàn ngành và chính phủ, khiến chúng tôi chuyển hướng sang triển khai xác thực hậu lượng tử để bảo vệ chống lại những kẻ tấn công sắp có khả năng sử dụng máy tính lượng tử để phá vỡ các thông tin xác thực cổ điển và thực hiện các cuộc tấn công giả mạo.

Trong một bài viết trước, chúng tôi đã thông báo rằng Cloudflare đặt mục tiêu đạt được bảo mật hậu lượng tử toàn diện vào năm 2029 và đã vạch ra một số cột mốc cần đạt được trên lộ trình đó. Chúng tôi đã đạt được cột mốc đầu tiên: các sản phẩm Authenticated Origin Pulls và Custom Origin Trust Store hiện hỗ trợ xác thực hậu lượng tử (PQ) thông qua các chữ ký Module-Lattice-Based Digital Signature Algorithm (ML-DSA) để bảo vệ các kết nối giữa Cloudflare và máy chủ gốc của khách hàng.

Kết nối gốc (origin connection) có sự khác biệt

Khi một khách hàng truy cập vào một trang web được proxy bởi Cloudflare, thường có hai kết nối liên quan. Kết nối đầu tiên là từ khách truy cập (ví dụ: trình duyệt) đến Cloudflare. Nếu yêu cầu có thể được phục vụ từ bộ nhớ đệm của Cloudflare hoặc kích hoạt bất kỳ quy tắc chặn nào, Cloudflare có thể phản hồi trực tiếp. Nếu không, Cloudflare sẽ thiết lập kết nối thứ hai đến máy chủ gốc của khách hàng để lấy nội dung được yêu cầu, từ đó phản hồi lại yêu cầu ban đầu.

Việc bảo vệ dữ liệu nhạy cảm của khách truy cập đòi hỏi cả hai kết nối này phải được bảo mật trước các cuộc tấn công lượng tử. Chúng tôi đã kích hoạt hỗ trợ mã hóa hậu lượng tử cho cả kết nối từ khách truy cập đến Cloudflare (Kết nối 1) và từ Cloudflare đến máy chủ gốc (Kết nối 2) lần lượt vào năm 2022 và 2023, và hiện đã ghi nhận mức sử dụng đáng kể.

Chúng tôi đang tích cực hoàn thiện bức tranh này với xác thực hậu lượng tử. Đối với kết nối từ khách truy cập đến Cloudflare, chúng tôi đang hợp tác với Google và các bên khác tại Internet Engineering Task Force (IETF) để phát triển và thử nghiệm Merkle Tree Certificates (MTC), một thiết kế cho các chứng chỉ hậu lượng tử nhanh dành cho web, với các đợt triển khai ban đầu dự kiến vào năm 2027. Tuy nhiên, chủ đề của bài viết này là kết nối từ Cloudflare đến máy chủ gốc, nơi các yêu cầu về xác thực khác biệt so với kết nối từ khách truy cập đến Cloudflare ở một số điểm quan trọng.

Đối với kết nối này, Cloudflare đóng vai trò là máy khách. Điều này cho phép chúng tôi kiểm soát việc sử dụng các kỹ thuật như gộp kết nối (connection pooling) để tập hợp các yêu cầu từ khắp mạng lưới của chúng tôi vào một nhóm kết nối nhỏ hơn tới các máy chủ gốc, giúp phân bổ chi phí thiết lập kết nối cho nhiều yêu cầu. Điều này làm cho chi phí của các chữ ký hậu lượng tử "cắm là chạy" (drop-in) trở nên dễ chấp nhận hơn, và lợi ích hiệu năng của MTC trở nên ít cần thiết hơn.

Và với mối quan hệ tin cậy đã tồn tại từ trước giữa Cloudflare và khách hàng (tức là tài khoản Cloudflare), chúng tôi không cần phải ràng buộc mình vào các hạn chế và lộ trình của cơ sở hạ tầng khóa công khai (PKI) cho Internet công cộng (WebPKI), mà thay vào đó có thể sử dụng các PKI tùy chỉnh phù hợp với trường hợp sử dụng, không bị gánh nặng bởi các chứng chỉ trung gian và Certificate Transparency vốn có thể không áp dụng được. Các giải pháp như Cloudflare Tunnel cũng có thể được sử dụng để bảo vệ kết nối từ Cloudflare đến máy chủ gốc mà không cần nâng cấp các hệ thống gốc cũ, bằng cách chuyển tiếp lưu lượng qua một đường hầm được bảo mật bằng mã hóa hậu lượng tử (và xác thực hậu lượng tử đang được phát triển).

Tóm lại, các yêu cầu độc đáo của kết nối từ Cloudflare đến máy chủ gốc đã cho phép chúng tôi triển khai xác thực hậu lượng tử thông qua ML-DSA trước khi nó được hỗ trợ trong WebPKI cho Internet công cộng. (Đối với những khách hàng vẫn sử dụng WebPKI, đừng lo lắng: chúng tôi sẽ bổ sung hỗ trợ MTC cho kết nối từ Cloudflare đến máy chủ gốc trong tương lai.)

Vậy làm thế nào để bật tính năng này? Hãy cùng đi sâu vào phần cấu hình.

Cấu hình các kết nối gốc được bảo mật hoàn toàn bằng PQ

Chúng tôi đã thêm hỗ trợ ML-DSA (cho tất cả các bộ tham số FIPS 204: ML-DSA-44, ML-DSA-65 và ML-DSA-87) vào các sản phẩm Custom Origin Trust Store và Authenticated Origin Pulls. ML-DSA-44 là khuyến nghị của chúng tôi cho hầu hết các ứng dụng vì đây là tùy chọn hiệu năng cao nhất và đạt được mức độ bảo mật NIST loại 2 thoải mái.

Custom Origin Trust Store

Khi Cloudflare thực hiện kết nối tới máy chủ gốc của khách hàng được cấu hình với chế độ SSL Full (strict), chúng tôi xác thực chứng chỉ gốc dựa trên một kho lưu trữ tin cậy mặc định bao gồm tất cả các Cơ quan cấp chứng chỉ (CA) được tin cậy phổ biến cũng như CA gốc của Cloudflare. Sản phẩm Custom Origin Trust Store (COTS) (yêu cầu bật Advanced Certificate Manager) cho phép khách hàng thay thế kho lưu trữ tin cậy mặc định này bằng một tập hợp các CA do họ kiểm soát. COTS hiện cho phép khách hàng tải lên các CA ML-DSA, để Cloudflare sẽ tin tưởng bất kỳ chứng chỉ máy chủ gốc nào liên kết với CA đó khi kết nối tới máy chủ gốc.

Authenticated Origin Pulls

Để hạn chế lạm dụng và tiêu thụ tài nguyên trên máy chủ gốc, khách hàng có thể chỉ muốn phục vụ các yêu cầu đến từ máy chủ của Cloudflare. Authenticated Origin Pulls (AOP) có thể được sử dụng để cấu hình Cloudflare trình chứng chỉ máy khách tới máy chủ gốc nhằm thiết lập kết nối TLS xác thực lẫn nhau (mTLS), trong đó giao tiếp giữa các bên được bảo mật và tin cậy hai chiều. AOP được cung cấp miễn phí trên tất cả các gói dịch vụ của Cloudflare.

AOP hỗ trợ ba cấp độ cấu hình: toàn cầu (global), theo vùng (per-zone) và theo tên máy chủ (per-hostname). Các cấp độ cấu hình theo vùng và theo tên máy chủ hiện cho phép khách hàng tải lên các chứng chỉ và khóa riêng tư ML-DSA (ở định dạng hạt giống FIPS 204), để máy khách TLS của Cloudflare sẽ trình chứng chỉ này nhằm xác thực chính nó khi kết nối tới máy chủ gốc. (Đừng lo, chúng tôi không quên cấp độ cấu hình toàn cầu — đó chỉ là một thay đổi phức tạp hơn sẽ được ưu tiên vào một ngày sau đó.)

Tránh hạ cấp (downgrade)

Việc thêm hỗ trợ mã hóa và xác thực hậu lượng tử cho cả bên xác thực và bên được xác thực là cần thiết nhưng chưa đủ để đạt được bảo mật hậu lượng tử toàn diện. Vấn đề khó chịu về hạ cấp vẫn còn đó. Nếu bên xác thực hỗ trợ bất kỳ cơ chế xác thực nào dễ bị tấn công bởi lượng tử, họ vẫn mở ra nguy cơ bị tấn công từ kẻ tấn công trên đường truyền có khả năng giả mạo các thông tin xác thực cổ điển.

Giải pháp: bên xác thực phải loại bỏ sự tin tưởng vào các cơ chế xác thực dễ bị tấn công bởi lượng tử. (Điều này tinh tế hơn trong các PKI phức tạp. Ví dụ, hãy xem kế hoạch bốn giai đoạn của nhóm bảo mật Chromium để chuyển đổi Web.) Xem hướng dẫn cấu hình cho AOP và COTS để biết chi tiết về cách đảm bảo máy chủ gốc của bạn được bảo mật trước các cuộc tấn công hạ cấp.

Bắt đầu nhanh

Hướng dẫn dưới đây cho thấy cách tạo chuỗi chứng chỉ ML-DSA và cấu hình cả hai sản phẩm thông qua API của Cloudflare. Để biết hướng dẫn trên bảng điều khiển và bối cảnh bổ sung, hãy tham khảo tài liệu dành cho nhà phát triển.

1. Tạo chứng chỉ

Bạn sẽ cần OpenSSL 3.5.0 trở lên. Khóa riêng tư phải được tạo ở định dạng mã hóa chỉ hạt giống (seed-only) FIPS 204, đây là định dạng duy nhất mà Cloudflare hiện chấp nhận khi tải lên.

Chuỗi chứng chỉ máy chủ gốc cho COTS:

Chuỗi chứng chỉ máy khách Cloudflare cho AOP:

2. Tải CA gốc lên Custom Origin Trust Store

Việc tải lên một CA COTS sẽ thay thế các CA được tin cậy công khai mặc định cho vùng đó. Hãy đảm bảo bạn chỉ tải lên các CA hậu lượng tử nếu bạn muốn tránh các cuộc tấn công hạ cấp.

3. Tải lên chứng chỉ máy khách cho Authenticated Origin Pulls

Ví dụ dưới đây sử dụng AOP cấp vùng. Nếu bạn thích AOP theo tên máy chủ, hãy sử dụng endpoint /origin_tls_client_auth/hostnames/certificates thay thế.

4. Đặt chế độ SSL/TLS của bạn thành Full (strict)

Custom Origin Trust Store chỉ hoạt động khi vùng của bạn đang sử dụng chế độ Full (strict). Nếu bạn đang sử dụng AOP mà không có COTS, chế độ Full hoặc cao hơn là đủ.

5. Cấu hình máy chủ gốc của bạn (trên NGINX)

Nếu bạn đang sử dụng COTS (máy chủ gốc của bạn trình chứng chỉ máy chủ ML-DSA):

Nếu bạn đang sử dụng AOP (máy chủ gốc của bạn xác thực chứng chỉ máy khách của Cloudflare):