De acuerdo

Introducción a la función de descifrado del trafico SSL en el NIP6000 de Huawei

24 0 0 0

Esta publicación seguimos con el dessarollo de los metodos para detectar tráfico cifrado SSL.Describimos el proceso para establecer una conexión SSL entre un cliente y un servidor cuando el NIP funciona como un proxy SSL y el proceso para descifrar el tráfico SSL por el NIP.

 

Protección del servidor

La Figura 1 muestra el proceso para establecer conexiones SSL entre el NIP y un cliente y entre el NIP y un servidor, y el proceso para descifrar el tráfico SSL en el escenario de protección del servidor.

 

Figura 1 Diagrama esquemático del intercambio de paquetes SSL en el escenario de protección del servidor


l1


1. Importe el certificado del servidor y la clave privada al NIP.


2. Un cliente envía un paquete de saludo de cliente para iniciar una nueva conexión SSL.


3. El NIP resuelve y almacena el paquete de saludo de cliente enviado desde el cliente, y envía su propio paquete de saludo de cliente al servidor.


4. El servidor responde al paquete de saludo de cliente y envía un paquete de saludo de servidor y un certificado de servidor al NIP.


5. El NIP implementa el protocolo de enlace SSL con el servidor y establece la conexión SSL como un cliente proxy.

Una vez establecida la conexión SSL, el NIP y el servidor negocian una clave simétrica. Esta clave simétrica se utiliza para el cifrado o descifrado cuando el tráfico de servicio se transmite entre el NIP y el servidor.

 

6. El NIP envía el propio paquete de saludo del servidor y el certificado del servidor importado en 1 al cliente.

 

7. El cliente verifica el certificado del servidor, implementa el protocolo de enlace SSL con el NIP y establece la conexión SSL.

Después de verificar el certificado del servidor, el cliente genera una clave simétrica local. Después de cifrar la clave simétrica utilizando la clave pública del certificado del servidor, el cliente envía la clave simétrica al NIP. Al recibir la clave simétrica cifrada, el NIP la descifra utilizando la clave privada en el certificado del servidor importado en 1. Esta clave simétrica se utiliza para el cifrado o descifrado cuando el tráfico de servicio se transmite entre el cliente y el NIP.


8. El cliente envía el tráfico del servicio cifrado con SSL (utilizando la clave simétrica) al servidor.

El NIP descifra el tráfico del servicio SSL enviado desde el cliente utilizando la clave simétrica y verifica la seguridad del contenido del tráfico descifrado.

9. El NIP vuelve a cifrar el tráfico que pasa la comprobación de seguridad de contenido al servidor.

10. El NIP vuelve a encriptar la clave simétrica negociada con el servidor. Cuando el tráfico encriptado llega al servidor, el servidor descifra el tráfico utilizando la clave simétrica nuevamente.

 

Protección del cliente

La Figura 2 muestra el proceso para establecer conexiones SSL entre el NIP y un cliente y entre el NIP y un servidor, y el proceso para descifrar el tráfico SSL en el escenario de protección del cliente.

 

Figura 2 Diagrama esquemático del intercambio de paquetes SSL en el escenario de protección del cliente


l2


1. Un cliente envía un paquete de saludo de cliente para iniciar una nueva conexión SSL.


2. El NIP resuelve y almacena el paquete de saludo de cliente enviado desde el cliente, y envía su propio paquete de saludo de cliente al servidor.

Al resolver el paquete de saludo de cliente, el NIP extrae el campo de Indicación de nombre de servidor (SNI) del paquete.


3. El servidor responde al paquete de saludo de cliente y envía un paquete de saludo de servidor y un certificado de servidor al NIP.


4. El NIP verifica la validez del certificado del servidor y vuelve a emitir un certificado del servidor utilizando el Certificado de descifrado SSL de acuerdo con el contenido del certificado del servidor.

Además de verificar el certificado del servidor y volver a emitir un certificado del servidor, el NIP extrae el campo SAN / CN del certificado del servidor (certificado del servidor verdadero) para realizar la comprobación de consistencia SNI y SAN / CN, y por lo tanto determina si se debe establecer el SSL conexión con el servidor.


