ECH đã được bật, nhưng SNI vẫn hiển thị: cách kiểm tra mã hóa tên miền vào năm 2026

ECH — mã hóa tên miền trong quá trình bắt tay TLS — đã nhận được trạng thái tiêu chuẩn vào tháng 3 năm 2026 (RFC 9849, Standards Track). Firefox và Chrome kích hoạt nó theo mặc định, Cloudflare cung cấp khóa cho hầu hết khách hàng của mình. Tuy nhiên, đối với hầu hết người dùng, ECH không hoạt động một cách âm thầm: trình duyệt chuyển sang bắt tay thông thường, và nhà cung cấp vẫn thấy bạn đang đi đâu.

Dưới đây là cách kiểm tra trong một phút xem SNI có được mã hóa hay không, lý do tại sao nó thường không được mã hóa, và trong những kịch bản nào ECH hoàn toàn vô dụng (spoiler: cho việc chống phát hiện và phân tích — gần như luôn luôn).

Điều gì ECH ẩn giấu — và điều gì không ẩn giấu

Trong TLS 1.3 thông thường, mọi thứ đều được mã hóa, ngoại trừ thông điệp đầu tiên — ClientHello. Trong đó, trường SNI với miền mà bạn kết nối được hiển thị dưới dạng văn bản rõ. Chính SNI là cách mà hầu hết các hệ thống lọc hoạt động: IP chỉ có một cho hàng ngàn trang web qua CDN, trong khi miền thì có thể nhìn thấy.

ECH chia tách ClientHello thành hai phần:

• ClientHelloOuter — được gửi công khai, nhưng với miền giả làm lớp bọc. Đối với Cloudflare, đó là cloudflare-ech.com.
• ClientHelloInner — miền thực, ALPN và danh sách mã hóa, được mã hóa bằng khóa công khai của máy chủ.

Khóa cho việc mã hóa này không được lấy từ kết nối, mà từ DNS — từ đăng ký HTTPS (loại 65), tham số ech=. Từ đây, hệ quả chính mà mọi người thường quên: ECH không thể thực hiện nếu không có DNS được mã hóa. Nếu yêu cầu DNS được gửi qua UDP/53 công khai, người quan sát sẽ thấy tên miền trước khi bắt tay, và bộ giải quyết lọc có thể cắt tham số ech= khỏi phản hồi — và ECH sẽ không được kích hoạt.

Những gì ECH không ẩn giấu hoàn toàn:

• Địa chỉ IP đích — luôn có thể nhìn thấy;
• khối lượng và thời gian của lưu lượng;
• chữ ký TLS của khách hàng (JA3/JA4) — tập hợp các mã hóa và mở rộng vẫn nằm trong phần công khai;
• bạn đối với chính trang web — máy chủ sau khi giải mã thấy mọi thứ mà nó đã thấy trước đó.

Điểm cuối cùng là lý do tại sao ECH không liên quan đến việc vượt qua các hệ thống chống bot. Cloudflare, DataDome và Akamai hoạt động ở phía máy chủ: họ không quan tâm đến việc SNI có được mã hóa trong quá trình hay không. Nếu nhiệm vụ là không bị phát hiện khi tự động hóa, một lớp hoàn toàn khác hoạt động: thay thế chính chữ ký TLS, điều mà chúng tôi đã phân tích trong tài liệu về vượt qua chữ ký JA4 qua curl-cffi.

Kiểm tra số 1: ECH có hoạt động ngay bây giờ không (10 giây)

Mở trong trình duyệt:

https://crypto.cloudflare.com/cdn-cgi/trace

Tìm dòng sni=. Có hai khả năng:

• sni=encrypted — ECH đang hoạt động, tên miền được ẩn trong quá trình;
• sni=plaintext — ECH không được áp dụng, miền đã được gửi dưới dạng văn bản rõ.

Địa chỉ giống nhau qua curl trong terminal sẽ luôn trả về sni=plaintext — curl thông thường không hỗ trợ ECH, và đây là một chỉ dẫn tiện lợi: đó là cách mà "tắt" trông như thế nào.

Kiểm tra số 2: miền có khóa ECH không (dig, không cần trình duyệt)

ECH chỉ được kích hoạt nếu miền có đăng ký HTTPS trong DNS với tham số ech=. Kiểm tra đăng ký thô:

dig +short TYPE65 example.com @1.1.1.1

