La "S" de HTTPS no significa SSL.
Es natural suponer que cuando vemos un icono de candado en nuestros navegadores, el sitio está utilizando SSL para proteger nuestras comunicaciones. Aparentemente, también es una señal para los consumidores de que el sitio es, de hecho, seguro . Tanto es así que, según la Encuesta de Confianza del Consumidor de 2015 del Consejo de Seguridad de CA, “solo el tres por ciento daría la información de su tarjeta de crédito a sitios que no tuvieran el ícono de un candado”.
El impacto no se limita a los consumidores. Los encuestados en nuestra última encuesta sobre el estado de la entrega de aplicação que ya habían implementado o planeaban implementar “SSL Everywhere” tenían mayor confianza (un 3 o más en una escala de 1 a 5) en la capacidad de su organización para resistir un ataque a la capa de aplicação .
La verdad es que la mayoría de las personas no pueden explicarte qué significa SSL, y mucho menos describir cómo funciona. Lo que sí saben, sin embargo, es que se trata de un mecanismo para garantizar la seguridad de las transacciones (y, por tanto, de la información confidencial) mientras se interactúa con una aplicación o un sitio web.
Esto es en parte culpa nuestra (y del mercado). Hemos utilizado SSL como descripción tanto del protocolo ( RFC 6101 ) como una forma genérica de describir una conexión segura. SSL es la curita de la seguridad, el Google de los motores de búsqueda, el Kleenex de los pañuelos.
La realidad es que HTTPS en realidad no requiere SSL. La “S” en “HTTPS” significa seguro y simplemente requiere algún método para proteger las conexiones entre dos puntos finales, como un navegador y un sitio web. En aumento, en realidad significa HTTP sobre TLS, no SSL.
Esa es una diferencia importante porque, aunque comparten raíces, TLS no es SSL no es TLS. Son protocolos diferentes, cada uno con sus propios desafíos, problemas e impactos. Ambas conexiones seguras de la misma manera (utilizan certificados para la autenticación y pares de claves públicas y privadas para el cifrado), pero las diferencias de implementación persisten.
¿Por qué debería importarte? Debería preocuparle porque los protocolos de aplicação web más recientes (y quizás los mejores, eso está por verse) (HTTP/2 y SPDY) no admiten SSL. Son compatibles con TLS. No lo requieren, per se, pero las implementaciones de navegador que admiten ambos solo ofrecen soporte a través de TLS. No SSL.
Es cierto que hoy en día no hay una cantidad significativa de sitios que utilicen HTTP/2 o SPDY, pero está creciendo. Consideremos que el 7,5 % de los 1000 sitios principales ahora ofrecen contenido a través de HTTP/2:
De W3CTech (julio de 2015):
El nuevo estándar HTTP/2 , cuya versión final se publicó en mayo de 2015, lo utilizan ahora el 0,4% de todos los sitios web (frente al 0,24% a principios de mes) y el 7,5% de los 1.000 sitios más importantes .
Ahora consideremos que no estamos hablando sólo de navegadores y servidores. También tenemos que considerar lo que eso significa para la integración, para el uso de API que provienen de algunos de esos 1000 sitios principales (como Google) que pueden estar forzando el uso no solo de HTTP/2 o SPDY, sino también de TLS. Todos los servicios públicos de Google que ofrecen cifrado utilizan TLS. Si está integrando alguna funcionalidad de Google, es posible que le importe que utilicen TLS en lugar de SSL. Porque hace la diferencia debajo del capó.
Tenga en cuenta también que existen ramificaciones comerciales. Según PCI, ya no se podrá utilizar SSL después del 30 de junio de 2016. Después de ese punto, TLS se requiere explícitamente. Eso implica algunos cambios para cumplir con PCI. Y claro que lo haces, porque si no lo haces, hay muchas consecuencias. Podría, por ejemplo, dar lugar a tarifas de cuenta comercial más altas y multas por parte de los emisores de tarjetas de crédito o la revocación total de su capacidad para procesar pagos y transacciones. Si ocurre una violación, su empresa correrá un mayor riesgo de recibir demandas y multas debido a su falta de diligencia debida en materia de seguridad.
Por último, existe este RFC ( RFC 7568 ) redactado con mucha fuerza que explica por qué realmente debería migrar a TLS:
3. No utilice SSL versión 3.0
Ahora bien, no es factible asumir que vas a salir corriendo y cambiar de SSL a TLS en este preciso instante. Después de todo, aunque TLS se basa en SSL v3, no es 100% compatible con su predecesor y se necesitan algunos cambios de configuración para deshabilitar SSL y forzar el uso de TLS. Cambios de configuración que generalmente requieren reinicio. En un entorno grande, este proceso es comprensiblemente disruptivo y requiere mucho tiempo.
Pero es hora de comenzar a considerar seriamente durante cuánto tiempo desea brindar soporte a SSL y cuándo desea cambiar a TLS puro.