5. El NIP implementa el protocolo de enlace SSL con el servidor y establece la conexión SSL como un cliente proxy.

Una vez establecida la conexión SSL, el NIP y el servidor negocian una clave simétrica. Esta clave simétrica se utiliza para el cifrado o descifrado cuando el tráfico de servicio se transmite entre el NIP y el servidor.


6. El NIP envía el propio paquete de saludo del servidor y el certificado del servidor generado en 4 al cliente.


7. El cliente verifica el certificado del servidor, implementa el protocolo de enlace SSL con el NIP y establece la conexión SSL.

Después de verificar el certificado del servidor, el cliente genera una clave simétrica local. Después de cifrar la clave simétrica utilizando la clave pública del certificado del servidor generado en 4, el cliente envía la clave simétrica al NIP. Al recibir la clave simétrica cifrada, el NIP la descifra utilizando la clave privada en el nuevo certificado del servidor. Esta clave simétrica se utiliza para el cifrado o descifrado cuando el tráfico de servicio se transmite entre el cliente y el NIP.


8. El cliente envía el tráfico cifrado con SSL (utilizando la clave simétrica) al servidor.


9. El NIP descifra el tráfico SSL enviado desde el cliente utilizando la clave simétrica y verifica la seguridad del contenido del tráfico descifrado.

El NIP vuelve a cifrar el tráfico que pasa la comprobación de seguridad de contenido al servidor.

10. El NIP vuelve a encriptar la clave simétrica negociada con el servidor. Cuando el tráfico encriptado llega al servidor, el servidor descifra el tráfico utilizando la clave simétrica nuevamente.


Certificado de descifrado SSL

Cuando funciona como un servidor proxy SSL, el NIP debe enviar el certificado al cliente para indicar la identidad. Sin embargo, el NIP no envía directamente el verdadero certificado del servidor al cliente o no simplemente envía su propio certificado al cliente. El NIP vuelve a emitir un nuevo certificado de servidor para el cliente utilizando el certificado de descifrado SSL de acuerdo con el contenido del verdadero certificado del servidor. Las razones son las siguientes:

 

Si el NIP envía directamente el certificado del servidor verdadero al cliente, porque el NIP no tiene la clave privada correspondiente a la clave pública en el certificado del servidor verdadero, el NIP no puede descifrar la información cifrada de la clave pública, no puede obtener la clave simétrica generado por el cliente y no puede descifrar el tráfico SSL enviado desde el cliente.

Como se muestra en la Figura 3, cuando el NIP vuelve a emitir un certificado utilizando el certificado de descifrado SSL, la clave pública del certificado se reemplaza por una clave pública RSA local del NIP. El cliente cifra la clave simétrica utilizando la clave pública del certificado y envía la clave simétrica cifrada al NIP. Debido a que el NIP almacena localmente la clave privada correspondiente a la clave pública, el NIP puede descifrar la información cifrada de la clave pública, obtener la clave simétrica generada por el cliente y descifrar el tráfico SSL enviado desde el cliente posteriormente.


Si el NIP envía directamente su propio certificado al cliente, el cliente genera una alerta de seguridad, indicando nombres de sitio inconsistentes en el certificado, porque la información de identidad del propietario en el certificado NIP es inconsistente con el servidor real, lo que afecta la experiencia del usuario.


Como se muestra en la Figura 3, cuando el NIP usa el certificado de descifrado SSL para volver a emitir un certificado, el campo Asunto en el nuevo certificado sigue siendo coherente con el del certificado del servidor verdadero. De esta manera, el cliente no genera la alerta de seguridad que indica nombres de sitio inconsistentes en el certificado.

 

Figura 3 NIPre-emisión de un certificado de servidor utilizando el certificado de descifrado SSL


l3


El certificado de descifrado SSL es un certificado de CA. Puede importarse desde el externo o generarse por la CA incorporada del NIP. Cuando se importa o genera el certificado de descifrado SSL, debe marcarse como confiable o no confiable.

 

No confiable: el cliente no confía en el certificado de descifrado SSL.

