Зашифрован ли трафик WebRTC через TURN сквозным?

Question

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

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

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

Скорее,

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

Я не смог найти однозначного ответа на это.

Answer 1

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

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

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

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

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

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

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

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

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

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

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