Desde los primeros días de la web, el protocolo SSL y su descendiente, TLS, han proporcionado el cifrado y la seguridad que hacen posible el comercio moderno por Internet.
La historia de estos protocolos durante décadas ha estado marcada por actualizaciones continuas que apuntan a seguir el ritmo de los atacantes cada vez más sofisticados. La próxima versión importante del protocolo, TLS 1.3, se finalizará pronto, y la mayoría de las personas que tengan un sitio web querrán actualizarlo, porque los ciberdelincuentes se están recuperando.
¿Qué es SSL?
Secure Sockets Layer, o SSL por sus siglas en inglés, fue el nombre original del protocolo cuando fue desarrollado a mediados de la década de 1990 por Netscape, la compañía que creó el navegador web más popular en ese momento. SSL 1.0 nunca fue lanzado al público, y SSL 2.0 tuvo serias fallas. SSL 3.0, lanzado en 1996, se renovó completamente y sentó las bases para lo que siguió.
TLS vs. SSL
Cuando la siguiente versión del protocolo fue lanzada en 1999, fue estandarizada por el Grupo de trabajo de ingeniería de Internet (IETF, por sus siglas en inglés) y se le dio un nuevo nombre: Seguridad de la capa de transporte o TLS. Como señala la “especificación TLS”, “las diferencias entre este protocolo y SSL 3.0 no son dramáticas”. Por lo tanto, no es realmente una cuestión de TLS contra SSL; más bien, los dos forman una serie de protocolos continuamente actualizados y, a menudo, se agrupan como SSL/TLS.
El protocolo TLS encripta el tráfico de Internet de todo tipo. El más común es el tráfico web; sabe que su navegador está conectado a través de TLS si la URL de su dirección comienza con “https” y hay un indicador con un candado que le indica que la conexión es segura.
Pero TLS también puede ser usado por otras aplicaciones, incluyendo correo electrónico y usenet.
Cómo funciona SSL
El cifrado es necesario para comunicarse de forma segura a través de Internet: si sus datos no están cifrados, cualquiera puede examinar sus paquetes y leer información confidencial. El método más seguro de encriptación se llama criptografía asimétrica; esto requiere dos claves criptográficas (piezas de información, generalmente números muy grandes) para funcionar correctamente, una pública y otra privada.
Las matemáticas aquí son complejas, pero en esencia, puede usar la clave pública para cifrar los datos, pero necesita la contraseña privada para descifrarla. Las dos claves están relacionadas entre sí por una fórmula matemática compleja que es difícil de aplicar ingeniería inversa por fuerza bruta. Piense en la clave pública como información sobre la ubicación de un buzón bloqueado con una ranura en la parte frontal y la clave privada como la clave que desbloquea el buzón. Cualquiera que sepa dónde está el buzón puede poner un mensaje en él; pero para que alguien más lo lea, necesitan la clave privada.
Debido a que la criptografía asimétrica involucra estos problemas matemáticos difíciles, requiere una gran cantidad de recursos informáticos, tanto que, si la usara para cifrar toda la información en una sesión de comunicaciones, su computadora y la conexión se detendrían.
TLS soluciona este problema utilizando solo la criptografía asimétrica al comienzo de una sesión de comunicaciones para cifrar la conversación que el servidor y el cliente deben acordar en una clave de sesión única que ambos usarán para cifrar sus paquetes a partir de ese momento. El cifrado que utiliza una clave compartida se denomina criptografía simétrica y es mucho menos intensivo computacionalmente que la criptografía asimétrica. Debido a que esa clave de sesión se estableció utilizando criptografía asimétrica, la sesión de comunicación en su conjunto es mucho más segura de lo que sería de otro modo.
El proceso mediante el cual se acuerda la clave de las sesiones se llama un apretón de manos, ya que es el momento en que las dos computadoras que se comunican se presentan y están en el corazón del protocolo TLS.
Proceso de protocolo SSL
El proceso de protocolo de enlace es bastante complejo, y hay varias variaciones permitidas por el protocolo. Los siguientes pasos proporcionan un esquema amplio que debería darle una idea de cómo funciona.
- El cliente contacta con el servidor y solicita una conexión segura. El servidor responde con la lista de conjuntos de cifrado (kits de herramientas algorítmicas de creación de conexiones encriptadas) que sabe cómo usar. El cliente compara esto con su propia lista de suites de cifrado compatibles, selecciona una y le dice al servidor que ambos la usarán.
- El servidor luego entrega su certificado digital, un documento electrónico emitido por una autoridad de terceros que confirma la identidad del servidor. Discutiremos los certificados digitales con más detalle en un momento, pero por ahora lo más importante que debe saber sobre ellos es que contienen la clave de cifrado pública del servidor. Una vez que el cliente recibe el certificado, confirma la autenticidad del mismo.
- Utilizando la clave pública del servidor, el cliente y el servidor establecen una clave de sesión que ambos utilizarán durante el resto de la sesión para cifrar la comunicación. Hay varias técnicas para hacer esto. El cliente puede usar la clave pública para cifrar un número aleatorio que luego se envía al servidor para descifrar, y ambas partes luego usan ese número para establecer la clave de la sesión. Alternativamente, las dos partes pueden utilizar lo que se llama un intercambio de claves Diffie-Hellman, para establecer la contraseña de la sesión.
Este artículo en SSL.com, tiene un gran diagrama que describe cada paso de la comunicación en el transcurso del proceso de reconocimiento de TLS.
Como su nombre lo indica, la clave o contraseña de sesión solo es válida para el curso de una sesión de comunicaciones única e ininterrumpida. Si, por alguna razón, las comunicaciones entre el cliente y el servidor se cortan (debido a un problema de red, por ejemplo, o porque el cliente está inactivo durante demasiado tiempo), se requerirá un nuevo protocolo de enlace para establecer una nueva clave de sesión cuando se restablezca la comunicación.
¿Qué es un certificado SSL?
Volvamos al concepto de un certificado SSL. Como lo dejó en claro la descripción en la sección anterior, estos certificados están en el corazón del protocolo SSL/TLS: proporcionan al cliente la clave criptográfica pública necesaria para iniciar conexiones seguras. Pero su propósito va más allá de simplemente suministrar la clave en sí; también autentican que la clave está de hecho asociada con la organización que la ofrece al cliente.
¿Cómo funciona esto? Los certificados son emitidos por las Autoridades de Certificación (CAs, por sus siglas en inglés), que sirven como el equivalente de una oficina de pasaportes cuando se trata de confirmar identidades. Las organizaciones que desean ofrecer servicios encriptados por TLS deben comprar certificados de las AC, quienes a su vez verifican que las organizaciones sean quienes dicen ser.
Por ejemplo, si desea comprar un certificado para asegurar un sitio web en example.com, tendría que tomar algunas medidas para demostrar a la CA que usted controla el dominio example.com. De esa manera, si alguien se conecta a example.com y obtiene un certificado SSL válido emitido por una CA de confianza, puede estar seguro de que se está comunicando con el propietario legítimo de example.com. Esto puede prevenir el ataque de ‘hombre en el medio’.
Observe que usamos la frase “CA confiable” en ese último párrafo. Cualquiera puede establecerse como una autoridad de certificación; ¿Cómo puede saber cuáles realizan la diligencia debida necesaria para autenticar a sus clientes? Afortunadamente, averiguarlo está mayormente a cargo de los fabricantes de software. La Fundación Mozilla mantiene una lista de CA en la que Firefox confiará; Apple y Microsoft también mantienen listas que implementan a nivel de SO para Windows, macOS e iOS, que Chrome utiliza en esas plataformas. Las decisiones sobre en qué CA confiar tienen una gran importancia, como un enfrentamiento del 2017 entre Google y Symantec sobre lo que Google sintió fueron los estándares laxos de Symantec.
El estándar que define los certificados SSL se llama X.509. Este estándar permite que los certificados transmitan mucha información más allá de la clave pública y la identidad confirmada del propietario del certificado; DigiCert es una CA cuya base de conocimientos tiene un desglose detallado de la norma.
Comprobadores SSL
Casi todo el intercambio y la confirmación de la información detallada anteriormente se lleva a cabo tras bambalinas a medida que se comunica con los servidores que ofrecen conexiones cifradas TLS. Si desea obtener un poco más de transparencia, puede ingresar la URL de un sitio cifrado con SSL/TLS en un sitio web de SSL. El verificador devolverá una gran cantidad de información, sobre el certificado del sitio probado, incluido el tipo de servidor, que navegadores web confiarían o no en el certificado, el emisor, el número de serie, y la fecha de caducidad.
La mayoría de los verificadores de SSL son servicios gratuitos ofrecidos por las AC como herramientas de marketing para sus productos; muchos, por ejemplo, le permitirán establecer una alerta para cuando caduque un certificado inspeccionado, en el supuesto de que sea su certificado y usted estará en el mercado buscando uno nuevo a medida que se acerque esa fecha. Si está buscando una alternativa menos comercial, consulte el comprobador de SSL de Qualys SSL Labs, que proporciona una recopilación de información particularmente sólida en sitios web inspeccionados.
Vulnerabilidades de TLS 1.2TLS 1.2 es la versión definida más actual del protocolo, y lo ha sido durante varios años. Estableció una serie de nuevas opciones criptográficas para la comunicación. Sin embargo, al igual que algunas versiones anteriores del protocolo, también permitía el uso de técnicas criptográficas más antiguas para admitir computadoras más viejas. Desafortunadamente, eso lo abrió a las vulnerabilidades, ya que esas técnicas más antiguas se han vuelto más vulnerables a medida que el tiempo ha pasado y la potencia de cómputo se ha vuelto más barata.
En particular, TLS 1.2 se ha vuelto cada vez más vulnerable a los llamados ataques de “hombre en el medio”, en los que un pirata informático intercepta paquetes en la mitad de la comunicación y los envía después de leerlos o modificarlos. También está abierto a los ataques POODLE, SLOTH y DROWN. Muchos de estos problemas han surgido en los últimos dos años, aumentando la sensación de urgencia para actualizar el protocolo.
TLS 1.3
Afortunadamente, la ayuda está en camino. La versión 1.3 del protocolo TLS, actualmente en borrador, pronto se finalizará y cierra muchos de estos agujeros al desechar el soporte para sistemas de cifrados heredados. Existe compatibilidad con versiones anteriores en el sentido de que las conexiones recaerán en TLS 1.2 si un extremo no es capaz de usar los sistemas de cifrado más nuevos en la lista aprobada 1.3. Sin embargo, si, por ejemplo, un ataque “hombre en el medio” intenta forzar un retroceso a 1.2 con el fin de espiar paquetes, eso se detectará y la conexión se interrumpirá.
Todavía hay servidores que utilizan versiones de TLS incluso más antiguas que 1.2, algunos todavía utilizan el protocolo SSL original. Si su servidor es uno de esos, debe actualizarlo ahora, y simplemente saltar y actualizar a la especificación del borrador 1.3.
TLS crimeware
Una última nota sobre TLS y seguridad: ¡Los buenos no son los únicos que lo usan! Muchos ciberdelincuentes utilizan TLS para cifrar el tráfico de comando y control entre sus servidores y el malware instalado en las computadoras de sus víctimas. Esto termina invirtiendo el estado habitual de las cosas y deja a las víctimas de delitos informáticos en busca de una forma de descifrar el tráfico. Existen varias técnicas para tratar este tipo de ataque encriptado, incluyendo el uso de metadatos de red sobre el tráfico encriptado para tener una idea de lo que están haciendo los atacantes sin leer realmente ninguno de ellos.
-Josh Fruhlinger, CSO (EE.UU.)