Trong phản hồi, tìm các byte FE0D — đây là mã mở rộng ECH, sau đó là ECHConfig. Ví dụ thực tế: vào thời điểm chuẩn bị tài liệu, crypto.cloudflare.com và miền của chúng tôi proxycove.com có đăng ký dài từ 133–136 byte chứa cả FE0D và tên giả cloudflare-ech.com dưới dạng hex. Trong khi đó, cloudflare.com có đăng ký ngắn, 61 byte: chỉ có ALPN và gợi ý IP, không có ECH. Điều này có nghĩa là ngay cả trong cơ sở hạ tầng của Cloudflare, ECH không được phát cho tất cả các miền — đừng ngạc nhiên nếu một trang web cụ thể không có nó.

Nếu dig báo lỗi ignoring invalid type HTTPS — bạn đang sử dụng phiên bản cũ của tiện ích, hãy sử dụng dạng số TYPE65, như trong lệnh ở trên.

Tại sao ECH không được kích hoạt: năm lý do theo thứ tự

1. DNS được mã hóa bị tắt. Nếu không có DoH, trình duyệt sẽ không nhận được ECHConfig một cách đáng tin cậy. Trong Firefox: Cài đặt → Quyền riêng tư → DNS qua HTTPS ở chế độ "Tăng cường" hoặc "Bảo vệ tối đa". Trong Chrome: Cài đặt → Bảo mật → Sử dụng DNS an toàn.
2. Miền đơn giản không có đăng ký HTTPS với ech= — kiểm tra bằng lệnh từ khối trên. Ở đây bạn không thể làm gì, đó là quyết định của chủ sở hữu trang web và CDN của họ.
3. Bộ giải quyết cắt tham số. Các máy chủ DNS của doanh nghiệp và nhà cung cấp thường có thể trả về các đăng ký HTTPS mà không có ech=. Kiểm tra bằng cách yêu cầu đăng ký trực tiếp từ bộ giải quyết công cộng (@1.1.1.1) và so sánh với phản hồi của hệ thống.
4. Các cờ của trình duyệt đã bị đặt lại. Trong Firefox, các tham số network.dns.echconfig.enabled và network.dns.http3_echconfig.enabled trong about:config — cả hai phải là true.
5. Có một cổng kiểm tra ở giữa. Về điều này — phần tiếp theo.

Cách ECH bị phá vỡ: hai sơ đồ khác nhau

Tường lửa doanh nghiệp: giảm thiểu âm thầm

Các nhà cung cấp thiết bị mạng đã phát hành các công thức sẵn có để chống lại ECH — họ không sẵn sàng mất khả năng nhìn thấy lưu lượng. Cisco, ví dụ, từ cơ sở ứng dụng VDB 416 (tháng 10 năm 2025) đã xác định "Máy chủ ECH" như một ứng dụng riêng và đề xuất hai cách tiếp cận: chặn kết nối với việc tái tạo chứng chỉ và cắt mở rộng encrypted_client_hello khỏi ClientHello, hoặc hành động đơn giản hơn — ở cấp độ DNS: chặn các đăng ký HTTPS cho các miền ECH, cắt DoH/DoT/DoQ, chặn miền canary use-application-dns.net và chỉ cho phép DNS đến các máy chủ doanh nghiệp.

Sự tinh vi của sơ đồ đầu tiên là nó không trông giống như một sự chặn. Máy chủ, khi không thấy mở rộng ECH, sẽ trả lời như bình thường, khách hàng nghĩ rằng ECH đã "tắt an toàn" và kết nối lại với SNI công khai. Trang web đã mở, không có lỗi — và tên miền đã bị ghi lại trong nhật ký của cổng.

Cấp độ quốc gia: kết nối đơn giản chết

Ví dụ của Nga là một minh chứng cho độ chính xác của nó. Kể từ ngày 5 tháng 11 năm 2024, việc lọc chỉ xảy ra khi có sự trùng khớp của hai dấu hiệu cùng lúc: SNI với giá trị cloudflare-ech.com cộng với sự hiện diện của mở rộng ECH. Riêng lẻ, cả hai không gây ra sự chặn — ECH vẫn hoạt động với các miền bọc khác (ví dụ, các miền thử nghiệm defo.ie hoặc tls-ech.dev). Điều này được thực hiện không phải bằng cách cắt kết nối, mà bằng việc âm thầm loại bỏ các gói tin: trang sẽ bị treo và ngắt kết nối theo thời gian chờ. Cả HTTP/2 dựa trên TCP và QUIC/HTTP-3 đều bị ảnh hưởng. Roskomnadzor đã tuyên bố rằng việc sử dụng TLS ECH vi phạm luật pháp Nga và khuyến nghị các chủ sở hữu trang web rời khỏi CDN Cloudflare — hàng ngàn tài nguyên hợp pháp đã bị lọc cùng một lúc, được đưa vào một lớp bọc chung.

