Sự thật về HTTP/3: Giải mã xung đột Tường lửa, Rule cũ và lựa chọn Cloudflare.

Ở bài viết trước, chúng ta đã cùng phân tích kiến trúc của HTTP/3 và những lợi ích to lớn của nó dưới góc độ bảo mật (QUIC, TLS 1.3). Lý thuyết là vậy, ngập tràn màu hồng. Nhưng khi thực sự xắn tay áo lên gõ lệnh để cấu hình HTTP/3 cho một hệ thống đang chạy thật bằng Nginx hay OpenResty, mới thấy đời không như là mơ. Bài viết này sẽ bỏ qua các khái niệm giáo điều, chúng ta sẽ đi thẳng vào điều kiện của giao thức HTTP/3 và trở ngại trong triển khai, những cú vấp ngã thực tế từ tường lửa, xung đột với WAF (ModSecurity) và câu hỏi muôn thuở: "Tự làm hay nhờ Cloudflare gánh?".

Điều kiện "cốt lõi" để Server lên HTTP/3

Để một máy chủ Nginx/OpenResty có thể "nói chuyện" bằng HTTP/3 với trình duyệt, bạn cần thỏa mãn một combo điều kiện khắt khe sau:

• Nền tảng Web Server hỗ trợ QUIC: Bạn không thể dùng các bản Nginx cũ. Bắt buộc phải dùng Nginx Mainline từ 1.25.0 trở lên (nơi QUIC đã được merge vào core), hoặc nếu dùng OpenResty, bạn phải tự biên dịch (compile) từ mã nguồn với cờ --with-http_v3_module và liên kết với thư viện mã hóa hỗ trợ QUIC (như quictls, BoringSSL).

• Giao thức bảo mật TLS 1.3: HTTP/3 được sinh ra gắn liền với TLS 1.3. Nếu file config của bạn chỉ có TLSv1.2, HTTP/3 sẽ từ chối hoạt động.

• Header quảng cáo Alt-Svc (Alternative Services): Khác với các bản cập nhật trước, trình duyệt sẽ không tự động dùng HTTP/3 trong lần truy cập đầu tiên vì nó được mặc định gọi qua TCP. Nginx phải chủ động "gửi thiệp mời" báo cho trình duyệt biết thông qua header:

   *http2 on;*
    *listen 443 quic reuseport;*
    *add_header Alt-Svc 'h3=":443"; ma=86400'*
    *ssl_protocols TLSv1.2 TLSv1.3;*
  

• Mở port 443/UDP, nếu không sẽ bị kẹt ở h2

Những cú vấp thực tế - Trở ngại không có trong sách vở

Nếu bạn không lắp WAF cho website của bạn thì bạn có thể dừng đọc tại đây, vì tại đây là trải nghiệm thực tế rất thú vị liên quan đến việc WAF chặn 403 trên giao thức HTTP3 như ảnh bên dưới: Bạn có thể thấy dù h3 đã hoạt động nhưng site vẫn trả về 403, tò mò một lúc ta có:

Ta hiểu là giao thức http/3 hoạt động bình thường nhưng WAF lại chặn mà chỉ chặn h3 mà không chặn h2 (http/2) điều này có nghĩa sẽ liên quan đến tính chất, đặc trưng khác biệt của h3, tôi vào đọc liền modsec_audit.log

Ngay lập tức ở phần ---JyzhsSd1---H--, ModSecurity đưa ra phán quyết:

• [id "920280"] ... [msg "Request Missing a Host Header"]
• Tại sao WAF lại hiểu lầm?

Trong HTTP/1.1, Host là một header văn bản bắt buộc. Tuy nhiên, lên HTTP/3 (QUIC), thông tin tên miền không còn nằm ở header Host truyền thống mà được chuyển sang một Pseudo-header có tên là :authority.

Vấn đề nằm ở chỗ các bộ "Connector" (người phiên dịch giữa Nginx và ModSecurity) có thể chưa ánh xạ (map) hoàn hảo trường :authority của HTTP/3 vào biến Host mà ModSecurity đang chờ đợi. Kết quả là WAF quét bảng header truyền thống, thấy trống rỗng và kết luận request vi phạm tiêu chuẩn RFC (Rule 920280), tặng ngay 5 điểm "độc hại" và chặn đứng truy cập.

Cách giải quyết tạm thời hiện trong đầu tôi đó là ồ, đã dùng h3 rồi thì rule này coi như bỏ hay là mình ném nó đi luôn nhỉ.

• SecRuleRemoveById 920280 ném thẳng vào main.conf Và thế là Problem Solved.

Lựa chọn "Cloudflare": Lối đi tắt cho người chơi hệ "nhàn"

Đọc đến đây chắc hẳn nhiều bạn sẽ thở dài "Trời đất, chỉ để lên cái HTTP/3 mà phải compile Nginx, đục tường lửa, rồi lại ngồi fix WAF rule nữa sao?".

Đó là lý do các dịch vụ bên thứ 3 như Cloudflare (hoặc các CDN bên thứ 3) trở thành một lựa chọn cực kỳ cám dỗ.

Với Cloudflare, bạn chỉ cần gạt một nút công tắc "Enable HTTP/3 (with QUIC)" trên Dashboard. Vậy là xong! Website của bạn lập tức có HTTP/3.

Cơ chế "ảo thuật" ở đây là gì? Cloudflare đóng vai trò là reverse proxy đứng mũi chịu sào

• Từ Client <---> Cloudflare Edge: Kết nối bằng HTTP/3 cực mượt, bên cạnh đó còn các cơ chế bảo mật rất hấp dẫn.
• Từ Cloudflare Edge <---> Máy chủ gốc: Tiếp tục sử dụng HTTP/1.1 hoặc HTTP/2 TCP truyền thống

Đánh giá sự đánh đổi:

• Ưu điểm: Nhanh, nguy hiểm, không cần chạm tay vào config server gốc. Tránh được toàn bộ rủi ro xung đột WAF nội bộ và Tường lửa UDP như đã phân tích ở trên. Rất phù hợp cho các hệ thống Legacy (cũ) khó nâng cấp.
• Nhược điểm: Bạn bị phụ thuộc vào bên thứ ba. Quan trọng hơn, kiến trúc này không phải là End-to-End HTTP/3. Nút thắt cổ chai đôi khi vẫn nằm ở đoạn kết nối TCP từ Cloudflare về server của bạn, làm giảm đi một phần ưu thế thực sự của QUIC.

Kết luận

Đưa website lên HTTP/3 không đơn thuần là cài đặt một phiên bản phần mềm mới, mà nó là sự chuyển dịch kiến trúc tầng mạng từ TCP sang UDP.

Nếu bạn là một Sysadmin đam mê kiểm soát và muốn tối ưu hóa hệ thống từ gốc rễ, việc tự cấu hình và xử lý các xung đột Tường lửa/WAF là một trải nghiệm cực kỳ xứng đáng. Còn nếu dự án ưu tiên sự ổn định, triển khai nhanh và tiết kiệm nguồn lực, việc "đứng trên vai người khổng lồ" như Cloudflare là một sự lựa chọn khôn ngoan.

Hệ thống của bạn đã sẵn sàng cho HTTP/3 chưa? Hay bạn thuộc team gạt nút Cloudflare? Hãy chia sẻ câu chuyện "ăn hành" của bạn dưới phần bình luận nhé!