Nuestro cortafuegos actualmente bloquea el tráfico QUIC (UDP 443) que parece estar habilitado de forma predeterminada en Google Chrome. ¿Es seguro permitir el QUIC o debo esperar hasta que se implemente en todos los principales navegadores?
Entiendo que se ha desarrollado como una experimentación de Google con el objetivo de mejorar el rendimiento de las aplicaciones web.
QUIC por sí mismo no es más peligroso que TCP, UDP, HTTP .... Lo que importa es el contenido transferido con el protocolo. Si usa su firewall solo como un simple filtro de paquetes y no realiza ninguna inspección de contenido (es decir, malware, filtro de URL, etc.), no importa mucho si permite el QUIC o no. Si, en cambio, su firewall se usa para analizar el tráfico de HTTP (s), podría ser una buena idea eliminar el tráfico de QUIC para que el navegador continúe usando HTTP (s) y no omita el análisis con un protocolo que su firewall no comprende.
"¡Los ataques se pueden usar para negar a los clientes el acceso a cualquier aplicación de elección y hacer que los servidores desperdicien recursos!" A partir de ahora, no es particularmente peligroso. Todo lo que se indica a continuación solo puede causar denegación de servicio (conexión) y conexiones rotas, eso es todo.
QUIC utiliza 0-rtt (reanudación de sesión / tickets) que es potencialmente vulnerable a ataques de repetición, como se indica aquí ; también lo hace tls; tls 0-rtt se puede deshabilitar en Firefox, aunque no estoy seguro si hay opciones para deshabilitar 0-rtt para quic en los navegadores en este momento. Después de un poco más de excavación, incluso quic 1-rtt (protocolo de enlace de conexión) es / era (2015 en el momento del artículo) también vulnerable a MITM, ataques de reproducción de configuración de servidor, ataques de reproducción de token de dirección de origen y ataques de manipulación de paquetes:
Nos enfocamos en la implementación de QUIC7 en Chromium en nuestros ataques, ya que esto Es la implementación canónica. Nuestros ataques se desarrollaron en python. utilizando la biblioteca de scapy. Resumimos nuestros ataques, sus propiedades, e impactos en la Tabla 1. Repetir ataques. Config del servidor Replay Attack. Para llevar a cabo este ataque, un atacante primero debe recoger una copia del scfg del servidor de destino. Esto se puede hacer estableciendo activamente una conexión al servidor o escuchando pasivamente a un cliente para intentar una conexión. En cualquier caso, el scfg del servidor puede ser fácilmente recolectado de un completo, 1-RTT QUIC conexión apretón de manos. Una vez el el atacante tiene scfg, espera que el cliente objetivo intente iniciar una conexión. Cuando el atacante ve un mensaje de saludo desde el cliente, puede responder con un mensaje de suplantación falsificado utilizando el recolectó scfg y generó aleatoriamente valores de stk y sno:
SRC enlace
Tenga en cuenta que el artículo se escribió en 2015 y es probable que el protocolo haya evolucionado desde entonces.
Estoy de acuerdo con Steffan en que QUIC no es más peligroso que TCP o UDP o HTTP o cualquier otro protocolo de comunicación. Creo que para su caso de uso lo que realmente importa es la transferencia de datos a través del protocolo.
Como dijo Steffan, realmente depende del firewall y de las inquietudes que intenta resolver usando ese firewall. Hacer un modelo informal de amenazas (¿qué tipo de ataques / actores de amenazas son su principal preocupación? ¿Qué tipo de activos está tratando de proteger mediante el uso del firewall?) Y compartir algunas de sus inquietudes específicas en las preguntas con respecto a QUIC realmente ayudaría a otros para proporcionar respuestas definitivas.
Hablando sobre la seguridad del protocolo en sí mismo : no soy un experto en seguridad de protocolos, pero según mi entendimiento, todos los protocolos de comunicación pasan por un gran escrutinio por parte de investigadores y expertos en seguridad antes de ser declarado como estándar (generalmente a través de RFC). Con respecto a esto, QUIC no es tan maduro como TCP o UDP o HTTP, pero se ha realizado mucha investigación de seguridad alrededor del protocolo.
La investigación más relevante que pude recuperar es ¿Qué tan seguro y rápido es QUIC? Pruebas de seguridad y rendimiento probables: por Lychev et al . Básicamente, los autores introducen un modelo de seguridad para analizar los protocolos basados en el rendimiento como el QUIC y demuestran que el QUIC satisface su definición bajo supuestos razonables sobre los componentes básicos del protocolo.