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.