Rò rỉ WebRTC: vì sao địa chỉ thật vẫn có thể lộ dù đã dùng proxy
WebRTC tồn tại để các trình duyệt có thể nói chuyện trực tiếp với nhau cho cuộc gọi và chia sẻ màn hình. Muốn vậy, chúng cần khám phá những địa chỉ có thể liên lạc được, và chính quá trình khám phá đó là điều mà “rò rỉ WebRTC” nhắc đến.
ICE candidate trong một đoạn văn
Khi một trang tạo RTCPeerConnection và bắt đầu một offer, trình duyệt thu thập các candidate: những cách để một peer khác có thể liên lạc với nó. Candidate host là địa chỉ của một giao diện mạng cục bộ. Candidate server-reflexive (srflx) là địa chỉ công khai mà máy chủ STUN thấy yêu cầu đến từ đó. Candidate relay là địa chỉ của một máy chủ TURN. Mỗi candidate được trao cho trang dưới dạng một dòng văn bản chứa địa chỉ, đó là cách một script có thể đọc nó mà không cần thực hiện bất kỳ cuộc gọi nào.
Chỗ rò rỉ nằm ở đâu
Candidate srflx là cái đáng quan tâm. Để có nó, trình duyệt gửi một gói UDP nhỏ tới máy chủ STUN, và máy chủ này trả lời bằng địa chỉ nó thấy. Nếu lưu lượng HTTP của bạn đi qua proxy nhưng lưu lượng UDP thì không, máy chủ STUN sẽ thấy kết nối thật của bạn, và trang giờ có một địa chỉ không khớp với địa chỉ mà máy chủ web thấy. Sự không khớp đó là kiểu rò rỉ kinh điển. Một trang chẩn đoán có thể cho thấy nó bằng cách so sánh hai địa chỉ.
Lưu ý điều gì đang và không diễn ra. Không có phương tiện nào được ghi lại. Không liên quan đến quyền micro hay camera. Gói tin đi tới bất kỳ máy chủ STUN nào mà trang chỉ định, nên máy chủ đó, như mọi máy chủ bạn liên lạc, thấy địa chỉ của bạn.
Trình duyệt đã thay đổi gì
Trước đây candidate host làm lộ địa chỉ LAN riêng như 192.168.1.23, vốn hữu ích để lấy vân tay mạng gia đình. Các trình duyệt hiện đại thay chúng bằng tên mDNS tạo ngẫu nhiên kết thúc bằng .local, nên trang thấy một cái tên mờ đục thay vì địa chỉ. Một công cụ chẩn đoán báo “được trình duyệt che” là đang mô tả những candidate đó. Firefox và Brave cũng có cài đặt ngăn việc thu thập candidate ngoài proxy, và một số tiện ích chặn hoàn toàn WebRTC.
Cấu hình an toàn với proxy
Có ba cách hiệu quả, với chi phí khác nhau. Tắt WebRTC ngăn được rò rỉ nhưng làm hỏng mọi trang cần đến nó. Buộc WebRTC chỉ dùng đường của proxy (chế độ “proxy-safe” ở một số trình duyệt) giữ cho cuộc gọi hoạt động khi proxy hỗ trợ UDP hoặc TURN, còn nếu không thì hoàn toàn không có candidate công khai. Để WebRTC hoạt động bình thường chỉ đúng khi proxy mang toàn bộ lưu lượng, như một VPN cấp hệ thống thường làm.
Cách nào phù hợp tùy vào công việc. Với một hồ sơ trình duyệt cô lập phải trông như ở một nơi duy nhất, quy tắc rất đơn giản: địa chỉ mà WebRTC để lộ phải là chính địa chỉ mà máy chủ web thấy, hoặc không có gì cả. Bất cứ thứ gì khác là một mâu thuẫn mà trang web có thể nhận ra mà không cần công cụ đặc biệt nào.
Đọc kết quả
Một công cụ chẩn đoán hiển thị các candidate quan sát được trong vài giây và so sánh bất kỳ candidate công khai nào với địa chỉ mà trang được truy cập từ đó. “Không lộ gì” cùng một số candidate bị che là kết quả bình thường, lành mạnh với trình duyệt giữ WebRTC bên trong proxy. Một địa chỉ công khai khác với địa chỉ của trang là thứ cần sửa.
