Es natural suponer que, cuando vemos el icono de un candado en el navegador, el sitio utiliza SSL para proteger nuestras comunicaciones. Al parecer, también indica a los consumidores que el sitio es, de hecho, seguro. Tanto es así que, según la encuesta de confianza del consumidor de 2015 del CA Security Council, «solo el tres por ciento facilitaría los datos de su tarjeta de crédito a sitios que no mostraran el icono del candado».
El impacto no se limita a los consumidores. Los participantes en nuestra última encuesta Estado de la entrega de aplicaciones que ya habían implementado «SSL en todas partes» o tenían previsto hacerlo mostraban una mayor confianza (una puntuación de 3 o más en una escala del 1 al 5) en la capacidad de su organización para resistir un ataque a la capa de aplicación.
Lo cierto es que la mayoría de la gente no sabe qué significan las siglas SSL, y mucho menos cómo funciona. Sin embargo, sí sabe que es un mecanismo para garantizar la seguridad de las transacciones (y, por tanto, de la información potencialmente confidencial) al interactuar con una aplicación o un sitio web.
Eso es en parte culpa nuestra (es decir, del mercado). Hemos utilizado SSL tanto para referirnos al protocolo (RFC 6101) como de forma genérica para describir una conexión segura. SSL es el Band-Aid de la seguridad, el Google de los motores de búsqueda, el Kleenex de los pañuelos de papel.
La realidad es que HTTPS no requiere realmente SSL. La «S» de «HTTPS» significa seguro, y simplemente requiere algún método para proteger las conexiones entre dos extremos, como un navegador y un sitio web. Cada vez más, esto significa HTTP sobre TLS, no SSL.
Es una diferencia importante porque, aunque comparten un origen común, TLS no es SSL ni SSL es TLS. Son protocolos distintos, cada uno con sus propios retos, problemas y repercusiones. Ambos protegen las conexiones de la misma manera —utilizan certificados para la autenticación y pares de claves pública y privada para el cifrado—, pero siguen existiendo diferencias en su implementación.
¿Por qué debería importarle? Porque los protocolos de aplicaciones web más recientes (y quizá los mejores, aunque eso está por ver), HTTP/2 y SPDY, no son compatibles con SSL, sino con TLS. No lo exigen como tal, pero las implementaciones de los navegadores compatibles con ambos protocolos solo ofrecen soporte mediante TLS, no SSL.
Es cierto que hoy en día no hay un número significativo de sitios que utilicen HTTP/2 o SPDY, pero la cifra va en aumento. Tenga en cuenta que el 7,5 % de los 1000 sitios más populares ya ofrecen contenido mediante HTTP/2:
De W3CTech (julio de 2015):
El nuevo estándar HTTP/2, cuya versión definitiva se publicó en mayo de 2015, ya lo utiliza el 0,4 % de todos los sitios web (frente al 0,24 % a principios de mes), así como el 7,5 % de los 1.000 sitios web más visitados.
Ahora, tengamos en cuenta que no estamos hablando únicamente de navegadores y servidores. También debemos considerar qué implica esto para la integración, es decir, para el uso de API procedentes de algunos de esos 1000 sitios web más importantes (como Google), que pueden exigir 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, puede que le interese saber que utiliza TLS en lugar de SSL, porque esto marca una diferencia a nivel interno.
También hay que tener en cuenta las repercusiones empresariales. Según la normativa PCI, SSL dejó de poder utilizarse a partir del 30 de junio de 2016. Desde entonces, se exige explícitamente el uso de TLS. Esto implica realizar algunos cambios para seguir cumpliendo la normativa PCI. Y, por supuesto, es necesario cumplirla, porque no hacerlo conlleva numerosas consecuencias. Por ejemplo, podría dar lugar a un aumento de las comisiones de la cuenta de comerciante y a multas por parte de los emisores de tarjetas de crédito, o incluso a la revocación total de la capacidad para procesar pagos y transacciones. Si se produce una brecha de seguridad, su empresa correrá un mayor riesgo de afrontar demandas y multas por no haber actuado con la diligencia debida en materia de seguridad.
Por último, está este RFC redactado en términos muy contundentes (RFC 7568) que explica claramente por qué deberías pasarte a TLS:
3. No utilice SSL versión 3.0
SSLv3 NO DEBE utilizarse. Negociación de SSLv3 desde cualquier versión de TLS
NO DEBE permitirse.
Cualquier versión de TLS es más segura que SSLv3, aunque la más alta
Es preferible utilizar la versión más reciente disponible.
Ahora bien, no es realista pensar que vaya a cambiar de SSL a TLS de inmediato. Al fin y al cabo, aunque TLS se basa en SSL v3, no es totalmente compatible con versiones anteriores y es necesario realizar algunos cambios de configuración para deshabilitar SSL y forzar el uso de TLS. Estos cambios suelen requerir un reinicio. Como es comprensible, en un entorno de gran tamaño este proceso resulta problemático y requiere mucho tiempo.
Pero ha llegado el momento de empezar a plantearse seriamente durante cuánto tiempo se quiere seguir admitiendo SSL y cuándo se quiere pasar a utilizar exclusivamente TLS.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.