Trong tình huống như vậy, Firefox sẽ thử lại sau khoảng một phút mà không có ECH — tức là cuối cùng sẽ trả về SNI công khai, điều mà đặc tả không khuyến nghị thực hiện vì lý do an toàn. Nếu bạn thấy "trang web tải đúng một phút, sau đó mở ra" — điều đó gần như chắc chắn là như vậy.

Khi nào ECH không đủ và nên thay thế bằng gì

Chúng ta hãy phân tích theo nhiệm vụ một cách trung thực.

• Bảo mật khỏi nhà cung cấp trên internet gia đình. ECH + DoH — một cải tiến tốt và miễn phí. Hoạt động ở nơi mà nó không bị cắt.
• Vượt qua lọc. ECH không được thiết kế cho điều này, và thực tiễn đã xác nhận điều đó: ngay khi nó bắt đầu gây rối cho các bộ lọc, họ đã học cách xác định và chặn hoàn toàn. Không thể dựa vào nó như một công cụ truy cập.
• Phân tích, đa tài khoản, tự động hóa. ECH không cung cấp gì: trang web mục tiêu thấy IP của bạn, JA4 của bạn và lịch sử yêu cầu của bạn. Chỉ có nguồn IP và chất lượng chữ ký mới quan trọng.

Trong tất cả các trường hợp mà ECH không hoạt động, một lớp thô hơn nhưng đáng tin cậy hơn hoạt động: đưa quá trình bắt tay TLS ra ngoài mạng quan sát được. Khi lưu lượng đi qua proxy, người quan sát trên kênh của bạn chỉ thấy kết nối với nút proxy — không có SNI của trang web mục tiêu trong đó, bất kể miền có hỗ trợ ECH hay không. Đối với việc truy cập hàng ngày và làm việc với các dịch vụ nhạy cảm với danh tiếng IP, các proxy dân cư sẽ phù hợp; cho các ứng dụng di động và các nền tảng đặc biệt nhạy cảm với loại kết nối, hãy sử dụng proxy di động.

Và đừng quên về DNS: proxy trong trình duyệt không đảm bảo rằng các tên được giải quyết qua nó. Rò rỉ DNS tiết lộ chính xác những gì bạn đã cố gắng ẩn giấu — cách kiểm tra điều này đã được thảo luận trong hướng dẫn riêng về kiểm tra proxy để rò rỉ DNS. Nếu câu hỏi là về phân tích sâu lưu lượng trên kênh, bạn cần xem xét không phải ECH, mà là chính phương tiện vận chuyển.

Danh sách kiểm tra ngắn gọn

1. Mở crypto.cloudflare.com/cdn-cgi/trace và xem dòng sni=.
2. Nếu plaintext — kích hoạt DoH trong trình duyệt và kiểm tra lại.
3. Nếu không giúp ích — kiểm tra sự hiện diện của khóa trên miền: dig +short TYPE65 miền @1.1.1.1, tìm FE0D.
4. Có khóa nhưng ECH không được áp dụng — so sánh phản hồi của bộ giải quyết công cộng và hệ thống: có khả năng tham số bị cắt trong quá trình.
5. Kết nối bị treo một phút và mở ra — ECH bị chặn ở cấp độ mạng; ECH không giúp ích ở đây, cần một phương tiện khác.

Kết luận

ECH là lỗ hổng cuối cùng được đóng lại một cách cẩn thận trong quyền riêng tư của TLS, không phải là một phương tiện truy cập và càng không phải là công cụ cho tự động hóa. Nó phụ thuộc vào DNS được mã hóa, có thể bị tắt giữa chừng mà không có bất kỳ lỗi nào trên màn hình và bị chặn hoàn toàn ở những nơi mà nó bắt đầu gây rối. Kiểm tra nó là điều đáng làm — hai lệnh ở trên chỉ mất một phút. Nhưng xây dựng trên nó để vượt qua các chặn hoặc bảo vệ chống lại các hệ thống chống bot là vô nghĩa: những nhiệm vụ này được giải quyết ở cấp độ mà máy chủ nhìn thấy IP và chữ ký TLS của ai ở đầu bên kia.