ssl - ¿El SNI realmente se usa y es compatible con los navegadores?

cross-browser

Question

Puedo encontrar diversa información sobre SNI (ver Wikipedia ), pero no puedo encontrar ninguna estadística sobre el soporte real en los navegadores.

Lo mejor que pude descubrir es que debería funcionar en Windows XP con SP3.

¿Alguien sabe si SNI realmente se puede usar en la práctica?

Answer 1

Sí

No podrá admitir conexiones SSL desde XP con SNI. Sin embargo, permitir que los clientes de XP se conecten no se ajusta a algunos estándares de todos modos, por lo que es posible que deba abandonar a estos usuarios por otros motivos.

Son solo un pequeño porcentaje en 2016 y disminuyen. Si debe admitir a todos los usuarios con SSL, tendrá que cambiar dinámicamente, pero si solo necesita la gran mayoría ... seguro.

Answer 2

Creo que hay dos aspectos de esto, la interfaz de usuario y la parte de detección.

UX

<!--[if lt IE 7]>
<div>You''re using a browser that has high security risks (SSL, XSS, etc). Please consider upgrading it.</div>
<![endif]-->

Está claro que cualquiera que use IE6 or below una Windows XP IE6 or below tiene grandes posibilidades de estar en Windows XP y no admitir SNI. El otro que engaña a su usuario-agente no importa aquí.

Lado del servidor

1. Sniff para el usuario-agente. Aparecerá expresiones regulares después de que se realicen las pruebas de la unidad.
2. Use la implementación AJAX arriba.

Nota especial

El uso de la solución AJAX le proporciona una detección a prueba de balas al 99%, pero no se ajusta a un par de principios de desarrollo web.

• Mejora progresiva : está dando la misma solicitud de AJAX a todos los usuarios. Los usuarios que admiten SNI no deberían molestarse.
• Legado : no puede desaprobar este código fácilmente.
• Si está utilizando jQuery con sus solicitudes AJAX, puede afectar su código según el método $ .ajaxStop ().

Answer 3

El artículo de Wikipedia al que se hace referencia enumera las versiones de servidor y navegador compatibles. Internet Explorer 7 (Vista o superior, no XP) o posterior y Mozilla Firefox 2.0, por ejemplo. A menos que sepa que todos sus visitantes usan navegadores compatibles, no puede usar SNI (con múltiples certificados en una sola dirección IP) sin cortarlos de la parte de SSL de su sitio.

Answer 4

El problema son los clientes de Windows XP y Android <3.0 clientes. Desafortunadamente combinados, siguen siendo casi el 10% de los visitantes de muchos de nuestros sitios web. Además, aunque los usuarios de Blackberry tienen un volumen bajo, son algunos de nuestros clientes que pagan. XP, Blackberry y Gingerbread combinados hacen que SNI no sea aceptable en la mayoría de nuestros sitios web en este momento (febrero de 2015). Espero que este problema disminuya en aproximadamente un año o dos.

Actualización en noviembre de 2016 (21 meses después): ir a un sitio bastante estándar con ~ 10,000 visitas / mes. Enero de 2013 ~ 10% no SNI. Enero de 2014 ~ 6%, enero de 2015 <2%, enero de 2016 ~ 0.5%, noviembre de 2016 ~ 0.1% (1 en 1,000). Hicimos la transición en noviembre / diciembre de 2015. Sin embargo, ciertos mercados pueden tener una mayor cantidad de estos usuarios. Creé audiencias personalizadas en Google Analytics, por lo que es fácil ver el impacto. Simplemente defina por nombre de sistema operativo, la versión comienza con, y para XP, el navegador es IE.

Answer 5

Internet Explorer (todas las versiones; 6, 7 y 8) en Windows XP no son compatibles con SNI. Todos los demás trabajan. Realmente no sé cuántos usuarios en XP usan Internet Explorer, pero esa es la cantidad mágica de usuarios que no pueden usar SNI.

Soporte móvil:

Android default browser on Honeycomb or newer
Windows Phone 7
MobileSafari in Apple iOS 4.0 or later

Answer 6

Llegué tarde para responder esto, pero para todos los lectores que puedan estar interesados ​​en este tipo de solución. Simplemente detecte el navegador y el SO utilizando la función del lado del servidor y diga al visitante que use "Instalar y usar un navegador seguro para comprar en línea como Chrome o Firefox y proporcionar un enlace para descargar e instalar".

Esta es la mejor forma de hacer que las compras sean seguras para su cliente y esto tiene dos propósitos, un uso de SSL habilitado para SNI y hacer que las compras del cliente sean seguras. Debido a que esos navegadores obsoletos en XP no son realmente seguros independientemente del servidor que use SSL habilitado para SNI o no.

Podemos arriesgar esto, porque el porcentaje de usuarios que usan versiones anteriores de IE en XP está por debajo del 5% en EE. UU. Y es insignificante o cero en otros países. De hecho, las personas de otros países están acostumbradas a los navegadores de código abierto.

Mi propia experiencia, alojo muchos sitios web para mí y para muchos clientes y tengo SSL para todos ellos que usan tecnología SNI sin IP dedicada y estoy bastante seguro de que la gente ha cambiado a Chrome o Firefox en muchos países, casi todos ellos y en EE. UU., el 95% de ellos.

Perdóname por cualquier información inexacta.

Answer 7

Puedo compartir mi experiencia y enfoque para cambiar de un certificado de IP por certificado en un entorno de alojamiento virtual (dominios múltiples por servidor) a un entorno de equilibrio de carga con una dirección IP para todos los dominios.

