Cách Encrypted Client Hello (RFC 9849) hoạt động: ClientHello ngoài và trong, khóa trong DNS, ISP và CDN vẫn thấy gì, và cách tự kiểm tra kết nối của bạn.
Suốt nhiều năm, phần duy nhất của kết nối HTTPS còn gọi tên website bằng văn bản thuần là trường Server Name Indication (SNI) trong bước bắt tay TLS. Encrypted Client Hello (ECH) là bản sửa đã được chuẩn hóa: trình duyệt mã hóa ClientHello thật rồi gói nó vào một ClientHello bên ngoài trông vô hại. Nhưng rất dễ thổi phồng vai trò của ECH. Nó chỉ chuyển bí mật từ "mọi người trên đường truyền" sang "máy chủ giải mã nó", và vẫn để lộ nhiều phần của bước bắt tay hơn so với nhiều bài tóm tắt nói. Bài này giải thích cơ chế và cho biết từng bên quan sát đọc được gì, không đọc được gì.
Điểm chính
- ECH đã là một chuẩn. Đặc tả được công bố thành RFC 9849 (Proposed Standard, tháng 3/2026), sau nhiều năm là bản nháp
draft-ietf-tls-esni. - Hai ClientHello trong một kết nối. Trình duyệt gửi một ClientHello ngoài đọc được, dùng
public_namecủa máy chủ tiếp nhận làm SNI; ClientHello trong thật (gồm SNI thật và danh sách ALPN) được mã hóa bên trong nó. - Khóa đến từ DNS. Cấu hình ECH của máy chủ được công bố trong bản ghi DNS HTTPS/SVCB (RFC 9460), nên ECH chỉ bảo vệ bạn nếu chính truy vấn đó không bị đọc được. RFC nói thẳng rằng mã hóa SNI kém hữu ích nếu không mã hóa DNS.
- Vẫn có thể lấy dấu vân tay từ hello ngoài trên mạng. Hello ngoài là một ClientHello thật, đọc được, và đặc tả cho phép client sao chép các trường từ hello trong sang, nên thói quen của thư viện TLS không nhất thiết biến mất khỏi đường truyền.
- Máy chủ giải mã thấy tất cả. ECH thay đổi những gì mạng thấy, không thay đổi những gì CDN hay máy chủ gốc thấy.
Vấn đề ECH giải quyết
TLS 1.3 mã hóa chứng chỉ máy chủ và phần lớn bước bắt tay, nhưng ClientHello phải đọc được trước khi có khóa. Vì vậy SNI, thứ cho máy chủ biết bạn muốn vào tên miền nào trong số nhiều tên miền của nó, đi qua mạng dưới dạng văn bản thuần. RFC gọi nó là "có lẽ là thông tin nhạy cảm nhất còn chưa được mã hóa trong TLS 1.3". Tài liệu yêu cầu trước đó, RFC 8744, liệt kê lý do các nỗ lực mã hóa SNI trước đây khó thực hiện, và đó là lý do chuẩn hoàn chỉnh chỉ có vào năm 2026. Về việc SNI để lộ gì cho ISP hay bên vận hành Wi-Fi, xem ISP vẫn thấy gì khi bạn dùng HTTPS; bài này tập trung vào cách bản sửa hoạt động.
ClientHello ngoài và trong
Với ECH, trình duyệt tạo hai thông điệp:
- ClientHelloInner (trong) là thông điệp bắt tay thật: SNI thật, danh sách ALPN (khai báo các giao thức như HTTP/2 hoặc HTTP/3) và các extension khác. Nó được mã hóa bằng khóa công khai của máy chủ qua HPKE (mã hóa khóa công khai lai) và được đệm để lộ ít thông tin về độ dài hơn.
- ClientHelloOuter (ngoài) là một ClientHello trông bình thường.
server_namecủa nó được đặt làpublic_nametrong cấu hình ECH, tức tên của máy chủ tiếp nhận (client-facing server, máy chủ trực tiếp nhận kết nối từ client), ví dụ tên máy chủ dùng chung của một CDN. Thông điệp trong đã mã hóa nằm bên trong, trong extensionencrypted_client_hello.
Máy chủ tiếp nhận thử giải mã extension. Nếu thành công, nó tiếp tục bắt tay theo hello trong và kết nối đi đến website thật. Nếu không được (sai khóa, hoặc extension chỉ là dữ liệu giả), nó coi hello ngoài là toàn bộ nội dung và xử lý như public_name. Đặc tả mô tả hai mô hình: chế độ dùng chung, nơi một nhà cung cấp vừa là máy chủ tiếp nhận vừa là máy chủ gốc, và chế độ tách rời, nơi máy chủ tiếp nhận chuyển tiếp hello đã giải mã cho một máy chủ backend riêng.
RFC nêu thẳng một hệ quả: ECH "cho biết client đang kết nối tới một nhà cung cấp dịch vụ cụ thể, nhưng không cho biết máy chủ nào trong tập ẩn danh kết thúc kết nối". Nếu một website có IP riêng, chỉ riêng IP đích đã đủ làm lộ nó. ECH giúp được nhiều hay ít tùy vào số website dùng chung "cửa trước".
Khóa đến từ đâu: DNS
Trình duyệt cần khóa công khai của máy chủ trước khi kết nối, và lấy nó từ DNS. Máy chủ công bố ECHConfigList (một hoặc nhiều ECHConfig chứa khóa, ID cấu hình và public_name) trong bản ghi DNS HTTPS hoặc SVCB, loại bản ghi được định nghĩa ở RFC 9460.
Điều này tạo ra chuỗi phụ thuộc. Nếu truy vấn DNS lấy bản ghi HTTPS đi dưới dạng văn bản thuần, bộ phân giải của bạn và bất kỳ ai trên đường đi đã biết tên miền trước khi ECH kịp che gì. RFC cũng lưu ý rằng DNS mã hóa còn chống được kẻ tấn công trong mạng cục bộ sửa cấu hình ECH, và mã hóa SNI "kém hữu ích hơn nếu không mã hóa các truy vấn DNS khi truyền". Trên thực tế đó là DNS over HTTPS hoặc DNS over TLS. Cách thiết lập và kiểm tra có trong Ngăn rò rỉ DNS.
Ai thấy gì: bảng ba bên quan sát
| Mạng trên đường truyền (ISP, Wi-Fi) | Máy chủ tiếp nhận (vd. CDN) | Máy chủ gốc phía sau | |
|---|---|---|---|
| IP đích | Có | Có | Có |
SNI ngoài (public_name) | Có | Có | Chế độ tách rời: không |
| SNI thật và ALPN trong | Không (đã mã hóa) | Có, sau khi giải mã | Có |
| Các trường khác sao chép vào hello ngoài | Có | Có | Không áp dụng |
| ClientHello trong đầy đủ | Không | Có | Có |
| Truy vấn DNS văn bản thuần, nếu dùng | Có | Không áp dụng | Không áp dụng |
Có hai hàng đáng nhấn mạnh. Thứ nhất, SNI thật được giấu khỏi mạng nhưng không bao giờ giấu khỏi bên kết thúc kết nối. ECH không phải ẩn danh: CDN vẫn biết bạn vào khách hàng nào của nó. Thứ hai, hàng "các trường khác" là phần khiến nhiều người bất ngờ.
JA3/JA4 trên mạng vẫn đọc được gì
Một cách nói giản lược phổ biến, cũng xuất hiện trong bài chính về TLS fingerprinting của chúng tôi, là ECH chỉ để lại cho bên quan sát một ClientHello ngoài tối giản, giúp hạn chế lấy dấu vân tay. RFC ủng hộ nửa đầu và thận trọng hơn với nửa sau. Khi tạo hello ngoài, client theo một danh sách quy tắc ngắn (đề nghị TLS 1.3 trở lên, sao chép session ID, dùng số ngẫu nhiên mới, đặt public_name vào server_name), rồi theo nguyên văn, "nó CÓ THỂ (MAY) sao chép bất kỳ trường nào khác từ ClientHelloInner trừ ClientHelloInner.random". Khi bàn về tập ẩn danh, đặc tả còn thêm rằng các lựa chọn triển khai như thứ tự extension trong thông điệp TLS có thể tạo ra hành vi nhìn thấy được bên ngoài khác nhau dù cấu hình giống nhau.
Vì vậy hello ngoài là một ClientHello thật: có cipher suite, extension, nhóm đường cong được hỗ trợ và thứ tự, tất cả đọc được trên đường truyền. Bên quan sát thụ động có thể tính một dấu vân tay kiểu JA3 hoặc JA4 cho thông điệp này. Điều thay đổi là dấu vân tay mô tả hello nào và những trường nào bị giấu: SNI thật và danh sách ALPN trong không còn thấy được, còn chỉ báo có SNI và giá trị ALPN mà JA4 ghi lại được lấy từ hello ngoài. Dấu vân tay ngoài có đặc trưng như hiện nay hay không phụ thuộc vào cách triển khai của từng trình duyệt, RFC không đảm bảo theo hướng nào. Hãy coi "ECH đánh bại TLS fingerprinting trên mạng" là chưa được chứng minh, còn "bên quan sát đọc được ít hơn" mới là phát biểu chính xác. (Với QUIC cũng vậy: xem dấu vân tay HTTP/3 và QUIC.)
Phía máy chủ thì khác. Máy chủ tiếp nhận giải mã hello trong và thấy toàn bộ dấu vân tay của client, nên các hãng chống bot hoạt động ở tầng CDN không mất gì vì ECH.
GREASE ECH: vì sao riêng extension không chứng minh được gì
Trình duyệt không có cấu hình ECH cho một site vẫn gửi extension encrypted_client_hello, chứa các byte ngẫu nhiên có độ dài hợp lý. RFC gọi đó là GREASE ECH (cùng ý tưởng với các giá trị giả trong RFC 8701). Mục đích là để ECH thật không nổi bật, và thiết bị trung gian không thể dễ dàng chặn "extension ECH" mà không làm hỏng các kết nối bình thường. Máy chủ không giải mã được nó sẽ bỏ qua.
Bài học thực tế là thấy extension trong bản ghi gói tin không cho biết kết nối có thực sự được bảo vệ hay không. Chỉ một cuộc bắt tay thành công với ECH được chấp nhận mới tính. Đặc tả cũng thẳng thắn nói rằng GREASE và ECH thật chỉ được thiết kế để không phân biệt được với một bên quan sát thụ động có năng lực hạn chế; những giá trị như SNI ngoài hay ID cấu hình vẫn có thể là dấu hiệu phân biệt.
Các kiểu lỗi: thử lại, quay về và bị chặn
- Khóa cũ và retry_configs. Bộ nhớ đệm DNS và việc xoay khóa khiến khóa của trình duyệt có thể đã cũ. Nếu máy chủ không giải mã được, nó hoàn tất bắt tay bằng hello ngoài và trả
retry_configsmới trong một thông điệp được mã hóa. Client xác minh chứng chỉ theopublic_name, rồi thử lại với cấu hình mới. Đặc tả yêu cầu client không chấp nhậnretry_configslần thứ hai để đáp lại một lần thử lại, vì đó là dấu hiệu máy chủ cấu hình sai. ech_required. Nếu client đã đề nghị ECH thật mà kết nối cuối cùng không dùng được, client sẽ hủy trước khi gửi dữ liệu ứng dụng, thay vì lặng lẽ quay về SNI văn bản thuần.- Không có cấu hình nào. Nếu bản ghi DNS không có tham số ECH (hoặc bản ghi HTTPS bị lược bỏ), trình duyệt không có khóa để mã hóa và kết nối theo cách cũ, kèm GREASE nếu hỗ trợ. Khi đó trình duyệt báo lỗi hay tiếp tục là quyết định của sản phẩm, nên hãy coi ECH là cơ chế best-effort: có điều kiện thì dùng, không thì thôi.
- Mạng không ưa ECH. RFC thừa nhận một số bên vận hành có thể chặn ECH thật nhưng cho GREASE đi qua, và các môi trường được quản lý dựa vào SNI để lọc hoặc cân bằng tải có thể tắt ECH bằng chính sách. Tài liệu không tuyên bố ECH không thể bị chặn, chỉ nói rằng nó được thiết kế để bên quan sát thụ động khó phân biệt với GREASE.
Bài này không đưa ra tỷ lệ triển khai vì một con số duy nhất phụ thuộc vào việc tính những site và client nào. Để đọc cách một CDN lớn triển khai và điều đó có ý nghĩa gì với bên vận hành, xem bài của Cloudflare.
Cách tự kiểm tra kết nối của bạn
Mọi site được phục vụ qua Cloudflare đều có trang chẩn đoán /cdn-cgi/trace. Hãy mở nó và tìm dòng sni=: sni=encrypted nghĩa là kết nối đã dùng ECH, còn sni=plaintext nghĩa là tên máy chủ thật đã đi qua mạng dưới dạng văn bản thuần. Khi chúng tôi gọi browserinsight.net/cdn-cgi/trace bằng một client không dùng ECH vào 2026-10-12, kết quả là sni=plaintext, đúng như mong đợi với client không có khóa được công bố hoặc chưa bật ECH. Cách kiểm tra này chỉ áp dụng cho site chạy qua Cloudflare, và các công cụ của BrowserInsight không phát hiện ECH.
Đáp ứng đủ điều kiện thì kết quả sẽ tốt hơn: dùng trình duyệt hỗ trợ ECH, bật DNS mã hóa và truy cập site mà bên vận hành đã công bố bản ghi HTTPS có cấu hình ECH. Để biết điều gì vẫn lộ ngay cả khi đó, công cụ kiểm tra thông tin IP cho thấy địa chỉ mà máy chủ nhìn thấy; IP đích vẫn hiển thị với mạng dù có ECH hay không.
Câu hỏi thường gặp
ECH có giấu website tôi truy cập khỏi ISP không?
Một phần. Nó giấu tên máy chủ thật trong bước bắt tay, nhưng ISP vẫn thấy IP đích và public_name bên ngoài. Với các site dùng chung IP với nhiều site khác, như site sau một CDN lớn, điều đó để lại sự mơ hồ thực sự; với site có IP riêng, chỉ riêng địa chỉ IP đã đủ để nhận ra nó.
ECH có thay thế VPN không?
Không. VPN thay đổi vị trí của bên quan sát: ISP chỉ thấy VPN, còn nhà cung cấp VPN thấy những gì ISP lẽ ra thấy. ECH giấu một trường khỏi mạng, còn IP đích, thời điểm và khối lượng lưu lượng vẫn thấy được.
ECH có hoạt động khi không dùng DNS mã hóa không?
Vẫn kết nối được, nhưng lợi ích riêng tư bị giảm. Khóa được lấy từ bản ghi DNS, và truy vấn văn bản thuần để lộ tên miền cho bộ phân giải và thiết bị trên đường đi trước cả khi bắt tay bắt đầu.
Website có biết tôi đã dùng ECH không?
Có. Máy chủ tiếp nhận biết nó có giải mã extension ECH hay không, và CDN hiển thị điều đó, như dòng sni= trong kết quả trace cho thấy. Máy chủ này thấy trọn vẹn ClientHello trong.
Extension xuất hiện trong bản ghi gói tin có chứng minh ECH đã được dùng không?
Không. Trình duyệt gửi GREASE ECH khi không có cấu hình, nên extension vẫn có thể xuất hiện trên các kết nối không được bảo vệ.
