Витоки WebRTC: чому ваша справжня адреса може проявитися навіть за проксі
WebRTC існує, щоб браузери могли спілкуватися напряму для дзвінків і демонстрації екрана. Для цього їм потрібно виявити адреси, за якими до них можна дістатися, і саме процес виявлення мають на увазі під «витоком WebRTC».
ICE-кандидати в одному абзаці
Коли сторінка створює RTCPeerConnection і починає пропозицію (offer), браузер збирає кандидатів: способи, якими інший вузол міг би до нього дістатися. Кандидат host — це адреса локального інтерфейсу. Кандидат server-reflexive (srflx) — це публічна адреса, з якої STUN-сервер побачив надходження запиту. Кандидат relay — це адреса сервера TURN. Кожен кандидат передається сторінці в текстовому рядку, що містить адресу, і саме так скрипт може її прочитати, навіть без жодного здійсненого дзвінка.
Де витік
Важливий кандидат srflx. Щоб його отримати, браузер надсилає невеликий UDP-пакет на STUN-сервер, який відповідає адресою, що побачив. Якщо ваш HTTP-трафік іде через проксі, а UDP-трафік — ні, STUN-сервер бачить ваше справжнє підключення, і тепер сторінка має адресу, що розходиться з тією, яку бачив вебсервер. Ця розбіжність і є класичним витоком. Діагностична сторінка може показати її, порівнявши дві адреси.
Зверніть увагу, що відбувається, а що ні. Жодних медіа не захоплюється. Жодного дозволу на мікрофон чи камеру не задіяно. Пакет іде на той STUN-сервер, який назвала сторінка, тож цей сервер, як і будь-який сервер, до якого ви звертаєтеся, бачить вашу адресу.
Що змінили браузери
Кандидати host раніше розкривали приватні адреси локальної мережі, такі як 192.168.1.23, корисні для створення відбитка домашньої мережі. Сучасні браузери замінюють їх випадково згенерованими іменами mDNS із закінченням .local, тож сторінка бачить непрозоре ім'я, а не адресу. Діагностика, що повідомляє «приховано браузером», описує саме їх. Firefox і Brave також пропонують налаштування, що зупиняють збір кандидатів поза проксі, а деякі розширення блокують WebRTC повністю.
Конфігурації, безпечні для проксі
Працюють три підходи з різною ціною. Вимкнення WebRTC запобігає витоку й ламає кожен сайт, якому він потрібен. Примусове використання WebRTC лише через маршрут проксі (режим «безпечний для проксі» в деяких браузерах) зберігає дзвінки робочими, якщо проксі підтримує UDP або TURN, а інакше зовсім не дає публічного кандидата. Залишити WebRTC працювати як звичайно правильно лише тоді, коли проксі несе весь трафік, як зазвичай робить системний VPN.
Який варіант правильний, залежить від завдання. Для ізольованого профілю браузера, що має виглядати як такий, що перебуває в одному місці, правило просте: адреса, яку розкриває WebRTC, має збігатися з адресою, яку бачить вебсервер, або її не має бути взагалі. Усе інше — суперечність, яку сайт може помітити без жодних особливих інструментів.
Як читати результат
Діагностика показує кандидатів, яких спостерігала протягом кількох секунд, і порівнює будь-якого публічного з адресою, з якої було досягнуто сторінку. «Нічого не розкрито» з кількома прихованими кандидатами — нормальний, здоровий результат для браузера, що тримає WebRTC всередині проксі. Публічна адреса, що відрізняється від адреси сторінки, — те, що потрібно виправити.
