¿Qué impacto de seguridad tiene el servidor TLS al continuar el intercambio cuando se le presenta un SNI no válido?

3

RFC 6066 define Indicación del nombre del servidor como una extensión, por lo que los servidores web virtualizados pueden recibir una extensión SNI para saber qué certificado debe presentarse.

Tiene lo siguiente que decir sobre los casos en que el nombre del servidor indicado no coincide con un nombre conocido (énfasis mío):

  

Si el servidor entendió la extensión de ClientHello pero no reconoce el nombre del servidor, el servidor DEBERÍA realizar una de dos acciones: abortar el protocolo de enlace mediante el envío de una alerta de nombre no reconocido (112) de nivel fatal o continuar el protocolo de enlace . NO SE RECOMIENDA enviar una alerta de nivel no reconocido (112) de nivel de advertencia, porque el comportamiento del cliente en respuesta a las alertas de nivel de advertencia es impredecible. Si existe una discrepancia entre el nombre del servidor utilizado por la aplicación cliente y el nombre del servidor de la credencial elegida por el servidor, esta discrepancia se hará evidente cuando la aplicación cliente realice la identificación del punto final del servidor, momento en el cual la aplicación cliente deberá Decidir si proceder con la comunicación. Se recomienda a las implementaciones de TLS que pongan la información a disposición de quienes llaman a la aplicación sobre las alertas de nivel de advertencia que se recibieron o enviaron durante un protocolo de enlace de TLS. Dicha información puede ser útil para fines de diagnóstico.

¿Cuál es el impacto potencial en la seguridad de continuar el protocolo de enlace cuando se envía un SNI no válido? Estoy pensando especialmente en los casos en que se proporciona un completamente dominio diferente, o un subdominio incorrecto. ¿Cuál es la razón de compatibilidad detrás de no rechazar tales solicitudes? Mis pruebas limitadas mostraron que el envío de "microsoft.com" en el campo SNI a un servicio TLS en google.com no rechazó mi contenido, mientras que hacer lo mismo con un servicio habilitado para CloudFlare causó la alerta fatal.

    
pregunta Polynomial 14.04.2016 - 16:39
fuente

1 respuesta

4

No hay ningún impacto en la seguridad para detener o continuar el protocolo de enlace: la seguridad se basa en las pruebas realizadas por el cliente, no por el servidor. Esta es la razón por la que la extensión se denomina indicación . Lo que importa es que el cliente verifique debidamente que la clave pública aparente del servidor es realmente propiedad del servidor deseado. El SNI es una forma para que el cliente transmita al servidor una sugerencia sobre el proceso que el cliente utilizará para esa verificación: a saber, el cliente verificará que el certificado del servidor es válido, y que identifica un nombre de servidor específico.

Incluso si el servidor ve que el SNI coincide con su propio certificado, el cliente todavía tiene que hacer todas las comprobaciones.

En caso de falta de coincidencia de SNI (el cliente envía un nombre para el que el servidor no tiene un certificado coincidente), continuar con el protocolo de enlace puede ser algo útil para enviar un mensaje de error explícito. El usuario humano, en el lado del cliente, tendrá que "hacer clic" en la advertencia, y los usuarios humanos deberían estar realmente entrenados para no hacerlo, pero si lo hacen, pueden ver una página enviada por el servidor que indicará exactamente que ("Este no es el sitio web que está buscando"). Con una alerta de nivel SSL, todo lo que el usuario verá será el genérico "No se pudo conectar, verifique su conexión a Internet" que es terriblemente poco informativo.

    
respondido por el Tom Leek 14.04.2016 - 16:56
fuente

Lea otras preguntas en las etiquetas