¿Puedo detectar si el cliente SSL no admite la Indicación de nombre del servidor y proporcionar el sitio web HTTP estándar en ese caso?

Necesitaré usar SSL SNI, pero desafortunadamente de una publicación reciente en el blog de Cloudflare solo el 90% de la red lo admite. ¿Cómo puedo (por ejemplo, con nginx) detectar si el cliente admite SNI y proporcionar / redirigir a la versión HTTP del sitio web? es posible? ¿De qué otra forma no puedo perder el 10% del tráfico usando SNI? ¿Es correcto suponer que no podría redirigir el tráfico HTTPS a HTTP sin un certificado válido y, por lo tanto, esta solicitud es imposible?

Gracias.

Si desea ofrecer HTTPS desde el inicio, debe proporcionar un certificado aceptado por el cliente desde el inicio. Porque de lo contrario, el cliente no aceptará la conexión SSL y no podrá redirigir el cliente a un sitio diferente o una versión solo HTTP. Esto significa apoyar este caso usted

• o bien debe tener un único certificado que contenga todos sus dominios, de modo que pueda proporcionar a los clientes que no son SNI un certificado adecuado. Pero en este caso no necesita SNI en absoluto.
• o debe instalar algún certificado predeterminado que no coincida con la mayoría de sus nombres. En este caso, solo puede proporcionar al cliente una página diferente o redirigirla si el cliente acepta este certificado incorrecto.

Si no necesita tener HTTPS desde el principio, es decir, si el cliente generalmente se conecta primero con HTTP simple, puede intentar detectar el soporte SNI para poder redirigir el cliente más tarde. Esto puede hacerse mediante la inclusión de una imagen, algunos JavaScript o cosas similares de su sitio HTTPS y si la carga se realiza correctamente, entonces sabe que el cliente admite SNI o ignora los errores de certificado.

Por supuesto, esto deja todo abierto a los ataques de hombre en el medio, porque todo lo que tiene que hacer el hombre en el medio es entregar un certificado diferente o hacer que HTTPS no esté disponible, porque en este caso nunca lo intentará para actualizar la conexión a HTTPS. Además, esto se puede usar para que parezca que los clientes admiten SNI, si el intermediario lo hace en su lugar. Y no solo los clientes no SNI se ven afectados por esto, sino que los clientes con capacidad SNI solo pueden ser interceptados. Entonces, si bien esto sería posible en teoría, no se recomienda porque puede simplemente manipular todo en el medio y, por lo tanto, hacer que el punto principal del uso de HTTPS sea discutible.

Como publiqué en StackOverflow , solo puede probar el soporte SNI antes de requerirlo. Es decir, no puede forzar a los usuarios a SNI HTTPS y luego retroceder si no lo admiten, porque recibirán un error como este (de Chrome en Windows XP) sin forma de proceder.

Entonces (desafortunadamente) el usuario tiene que comenzar con una conexión HTTP insegura y luego actualizarse solo si admite SNI.

Puede detectar el soporte SNI a través de:

1. Script remoto
   Desde su página HTTP simple, cargue una <script>desde su servidor SNI HTTPS de destino y si el script se carga y ejecuta correctamente, sabe que el navegador admite SNI.

2. Cross-Domain AJAX (CORS)
   Similar a la opción 1, puede intentar realizar una solicitud AJAX entre dominios desde la página HTTP al HTTPS, pero tenga en cuenta que CORS solo tiene un soporte de navegador limitado .

3. Sniff the user-agent
   Este es probablemente el método menos confiable, y tendrá que decidir entre tener una lista negra de navegadores (y sistemas operativos) que no son compatibles, o una lista blanca de sistemas conocidos que lo hacen.

   Sabemos que todas las versiones de IE, Chrome y Opera en Windows XP y versiones posteriores no son compatibles con SNI. Consulte CanIUse.com para obtener una lista completa de los navegadores compatibles .