Desde 2018, Google ha impuesto el uso del protocolo HTTPS como protocolo de seguridad para los sitios web. Es probable que tu propio sitio haya integrado esta protección. ¿Deberías entonces creer que puedes descansar en tus laureles? No necesariamente. En realidad, las conexiones HTTPS pueden ser vulnerables si no están bien configuradas. Idealmente, la protección TLS que integren debe ser de un nivel alto. Las explicaciones siguen…
Internet se hizo popular entre el público en general a partir de 1995. Rápidamente, surgió la necesidad de establecer normas de seguridad.
En realidad, esta preocupación se sintió casi 10 años antes, cuando Internet llegaba principalmente al público de investigadores y académicos. Desde 1986, el gobierno estadounidense había creado un organismo de estandardización -que se volvió independiente después- el IETF o Internet Engineering Task Force.
En 1999, ante el aumento del poder de la Web y los riesgos que este nuevo medio podía representar en términos de seguridad, el IETF creó un protocolo de seguridad llamado TLS – Transport Layer Security. Su objetivo: cifrar las comunicaciones entre dos sistemas conectados a Internet. La versión más reciente (TLS 1.3) data de 2018.
Si utilizas un sitio web, este probablemente cumple con la norma HTTPS, la cual se basa en la norma de cifrado SSL. ¿Debes creer que tu sitio web está a salvo de todas las amenazas? No necesariamente.
HTTPS integra el TLS
Inicialmente, los sitios web estaban bajo la norma HTTP, la cual no era segura en absoluto. Los datos se transmitían tal cual, desde un servidor hasta la computadora utilizada para la consulta. Por lo tanto, era bastante fácil para un hacker interceptar este contenido, lo que podía incluir contraseñas, datos ingresados en un formulario, etc.
Para hacer la Web más confiable, la compañía Netscape, creadora del primer navegador web exitoso, desarrolló un protocolo de cifrado llamado SSL. Los sitios web que integraban esta protección se distinguían por la mención HTTPS. A finales de los años 2010, Google consideró que este cifrado era esencial y, para incentivar a los sitios web a evolucionar hacia HTTPS, comenzó a penalizar a los sitios HTTP en su motor de búsqueda.
¿Cuál es la diferencia entre HTTPS y TLS? Fundamentalmente, no existe. El SSL y por lo tanto el protocolo HTTPS integran el algoritmo TLS.
De hecho, HTTPS designa una implementación del cifrado TLS como una superposición del protocolo HTTP. Entonces, un sitio web que usa HTTPS se basa efectivamente en el cifrado TLS.
Si has leído lo que hemos mencionado más arriba, probablemente hayas sentido que el HTTPS no es necesariamente una protección suficiente en todos los casos. ¿Cómo se explica esto? Porque algunas implementaciones HTTPS todavía se basan en la norma inicial de 1999, es decir, TLS 1.0.
Por lo tanto, es necesario asegurarse de que el certificado TLS a HTTPS designa efectivamente el TLS 1.3. ¿Por qué es así?
¿Qué es un certificado TLS?
Un sitio web protegido con HTTPS integra un certificado TLS. Contiene datos sobre el propietario del dominio, y también la clave pública del servidor (calculada a partir de la clave privada que, a su vez, se mantiene confidencial), es decir, información crucial para la autenticación del servidor. Este tipo de certificado es emitido por una autoridad de certificación como Let’s Encrypt, DigiCert o GoDaddy, al propietario de un dominio.
Te es fácil consultar el certificado de cualquier sitio que visites. Justo antes de la dirección de un sitio web, haz clic en el pequeño ícono presente en la barra de direcciones. Podrás entonces consultar el certificado TLS presente en el servidor – a veces se le designa como «certificado SSL», debido a cierta confusión alrededor de la denominación de estos protocolos de cifrado.
La negociación TLS
Para comprender mejor cómo funciona el certificado, detallaremos lo que sucede cuando se establece una conexión entre una computadora y un servidor web a través de TLS.
Cuando escribes o seleccionas la dirección de un sitio web en tu navegador, comienza una “negociación TLS” (TLS handshake) entre tu computadora o smartphone y el servidor que aloja este sitio web.
Durante esta negociación, la computadora y el servidor:
- Indican qué versión de TLS (TLS 1.0, 1.2, 1.3) es utilizada.
- Se ponen de acuerdo sobre el cifrado que se implementará durante esta sesión de comunicación entre la computadora del usuario y el servidor. Recordemos que este cifrado enmascarará los datos intercambiados a un tercero que pudiera intentar interceptar los intercambios.
- Autentican la identidad del servidor, gracias a su certificado TLS. En otras palabras, el servidor debe probar su identidad a la computadora que realiza la consulta.
- Generan claves criptográficas que gestionarán el cifrado de los datos intercambiados entre ambas partes.
Lo que ha cambiado con TLS 1.3
Lo hemos visto. La primera etapa de la negociación concierne a la identificación de la versión de TLS utilizada. Ahora bien, las versiones TLS 1.0 y 1.1 son hoy en día consideradas obsoletas e insuficientemente seguras.
Varios ataques que tuvieron lugar alrededor de 2010 demostraron que existían fallos en la protección TLS básica. Entre las agresiones identificadas figuraban:
- BEAST (2011).
- CRIME (2012) y BREACH (2013).
- Heartbleed (2014)
Las grandes plataformas de cloud ya no gestionan TLS 1.0 desde hace mucho tiempo. El uso recomendado es el de TLS 1.3. ¿Por qué es así?
TLS 1.3, integra la noción de Perfect Forward Secrecy (PFS). Cada sesión se basa en una clave de protección efímera. Si alguna vez la clave privada de un servidor fuera comprometida, no sería posible para un hacker reconstruir los datos de una sesión anterior – el descifrado no funcionaría.
Si existe entonces un mensaje a transmitir es que es importante mantener las bibliotecas TLS actualizadas, en particular en un sitio de e-commerce. Herramientas como SSL Labs de Qualys te permiten estar seguro de ello.
