Является ли трафик WebRTC над TURN сквозным зашифрованным?

Трафик WebRTC зашифровывается с использованием DTLS - нормально. Но как насчет трафика, который передается через сервер TURN?

Я ищу надежный ресурс, который подтверждает, что трафик по-настоящему сквозной зашифрован (потому что "от конца до конца" иногда может означать несколько вещей). Поэтому я имею в виду

НЕ следует, что существует "сквозное" шифрование между одноранговым узлом и сервером TURN.

Но скорее,

чтобы он был сквозным между сверстниками
чтобы он не был расшифрован/повторно зашифрован на сервере TURN
И что нет никакого способа, чтобы сервер TURN мог получить доступ к секретному

Я не смог найти определенного ответа на этот вопрос.

Ответ 1

Место для поиска - это предлагаемый стандарт TURN, RFC 5766. Стандарт предоставляет средство для ретрансляции пакетов UDP, содержащих данные приложения между клиентом и одноранговым узлом:

После создания распределения клиент может отправлять данные приложения на сервер вместе с указанием того, к какому одноранговому узлу должны быть отправлены данные, и сервер будет передавать эти данные соответствующему партнеру. Клиент отправляет данные приложения на сервер внутри сообщения TURN; на сервере данные извлекаются из сообщения TURN и отправляются одноранговому узлу в дейтаграмме UDP. В обратном направлении одноранговый узел может отправлять данные приложения в дейтаграмме UDP на ретранслируемый транспортный адрес для распределения; сервер затем инкапсулирует эти данные в сообщение TURN и отправит его клиенту вместе с указанием того, какой одноранговый узел отправил данные.

Наивысший уровень, который обрабатывает TURN, является уровнем UDP. Он не понимает и не изменяет уровень данных приложения (в вашем случае - протокол WebRTC). В стандарте говорится:

Приложение, требующее, чтобы его данные не были изменены или подделаны, должны целостно защитить свои данные на уровне приложения.

Это означает, что вы можете целостно защитить свои данные приложения, а TURN будет передавать его без изменений. Вы также можете посмотреть подробности протокола TURN (который я не буду здесь повторять), которые показывают, что он просто обертывает и пересылает данные приложения.

Наконец, стандарт говорит об этом при подслушивании:

Конфиденциальность данных приложения, передаваемых TURN, лучше всего предоставленный самим протоколом приложения, поскольку выполняется TURN over TLS не защищает данные приложений между сервером и всматриваться. Если важна конфиденциальность данных приложения, приложение должно шифровать или иным образом защищать свои данные. Для Например, для СМИ в режиме реального времени конфиденциальность может быть обеспечена используя SRTP.

Рекомендация в этой выдержке заключается в защите конфиденциальности путем шифрования данных приложения с помощью протокола, такого как DTLS-SRTP, который использует WebRTC.

Поскольку TURN не интерпретирует или не изменяет данные приложения, он не добавляет никаких уязвимостей безопасности к трафику данных приложения WebRTC, который не присутствовал бы без использования TURN. Данные WebRTC зашифровываются между конечными точками WebRTC.

Теперь никто не может гарантировать, что "нет доступа к серверу TURN для доступа к тайне". Мошеннический TURN-сервер может попытаться атаковать "человек-в-середине" на вашем подключении так же легко, как и любой другой, кто может перехватывать ваши сетевые пакеты. Это правда, что использование реле TURN не ослабляет безопасность WebRTC.

До тех пор, пока DTLS будет реализован и будет использоваться должным образом, и если алгоритмы и шифры DTLS будут защищены, трафик WebRTC должен быть защищен от конца до конца. Часть использования любой схемы на основе SSL требует проверки сертификата другой конечной точки, как HTTPS. И так же, как HTTPS, для этого потребуется предварительный внеполосный обмен удостоверением подлинности или использование доверенной сторонней стороны. И точно так же, как HTTPS, если сертификаты не были правильно проверены, тогда дверь будет открыта для атаки MITM (кем бы то ни было, а не только серверами TURN).