Comprobación de la coherencia de SNI y SAN/CN
SNI es el identificador del nombre del servidor. El SNI transportado en el paquete Client Hello es el nombre de host DNS del servidor. Por ejemplo, cuando se introduce un nombre de dominio en un navegador para acceder a un servidor, el SNI en el paquete Client Hello enviado por el cliente es el nombre de dominio introducido. El nombre alternativo del sujeto o Subject Alternative Name (SAN) y el nombre común (CN) son campos del certificado del servidor. Cuando se solicita un certificado de servidor, se puede utilizar el nombre de host DNS del servidor como SAN y CN. Por lo tanto, el SNI y el SAN/CN utilizados para acceder al servidor son consistentes. El FW verifica la consistencia del SNI y SAN/CN para hacer frente a las excepciones.
Como se muestra en la Figura 1, cuando un usuario accede al sitio web ilegal www.example.com utilizando el navegador Internet Explorer en el sistema Windows, puede establecer políticas de detección de tráfico cifrado SSL en el FW para prohibir los accesos. Sin embargo, si el usuario se entera de que el FW permite el acceso al sitio web www.test.com, puede añadir la asignación entre el www.test.com y la dirección IP 1.1.1.1 al archivo del sistema Hosts. Entonces, el usuario accede al sitio web www.test.com. De acuerdo con la política2 que permite el acceso a www.test.com, el FW permite las solicitudes de acceso. De esta manera, el usuario accede con éxito al servidor ilegal con la dirección IP 1.1.1.1 modificando la regla de mapeo.
Para evitar la situación anterior, el FW añade la verificación de la consistencia entre el SNI y el SAN/CN a la detección de tráfico cifrado SSL. En el escenario de detección de tráfico encriptado SSL, después de que el usuario modifique el archivo de sistema Hosts, el SNI transportado en el paquete Client Hello se cambia en consecuencia. Sin embargo, el SAN/CN en el certificado del servidor permanece inalterado. De esta manera, el SNI en el paquete Client Hello es inconsistente con el SAN/CN en el certificado del servidor. Basándose en los resultados de la comprobación de consistencia, el FW identifica y bloquea el tráfico anormal (aunque el tráfico se libera según la política2, sigue bloqueado después de que la comprobación de consistencia del SNI y el SAN/CN coincida con la política de bloqueo).
Nota:
Al comprobar la coherencia del SNI y del SAN/CN, el FW compara preferentemente el SAN con el SNI. Si el SAN es nulo, el FW compara el CN con el SNI. El CN es obligatorio para solicitar el certificado. Por lo tanto, es imposible que tanto el SAN como el CN sean nulos.
La inconsistencia de SNI y SAN/CN no es causada definitivamente por la modificación del archivo del sistema Hosts. El escenario anterior es sólo un ejemplo. En situaciones reales, el SNI y el SAN/CN de algún tráfico son inconsistentes, pero el tráfico es normal. Por lo tanto, la comprobación de consistencia es sólo una opción para la gestión del tráfico cifrado con SSL. Puede configurar el FW para permitir o bloquear el tráfico cuando el SNI y el SAN/CN sean inconsistentes.
Figura 1. Diagrama esquemático de la comprobación de consistencia de SNI y SAN/CN.
Saludos.
FIN.
También te puede interesar:
Guía de dimensionamiento firewall USG6000 Series NGFW
Descripción general de la función DNS utilizado en firewalls de Huawei.
Escenarios de aplicación borde de red y detección fuera de ruta para NIP6000
Conoce más de esta línea de productos en:
O pregúntale al robot inteligente de Huawei, conócelo aquí:
Infografía: Conoce a iKnow, el robot inteligente
