Estamos desaprobando la compatibilidad con TLS 1.0 y 1.1 en nuestros sitios web porque ya no se consideran seguros.
¿Cómo podemos ver el porcentaje de nuestros visitantes que se verían afectados por este cambio? (es decir, aquellos visitantes que no son compatibles con TLS 1.2).
Usamos Windows Server 2012 R2 con IIS8.
Respuesta1
Configure un segundo servidor (como una máquina virtual o un segundo demonio en el mismo host). Utilice una regla de reescritura paraproxy inversosolicitudes de algo opcional para el segundo servidor, como una imagen invisible oculta en la página. Configure el segundo servidor para permitir solo TLS 1.2; no establezca un vínculo directo a otro nombre de host... asegúrese de utilizar el proxy, o no será seguro, por lo que tal vez el navegador tenga una advertencia, o tal vez simplemente nunca cargue la imagen.
Luego realice un seguimiento de las solicitudes de la imagen. Los clientes sin soporte deberían tener errores SSL/TLS. Los clientes con soporte generarían algunos registros de '200 OK'. Si el registro no dice nada útil, intente utilizar un proxy con javascript, que puede realizar una solicitud AJAX para registrar el tráfico cuando tenga éxito (pero un bloqueador de secuencias de comandos puede detener esto).
Para probar la compatibilidad con SSL/TLS de su segundo servidor antes de confiar en que los registros tengan sentido, utilice una buena prueba como nmap, que puede enumerar muchos detalles.
nmap --script ssl-enum-ciphers example.com
Respuesta2
No conozco ninguna forma de verificar los registros del servidor para ver qué protocolo SSL/TLS se usó para la conexión del servidor Windows (es bastante fácil con Nginx y Apache).
Entonces, la mejor manera que se me ocurre de hacerlo es si utiliza algún software de análisis (por ejemplo, Google Analytics) que rastree las versiones del sistema operativo y del navegador. Esto no será 100% exacto (algunas personas desactivan JavaScript y/o el seguimiento en sus navegadores).
Tenga en cuenta que usar Google Analytics o similar esmuchomejor que intentar descifrar el críptico campo USER_AGENT, aunque en teoría esa es otra forma de hacerlo y probablemente se registrará en los registros de su servidor. Consulte aquí para obtener más detalles sobre cómo hacerlo de esa manera si lo desea:https://stackoverflow.com/questions/17798944/get-browser-name-and-version-from-iis-log-file-in-log-parser.
Una vez que tenga el navegador y la versión del sistema operativo de sus visitantes, puede consultar esta tabla para ver si son compatibles con TLS 1.2: https://en.m.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers, y eso debería permitirle calcular un porcentaje aproximado.
También puede utilizar la herramienta de escaneo ssllabs (https://www.ssllabs.com/ssltest/) que escaneará su sitio para probar su configuración SSL/TLS, incluido un mensaje que le indicará qué versión de TLS y qué cifrado utilizará una lista de navegadores de referencia. Recomiendo encarecidamente realizar este escaneo de todos modos para ver el estado de su configuración SSL/TLS.
Lo que más le preocupará serán las versiones anteriores de IE y las versiones anteriores de Android.
También puede realizar una detección del navegador en su sitio web para agregar una advertencia a estos usuarios durante aproximadamente un mes antes de desactivar TLS 1.0 y 1.1. Es muy fácil tener una declaración "[if lt IE 11]" para incluir una hoja de estilo CSS que muestra una advertencia para versiones anteriores de IE. Sin embargo, IE10 ya no admite esta sintaxis en modo estándar y es un navegador afectado. Tampoco es tan fácil hacer esto para navegadores Android más antiguos.
Respuesta3
Una posibilidad sería utilizar un proxy inverso (Squid, Apache, etc.) que pueda registrar la versión del protocolo de enlace SSL/TLS. Alternativamente, si tiene un número muy limitado (hablando de un solo dígito) de hosts de servicios web, puede usar Wireshark directamente en el servidor para analizar los apretones de manos.