security webrtc dtls

security - ¿El tráfico de WebRTC sobre TURN de extremo a extremo está encriptado?



dtls (1)

El tráfico WebRTC se encripta utilizando DTLS - ok. Pero ¿qué pasa con el tráfico que se retransmite a través de un servidor TURN?

Estoy buscando un recurso confiable que confirme que el tráfico está verdaderamente encriptado de extremo a extremo (porque "de extremo a extremo" a veces puede significar varias cosas). Así que quiero decir

  • NO que haya un cifrado de "extremo a extremo" entre un par y el servidor TURN.

Sino más bien

  • que es de extremo a extremo entre los compañeros
  • de tal manera que no se descifre / vuelva a cifrar en el servidor TURN
  • Y que no hay forma de que el servidor TURN obtenga acceso al secreto

No he podido encontrar una respuesta definitiva a esto.


El lugar a buscar es el estándar propuesto por TURN, RFC 5766 . El estándar proporciona un medio para transmitir paquetes UDP que contienen datos de la aplicación entre un cliente y un par:

Una vez que se crea una asignación, el cliente puede enviar los datos de la aplicación al servidor junto con una indicación de a qué igual se enviarán los datos, y el servidor transmitirá estos datos al interlocutor apropiado. El cliente envía los datos de la aplicación al servidor dentro de un mensaje de TURN; en el servidor, los datos se extraen del mensaje TURN y se envían al interlocutor en un datagrama UDP. En la dirección inversa, un interlocutor puede enviar datos de la aplicación en un datagrama UDP a la dirección de transporte retransmitida para la asignación; el servidor luego encapsulará estos datos dentro de un mensaje de TURNACIÓN y los enviará al cliente junto con una indicación de qué pares enviaron los datos.

La capa más alta que analiza TURN es la capa UDP. No comprende ni modifica la capa de datos de la aplicación (en su caso, el protocolo WebRTC). La norma dice:

Una aplicación que desee asegurarse de que sus datos no se alteren o falsifiquen debe proteger su integridad a nivel de la aplicación.

Esto implica que puede proteger la integridad de los datos de su aplicación y TURN los retransmitirá sin modificaciones. También puede ver los detalles del protocolo TURN (que no repetiré aquí) que muestran que simplemente envuelve y reenvía los datos de la aplicación.

Finalmente, el estándar dice esto en las escuchas ilegales:

La confidencialidad de los datos de aplicación transmitidos por TURN es mejor proporcionada por el propio protocolo de la aplicación, ya que la ejecución de TURN sobre TLS no protege los datos de la aplicación entre el servidor y el par. Si la confidencialidad de los datos de la aplicación es importante, entonces la aplicación debe cifrar o proteger sus datos. Por ejemplo, para medios en tiempo real, la confidencialidad se puede proporcionar mediante el uso de SRTP.

La recomendación en este extracto es proteger la confidencialidad cifrando los datos de la aplicación con un protocolo como el DTLS-SRTP, que utiliza WebRTC.

Debido a que TURN no interpreta ni modifica los datos de la aplicación, no agrega ninguna vulnerabilidad de seguridad al tráfico de datos de la aplicación WebRTC que no estaría presente sin usar TURN. Los datos de WebRTC se cifran entre los puntos finales de WebRTC.

Ahora, nadie puede garantizar que "no hay forma de que el servidor TURN obtenga acceso al secreto". Un servidor TURN falso podría intentar un ataque de intermediario en su conexión tan fácilmente como cualquier otra persona que pueda interceptar sus paquetes de red. Solo es cierto que el uso de un relé TURN no debilita la seguridad de WebRTC.

Siempre que DTLS se implemente y use correctamente y asumiendo que los algoritmos y cifrados de DTLS sean seguros, el tráfico WebRTC debe estar asegurado de extremo a extremo. Parte del uso de cualquier esquema basado en SSL requiere verificar el certificado del otro extremo, al igual que HTTPS. Y al igual que HTTPS, esto requerirá un intercambio fuera de banda previo de la identidad del certificado o el uso de un tercero de confianza. Y al igual que HTTPS, si los certificados no se verifican correctamente, la puerta estará abierta para un ataque MITM (por cualquiera, no solo por los servidores TURN).