Al recibir un verdadero certificado de servidor, el NIP verifica el certificado. Si el verdadero certificado del servidor es ilegal (no es emitido por una CA confiable o es revocado), el NIP vuelve a emitir un certificado utilizando un certificado de descifrado SSL no confiable para el cliente. Como el cliente no confía en el certificado de descifrado SSL, las aplicaciones del cliente identifican el certificado como ilegal. En tal caso, una aplicación del cliente genera una alerta de seguridad que indica que el certificado del servidor es ilegal. Los usuarios pueden liberar la alerta o finalizar el acceso. De esta manera, el NIP entrega correctamente la información sobre el certificado ilegal del servidor al cliente, para que los usuarios puedan conocer los posibles riesgos de seguridad.


De confianza: el certificado de descifrado SSL se importa al navegador del cliente y es de confianza.

Si el verdadero certificado del servidor es válido, el NIP vuelve a emitir un certificado utilizando el certificado de descifrado SSL de confianza para el cliente. Como el cliente confía en el certificado de descifrado SSL, los navegadores del cliente identifican el certificado como válido.

 

Comprobación de consistencia SNI y SAN / CN

SNI es para el identificador del nombre del servidor. El SNI que se incluye en el paquete de saludo del cliente es el nombre de host DNS del servidor. Por ejemplo, cuando ingresa un nombre de dominio en un navegador para acceder a un servidor, el SNI en el paquete de saludo del cliente enviado por el cliente es el nombre de dominio de entrada. El Nombre alternativo del sujeto o Subject Alternative Name (SAN) y el Nombre común o Common Name (CN) son campos en el certificado del servidor. Al solicitar un certificado de servidor, puede usar el nombre de host DNS del servidor como SAN y CN. Por lo tanto, SNI y SAN / CN utilizados para acceder al servidor son consistentes. El NIP verifica la consistencia del SNI y SAN / CN para hacer frente a las excepciones.


Como se muestra en la Figura 4, 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 encriptadas con SSL en el NIP para prohibir los accesos. Sin embargo, si el usuario se entera de que el NIP permite el acceso al sitio web www.test.com, puede agregar el mapeo entre www.test.com y la dirección IP 1.1.1.1 a los archivos Hosts del sistema. Luego, el usuario accede al sitio web www.test.com. De acuerdo con la política2 que permite el acceso a www.test.com, el NIP 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 NIP agrega la verificación de consistencia entre el SNI y el SAN / CN a la detección de tráfico cifrado con SSL. En el escenario de detección de tráfico encriptado con SSL, después de que el usuario modifica el archivo del sistema Hosts, el SNI transportado en el paquete de saludo del cliente se modifica en consecuencia. Sin embargo, la SAN / CN en el certificado del servidor permanece sin cambios. De esta manera, el SNI en el paquete de saludo del cliente es inconsistente con el SAN / CN en el certificado del servidor. En función de los resultados de la comprobación de coherencia, el NIP identifica y bloquea el tráfico anormal (aunque el tráfico se libera de acuerdo con la política 2, todavía se bloquea después de que la comprobación de coherencia en el SNI y SAN / CN coincida con la política de bloqueo).

 

l4


La inconsistencia de SNI y SAN / CN no se debe definitivamente a la modificación del archivo del sistema Hosts. El escenario anterior es solo un ejemplo. En situaciones reales, el SNI y SAN / CN de algún tráfico son inconsistentes, pero el tráfico es normal. Por lo tanto, la comprobación de coherencia es solo una opción para la gestión del tráfico con cifrado SSL. Puede configurar el NIP para permitir o bloquear el tráfico cuando el SNI y el SAN / CN son inconsistentes.

 

Figura 4 Diagrama esquemático de la comprobación de coherencia SNI y SAN / CN


l5


Saludos.

 

FIN

Comunidad Huawei Enterprise
https://forum.huawei.com/enterprise/es/forums

 

#ComunidadEnterprise

#OneHuawei


  • x
  • convención:

Comentar

Responder
Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse

Aviso Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente

My Followers

¡Ingresa y disfruta de todos los beneficios para los miembros!

Inicia sesión

Comunidad Huawei Enterprise
Comunidad Huawei Enterprise