HTTPS mã hóa nội dung trang, nhưng không phải mọi thứ. Tìm hiểu ISP, bên vận hành Wi-Fi hay nhà mạng di động vẫn thấy gì: IP đích, DNS, SNI và mẫu lưu lượng.
Biểu tượng ổ khóa trên thanh địa chỉ có nghĩa là nội dung trang và đường dẫn bạn gõ sau tên miền đã được mã hóa — không có nghĩa là kết nối của bạn hoàn toàn vô hình. HTTPS chưa bao giờ được thiết kế để che giấu metadata (dữ liệu mô tả), và metadata chính là phần lớn những gì một bên quan sát trên đường truyền — như ISP, bên vận hành mạng Wi-Fi, hay nhà mạng di động của bạn — vẫn có thể khai thác. Bài viết này sẽ đi qua chính xác phần còn sót lại đó: địa chỉ IP đích, truy vấn DNS, tên máy chủ trong bắt tay TLS, và thời điểm cùng dung lượng của lưu lượng.
Những điểm chính
- HTTPS mã hóa những gì bạn đọc và nhập, chứ không phải bạn đang nói chuyện với ai. Địa chỉ IP đích luôn hiển thị trên mọi gói tin, bất kể có mã hóa hay không.
- DNS thường là điểm rò rỉ lớn nhất. Trừ khi dùng DNS mã hóa, trình phân giải của bạn — thường là của ISP — sẽ thấy mọi tên miền bạn tra cứu, ở dạng văn bản thuần.
- Bắt tay TLS trước đây cũng từng làm lộ chính tên miền đó, qua trường Server Name Indication (SNI). Encrypted Client Hello (ECH) lấp khoảng trống này khi cả trình duyệt lẫn máy chủ đều hỗ trợ.
- Thời điểm, dung lượng và nhịp độ lưu lượng làm lộ hành vi ở mức thô, ngay cả khi mọi byte nội dung đã được mã hóa — điều này không thể khắc phục bằng một cài đặt trình duyệt.
- Không có cài đặt nào khiến bạn hoàn toàn vô hình trước mạng bạn đang dùng. Mục tiêu thực tế là có một mô hình tư duy chính xác về những gì vẫn còn lộ ra, chứ không phải cảm giác an toàn tuyệt đối giả tạo.
Ranh giới cụ thể: HTTPS mã hóa gì, và không mã hóa gì
HTTPS bọc yêu cầu và phản hồi HTTP của bạn — phần nội dung trang, các trường biểu mẫu, cookie, cùng đường dẫn và chuỗi truy vấn trong URL — bên trong lớp mã hóa TLS. Một bên quan sát nằm trên đường truyền mạng giữa bạn và máy chủ không thể đọc được bạn đã tìm kiếm gì, đã gửi gì trong biểu mẫu, hay đang đọc bài viết nào trên một trang web nhất định. Đó là sự bảo vệ thực sự và quan trọng mà HTTPS mang lại so với HTTP thuần.
Điều mà TLS không che giấu là "chiếc phong bì": ai đang gửi gói tin và gửi đến ai, kích thước xấp xỉ bao nhiêu, và gửi vào lúc nào. Những trường này phải giữ nguyên dạng đọc được để các bộ định tuyến có thể làm nhiệm vụ của mình — và đó chính xác là thông tin mà một bên quan sát trên đường truyền vẫn có thể thu thập. Phần còn lại của bài viết sẽ đi qua từng phần trong số đó.
Phần còn lại 1: Địa chỉ IP đích
Mỗi gói tin bạn gửi đều mang địa chỉ IP đích ở dạng không mã hóa — TLS mã hóa phần dữ liệu (payload), chứ không mã hóa phần tiêu đề ở tầng mạng mà các bộ định tuyến dùng để chuyển gói tin đi. ISP của bạn (hoặc bất kỳ ai khác trên đường truyền) luôn có thể thấy bạn đang kết nối đến những địa chỉ IP nào, và có thể đối chiếu với các dải địa chỉ hosting đã biết.
Trên thực tế, tín hiệu này yếu hơn nhiều so với tưởng tượng. Một máy chủ chuyên dụng chỉ một khách thuê sẽ ánh xạ trực tiếp một IP tới một danh tính. Nhưng phần lớn web hiện đại nằm sau hạ tầng dùng chung — các CDN và bộ cân bằng tải trên đám mây phục vụ hàng nghìn tên miền không liên quan từ cùng một dải địa chỉ. Việc thấy một kết nối tới một IP của Cloudflare hay AWS chỉ cho biết "có gì đó đằng sau cánh cửa chung này", chứ không cho biết bạn đã tải trang nào trong số hàng nghìn trang đứng sau nó. Việc dùng chung hạ tầng làm suy yếu đáng kể tín hiệu này — nhưng không loại bỏ hoàn toàn, vì đôi khi một dải IP vẫn dành riêng cho một dịch vụ duy nhất; và khi kết hợp với DNS hoặc SNI (bên dưới), IP thường đóng vai trò xác nhận hơn là tiết lộ đích đến.
Phần còn lại 2: DNS — thường là rò rỉ lớn nhất
Trước khi trình duyệt có thể kết nối tới bất cứ đâu, nó phải phân giải tên miền thành địa chỉ IP, và truy vấn đó là một giao dịch hoàn toàn tách biệt với kết nối HTTPS diễn ra sau đó. Trừ khi bạn đã cấu hình riêng DNS mã hóa, truy vấn đó sẽ được gửi ra ngoài dưới dạng văn bản thuần tới một trình phân giải — mặc định là do ISP vận hành — và trình phân giải này thấy chính xác tên miền bạn sắp truy cập, kèm dấu thời gian.
Đây là phần còn lại mà hầu hết mọi người đánh giá thấp, bởi chính kết nối của trình duyệt thì được mã hóa, còn bước tra cứu diễn ra trước đó thì không. Cách khắc phục là DNS mã hóa (DNS over HTTPS hoặc DNS over TLS), mà hầu hết trình duyệt hiện đại ngày nay đã hỗ trợ sẵn. Chúng tôi đã trình bày cơ chế, các lỗi cấu hình phổ biến khiến rò rỉ xảy ra ngay cả khi dùng VPN, và cách tự kiểm tra trình phân giải của bạn trong bài Ngăn rò rỉ DNS — rất đáng đọc trọn vẹn nếu đây là điều bạn quan tâm nhất, vì đây thường là phần đáng ưu tiên khắc phục nhất.
Phần còn lại 3: SNI trong bắt tay TLS
Ngay cả sau khi DNS đã phân giải xong tên miền, bắt tay TLS thiết lập kết nối HTTPS của bạn trước đây cũng từng làm lộ lại chính tên miền đó lần nữa. Để một địa chỉ IP có thể phục vụ nhiều tên miền HTTPS (một lần nữa, trường hợp bình thường khi đứng sau CDN), trình duyệt của bạn gửi một trường Server Name Indication (SNI) trong thông điệp ClientHello ban đầu, nêu tên trang web nó muốn truy cập — để máy chủ kết thúc TLS biết cần trình chứng chỉ nào. TLS 1.3 (RFC 8446) mã hóa phần lớn quá trình bắt tay sau đó, kể cả các chứng chỉ được trao đổi ở giai đoạn thương lượng muộn hơn, nhưng bản thân ClientHello — cùng với trường SNI bên trong nó — phải được gửi trước khi bất kỳ khóa mã hóa nào tồn tại, nên theo yêu cầu bắt buộc của giao thức, nó luôn được truyền ở dạng văn bản thuần. Đó chính là ClientHello mà TLS fingerprinting đọc để nhận diện phần mềm client; SNI là một tín hiệu độc lập thứ hai, đi kèm trong cùng thông điệp văn bản thuần đó.
Encrypted Client Hello (ECH) chính là giải pháp khắc phục: nó mã hóa ClientHello nội bộ nhạy cảm — bao gồm cả SNI — bằng một khóa mà máy chủ công bố trong DNS, chỉ để lại trên đường truyền một ClientHello bên ngoài tối giản, mang tính chung chung. Cloudflare, đơn vị đảm nhiệm phần lớn việc kết thúc TLS trên web, đã công bố hỗ trợ ECH trên hạ tầng chính thức, thúc đẩy tiêu chuẩn này tiến tới triển khai thực tế. Tuy nhiên, cần chính xác về ý nghĩa thực sự của điều này: ECH chỉ lấp khoảng trống rò rỉ SNI khi cả trình duyệt của bạn và máy chủ bạn kết nối đến đều hỗ trợ và bật tính năng này — đây là thuộc tính theo từng kết nối, chứ không phải một cài đặt bật một lần rồi quên đi. Một kết nối tới trang web hoặc CDN chưa triển khai ECH vẫn gửi SNI ở dạng văn bản thuần, dù trình duyệt của bạn có mới đến đâu.
Còn một phụ thuộc nữa nối thẳng phần còn lại này với phần trước đó: khóa dùng để mã hóa ClientHello nội bộ được công bố trong một bản ghi DNS, nên trình duyệt phải tra cứu nó trước rồi mới mã hóa được. Nếu truy vấn đó đi ở dạng văn bản thuần, tên miền đã lộ ra với trình phân giải trước cả khi ECH kịp che nó — đó là lý do các trình duyệt có hỗ trợ ECH chỉ bật tính năng này khi truy vấn đi qua DNS mã hóa. DNS mã hóa không phải một lựa chọn song song để dùng thay cho ECH, mà là điều kiện tiên quyết để ECH hoạt động.
Phần còn lại 4: Thời điểm, dung lượng và mẫu hình
Ngay cả trong trường hợp giả định IP đích, DNS và SNI đều bị che giấu hoàn toàn, kết nối vẫn để lộ một điều: hình dạng của lưu lượng. Kích thước từng gói tin, số lượng gói tin, và nhịp độ của các đợt bùng nổ cùng khoảng nghỉ giữa chúng đều vượt qua quá trình mã hóa hoàn toàn nguyên vẹn, bởi vì mã hóa payload không làm thay đổi số byte cần để gửi nó, cũng không làm thay đổi thời điểm bạn chọn để gửi.
Đây là một phần còn lại có thật và đã được nghiên cứu kỹ — các nghiên cứu phân tích lưu lượng đã nhiều lần chứng minh rằng kích thước và mẫu hình thời gian của một phiên đã được mã hóa hoàn toàn vẫn có thể thu hẹp phạm vi, và đôi khi xác định chính xác, những gì người dùng đang làm. Đây cũng là phần khó hình dung nhất trong bốn phần còn lại nếu chỉ nhìn lướt qua, và không phải thứ có thể khắc phục bằng một cài đặt trình duyệt. Kết luận thực tế khá khiêm tốn: hiểu rằng "đã mã hóa" không có nghĩa là "không có hình dạng", và xem đây như một sự thật nền chứ không phải thứ cần tìm cách né tránh — không có biện pháp giảm thiểu đơn giản nào để khuyến nghị ở đây, và bài viết này sẽ không giả vờ là có.
Còn ai khác trên đường truyền
ISP của bạn là bên quan sát rõ ràng nhất, nhưng hiếm khi là bên duy nhất. Đơn vị vận hành mạng Wi-Fi — quán cà phê, sân bay, khách sạn — nằm ở đúng vị trí như ISP tại nhà của bạn, chừng nào bạn còn kết nối vào mạng của họ. Mạng doanh nghiệp thường chạy một thiết bị trung gian có thể thấy cùng loại metadata đó (và trên các thiết bị được quản lý, nhờ chứng chỉ gốc được cài đặt, đôi khi còn thấy nhiều hơn thế). Nhà mạng di động thấy mọi thứ điện thoại của bạn làm trên dữ liệu di động, theo cùng cách mà ISP tại nhà thấy lưu lượng qua router của bạn.
VPN là phản ứng phổ biến trước tình huống này, và cần nói chính xác về những gì nó thực sự làm: nó di dời điểm quan sát — từ mạng cục bộ hoặc ISP của bạn sang nhà cung cấp VPN — chứ không loại bỏ một bên quan sát khỏi bức tranh. ISP của bạn giờ chỉ thấy bạn đang kết nối tới một máy chủ VPN, nhưng nhà cung cấp VPN giờ trở thành bên ở vị trí có thể thấy IP đích của bạn, và tùy vào cấu hình DNS riêng của họ, cả các truy vấn DNS của bạn. Việc đây có phải là một cải thiện thực sự hay không hoàn toàn phụ thuộc vào việc bạn có tin tưởng nhà vận hành VPN hơn ISP của mình hay không — xem so sánh VPN, proxy và Tor của chúng tôi để biết ba công cụ phổ biến này thực sự khác nhau ra sao về những gì chúng che giấu và những gì vẫn để lộ. Một phương án liên quan đáng biết, hiện đã ngừng hoạt động, là Chrome IP Protection, sử dụng thiết kế proxy hai chặng riêng để không một nhà vận hành chặng chuyển tiếp đơn lẻ nào có thể thấy đồng thời cả IP thật và đích đến của bạn — dù về nghĩa chung đây cũng là một dạng proxy, nhưng khác mô hình tin cậy so với VPN của một nhà cung cấp duy nhất.
Những gì bạn có thể tự kiểm tra
Bạn không cần phải tin vào bất cứ điều gì ở trên một cách mù quáng. Công cụ kiểm tra thông tin IP của BrowserInsight cho thấy IP thoát và thông tin mạng mà máy chủ đích thực sự thấy đối với kết nối hiện tại của bạn, còn công cụ kiểm tra VPN/proxy báo cáo liệu kết nối đó có vẻ là VPN, proxy, hay chỉ là một đường dây ISP dân dụng hoặc doanh nghiệp thông thường. So sánh hai kết quả này trước và sau khi kết nối VPN — hoặc sau khi chuyển mạng — là cách nhanh nhất để biết ai đang thực sự nằm trên đường truyền của bạn lúc này. Nếu bạn nghi ngờ VPN của mình không định tuyến DNS qua đường hầm đúng như lẽ ra phải làm, bài Ngăn rò rỉ DNS có các lệnh cụ thể để kiểm tra chính xác trình phân giải nào đang trả lời truy vấn của bạn; đồng thời, một kênh phụ liên quan đáng loại trừ là chủ đề của bài Chống rò rỉ WebRTC, vì WebRTC có thể làm lộ IP thật của bạn độc lập với DNS hay đường hầm VPN của bạn.
Kết luận trung thực
Tất cả những điều trên không phải để gây hoang mang, và cũng không phải một danh sách để "trốn" khỏi ISP — cách diễn đạt đó hứa hẹn quá mức, và bài viết này sẽ không giả vờ như vậy. Đây đúng hơn là lý do để xây dựng một mô hình tư duy chính xác: HTTPS đã làm được một việc thật sự và quan trọng là mã hóa nội dung, còn DNS, SNI và hình dạng lưu lượng là phần metadata còn sót lại — gần đúng theo thứ tự mức độ bạn có thể thực tế giảm bớt được chúng. Không có tổ hợp cài đặt trình duyệt nào khiến lưu lượng của bạn trở nên vô hình trước bên đang vận hành mạng bạn đang dùng — mục tiêu là hiểu chính xác những gì đang bị lộ, chứ không phải cảm giác sai lầm rằng biểu tượng ổ khóa có nghĩa là không ai có thể thấy gì.
Câu hỏi thường gặp
ISP của tôi có thể thấy tôi truy cập những trang web nào nếu tôi chỉ dùng HTTPS không?
Không thấy được trang cụ thể hay nội dung của trang, nhưng với tên miền thì trong hầu hết trường hợp là có. Trừ khi dùng DNS mã hóa, trình phân giải của ISP sẽ thấy mọi tên miền bạn tra cứu. Ngay cả khi dùng DNS mã hóa, ISP thường vẫn có thể suy ra đích đến từ địa chỉ IP, và ở nơi chưa triển khai Encrypted Client Hello, từ trường SNI trong bắt tay TLS.
HTTPS có che giấu URL khỏi ISP của tôi không?
Nó che giấu đường dẫn và chuỗi truy vấn — tức mọi thứ sau tên miền — vì những phần này nằm bên trong yêu cầu HTTP đã mã hóa. Nó không che giấu chính tên miền, vốn bị lộ riêng qua DNS và có thể qua SNI như đã mô tả ở trên.
SNI là gì và nó ảnh hưởng thế nào đến quyền riêng tư?
Server Name Indication là một trường trong bắt tay TLS cho máy chủ biết bạn đang cố truy cập tên miền nào, cần thiết vì một địa chỉ IP thường lưu trữ nhiều tên miền HTTPS khác nhau. Trước đây nó được truyền không mã hóa, làm lộ tên miền trên đường truyền ngay cả khi phần còn lại của phiên HTTPS đã được bảo vệ. Encrypted Client Hello (ECH) là giải pháp đã được triển khai, nhưng chỉ hoạt động khi cả trình duyệt của bạn và máy chủ đích đều hỗ trợ.
Chủ mạng Wi-Fi của tôi có thể thấy tôi duyệt web gì qua HTTPS không?
Cùng loại metadata mà ISP thấy được: IP đích, truy vấn DNS nếu không mã hóa, và SNI ở nơi chưa dùng ECH — chừng nào bạn còn kết nối vào mạng của họ, họ ở đúng vị trí trên đường truyền như ISP. Nhưng họ vẫn không thể đọc nội dung trang, cũng không thể thấy những gì bạn nhập vào một trang HTTPS.
VPN có ngăn ISP của tôi thấy các metadata này không?
Nó thay đổi ai là người thấy, chứ không phải liệu có ai thấy hay không. ISP của bạn giờ chỉ thấy một đường hầm mã hóa đến nhà cung cấp VPN, nhưng nhà cung cấp VPN lại ở vị trí có thể thấy IP đích và truy vấn DNS của bạn. Đây có phải là một cải thiện hay không phụ thuộc vào việc bạn tin tưởng nhà cung cấp VPN hơn ISP của mình hay không — xem đầy đủ các đánh đổi trong bài so sánh công cụ bảo mật của chúng tôi.