Observamos nuestros analíticos (más de 1 millón de visitantes únicos / mes), que en su mayoría son usuarios masculinos norteamericanos que buscan comprar autopartes en línea, y el 8 de marzo de 2014 descubrieron que aproximadamente el 4% de los usuarios usaban Windows XP usando Internet Explorer ( otros fueron menores; en el peor de los casos, el 4,5% del total de usuarios se vería afectado por no apoyar el SNI). Tenga en cuenta que no tenemos "control" sobre estos usuarios, por lo que no podemos decirles que cambien navegadores. Este porcentaje también está cayendo bastante rápido, al menos en los EE. UU.

Primero decidimos que estaba "bien" para los clientes que no tienen SNI tener una experiencia algo diferente a la de los clientes que soportan SNI.

Nuestro enfoque fue detectar el lado del servidor (usando la cadena UA), que combinación de navegador / sistema operativo no es compatible con SNI (como otras personas mencionaron: artículo de Wikipedia sobre soporte de SNI ). Todos nuestros dominios (~ 120) tendrían un registro A apuntando a una única IP de carga equilibrada. Tuvimos un segundo IP (también equilibrio de carga) para un dominio que podemos llamar generic-autoparts.com.

Entonces la configuración es [No estoy asociado con ningún dominio que utilizo como ejemplos a continuación]:

mikesautoparts.com -> Un registro de servidor de nombres de IP X
dansautoparts.com -> Un registro de servidor de nombres de IP X
jensautoparts.com -> Un registro de servidor de nombres de IP X
... etc

generic-autoparts.com -> Un registro de servidor de nombres de IP Y

Si un cliente visita http://www.dansautoparts.com y admite SNI, no ocurre nada. Busca en dansautoparts.com, y cuando llega el momento de verificar, usa https://www.dansautoparts.com .

Si un cliente visita http://www.dansautoparts.com y detectamos que no admite SNI, inmediatamente redirigiremos al cliente a http://generic-autoparts.com/dansautoparts.com . Él compra allí, y al pagar utiliza https://generic-autoparts.com/dansautoparts.com

Ahora, si un cliente visita https://www.dansautoparts.com DIRECTAMENTE (enlace en el correo electrónico, página indexada en los motores de búsqueda), no tiene suerte. Recibirán un desagradable error de certificado. En nuestro caso, nos aseguramos de que todos los correos electrónicos que nuestro sistema enviaba no utilizaran https, y sabíamos que los motores de búsqueda no habían indexado nuestras páginas https.

Cada entorno tiene diferentes desafíos y posibles compensaciones. Descubrimos que esto funcionó bien en nuestro caso y los clientes "aceptaron" (o no lo notificaron) siendo redirigidos a http://generic-autoparts.com/[ORIGINAL DOMAIN] .com. También mantuvimos el pago seguro a través de generic-autoparts.com.

Digamos que el 20% de los usuarios no SEN notan la redirección, parece sospechoso, y se van. En nuestro caso, eso es 0.8 - 0.9% (basado en los números del 8 de marzo de 2014) de usuarios y estábamos dispuestos a "vivir" con eso. No tengo datos específicos sobre esto en este momento, pero las ventas generales se mantuvieron constantes. [EDIT 28/03/2014: No vimos ningún impacto en las ventas después de cambiar al 100% de nuestros clientes]

Actualización de implementación 8 de julio de 2014

Resulta que es imposible detectar cada cadena de agente de AU estáticamente en el servidor. Implementamos el siguiente JavaScript para detectar la capacidad de SNI del navegador. El enfoque general es hacer una solicitud JSONP contra un dominio que requiere SNI (Apache admite esto a través de "SSLStrictSNIVHostCheck on"). Si la solicitud de JSONP falla al agotar el tiempo de espera, redirigiremos al cliente al dominio no de SNI.

Para complicar aún más las cosas, no queremos redireccionar a todos solo porque el SNI_TEST_DOMAIN está inactivo. Si la solicitud JSONP falla (al agotarse el tiempo ya que no hay manera de detectar una falla JSONP directamente), verificamos que el servidor esté disponible haciendo una solicitud HTTP de "comprobación de estado". Además, no queremos ejecutar este código JavaScript en cada carga de página, ya que aumenta la posibilidad de un tiempo de espera extraño y redirecciona incorrectamente a muchos clientes, por lo que establecemos una variable de sesión una vez que se realiza la verificación SNI para que no suceda de nuevo a medida que el cliente navega por los sitios.

Sabemos que recibimos ciertos controles falsos que fallan debido a que el tiempo de espera de JSONP no es confiable, pero desde la implementación de esto no recibimos quejas de los clientes.

var redirect=''http://REPLACE_WITH_NON_SNI_URL'';
var sni_https_timeout, sni_http_timeout;
var https_req = $.ajax({
url : ''https://SNI_TEST_DOMAIN.com/snitest.php'',
dataType : "jsonp",
}).done(function() {
window.clearTimeout(sni_https_timeout);
var request = $.ajax({
url: "index.php?ua=sni_check_done",
type: "POST"
});
})
sni_https_timeout = window.setTimeout(function() {
var http_req = $.ajax({
url : ''http://SNI_TEST_DOMAIN/sni_healthcheck.php'',
dataType : "jsonp"
}).done(function()
{
window.clearTimeout(sni_http_timeout);
window.setTimeout(function()
{
window.location = redirect;
},
200);
});
sni_http_timeout = window.setTimeout(function() { sni_http_fail(); }, 8000);
}, 8000);
function sni_http_fail() {
var request = $.ajax({
url: "index.php?ua=sni_check_done",
type: "POST"
});
}

snitest.php / sni_healthcheck.php:

<?php
if (array_key_exists(''callback'', $_GET))
{
header( ''Content-type: application/javascript'' );
echo "{$_GET[''callback'']}();/n";
}

Answer 8

http://caniuse.com/#feat=sni actualmente dice que SNI es compatible con el 97.6% de los navegadores.