Protocolos SSL, TLS y HTTPS
SSL, TLS y HTTPS son protocolos criptográficos, que proporcionan comunicaciones seguras por una red, comúnmente Internet.
Sumario
- Definición
- Protocolo SSL «Secure Sockets Layer»
- Protocolo TLS «Transport Layer Security»
- HTTPS «Hyper Text Transfer Protocol Secure»
- Diferencias entre TLS y el protocolo SSL
- Los ataques BEAST y POODLE
- Protocolo de enlace TLS «TLS Handshake Protocol» (apretón de manos)
- Notificaciones de protocolo TLS y SSL
- Descripciones de alertas SSL
- Descripciones de alertas de TLS
Definición
Utilizamos los protocolos SSL/TLS para cifrar la información en una comunicación entre dos puntos. Normalmente un servidor y un cliente aunque también puede ser necesario cifrar la información compartida por dos servidores o dos clientes.
Se usan certificados X.509 y por lo tanto criptografía asimétrica para autenticar a la contraparte con quien se están comunicando, y para intercambiar una clave simétrica. Se establece una conexión en la que todo el flujo de datos está cifrado, garantizando la confidencialidad de los datos y de los códigos de autenticación de los mensajes para asegurar su integridad y su autenticidad. Nos encontramos con varias versiones del protocolo ampliamente implementadas en aplicaciones como: navegadores web, servidores de correo electrónico, fax por internet, mensajería instantánea y voz sobre IP «VoIP». Se utiliza «forward secrety» negociando una clave de corta vida para la sesión de manera que no pueda ser descubierta a partir de la clave asimétrica de largo plazo.
Protocolo SSL
SSL es el acrónimo de «Secure Sockets Layer» (capa de sockets seguros). Se trata de una tecnología para securizar las conexiones de internet y garantizar la confidencialidad de la información transmitida, impidiendo su vulneración por ciberdelincuentes que lean o modifiquen los datos transmitidos. Como hemos visto intervienen dos extremos en la comunicación. Por ejemplo, una web de compras y un navegador.
El protocolo se encarga de que los datos sean imposibles de leer utilizando algoritmos de cifrado para codificarlos. Tengamos en cuenta que esta transmisión puede incluir datos sensibles como: números de tarjeta de crédito y otros datos bancarios, nombres y direcciones, u otros datos que permitan identificar a una persona y sus condiciones personales.
Protocolo TLS
El protocolo TLS «Transport Layer Security» (seguridad de la capa de transporte) es una versión actualizada y más segura de SSL. Es habitual seguir hablando de certificados SSL, aunque normalmente ya esté implementado el protocolo TLS, con la opción de cifrado ECC, RSA o DSA.
El protocolo TLS, de «Internet Engineering Task Force» (IETF), fue definido en 1999 y actualizado en el RFC 5246 (agosto de 2008) y en el RFC 6176 (marzo de 2011). Está basado en especificaciones previas de SSL implementadas por «Netscape Communications» para añadir el protocolo HTTPS a su navegador «Netscape Navigator».
La última versión es TLS 1.3 de agosto de 2018.
HTTPS «Hyper Text Transfer Protocol Secure»
HTTPS «Hyper Text Transfer Protocol Secure» o protocolo seguro de transferencia de hipertexto, lo encontramos en la barra de direcciones del navegador «URLs», mostrando un candado, cuando un sitio web está protegido por un certificado SSL. Los detalles del certificado, como: la entidad emisora y el nombre del propietario del sitio web, los podemos consultar haciendo clic en el símbolo de este candado.
Diferencias entre los protocolos TLS y SSL
TLS es una evolución de SSL 3.0, para desarrollar la versión TLS 1.0, que implementa medidas de seguridad proporcionando encriptación de datos e integridad entre los canales de comunicación, que se habían visto expuestas en algunos ataques que ahora veremos.
SSL3.0 es un protocolo obsoleto, como demostraron los ataques POODLE, BEAST y alguno más, determinando que SSL3.0 no tuviera vida como protocolo de seguridad.
Los ataques BEAST y POODLE
Los ataques BEAST y POODLE, entre otros, han llevado a que SSL v3 esté siendo deshabilitado en sitios web de todo el mundo.
BEAST
Primero vino el ataque BEAST que rompía completamente los sitios web que se ejecutan en protocolos SSL v3.0 y TLS v1.0 más antiguos.
Thai Duong y Juliano Rizzo demostraron una «prueba de concepto» llamada BEAST, «Browser Exploit Against SSL/TLS», usando un applet Java para violar restricciones de políticas de mismo origen, por una vulnerabilidad de CBC ampliamente conocida de TLS 1.0. en septiembre de 2011.
No se conocían «exploits» prácticos de esta vulnerabilidad, la cual fue descubierta originalmente por Phillip Rogaway en 2002.
Podemos prevenir el ataque BEAST, eliminando todos los cifrados CBC de la lista de cifrados permitidos, dejando solamente el cifrado RC4, que es soportado por la mayoría de los sitios web.
POODLE
El ataque POODLE (en inglés, Padding Oracle On Downgraded Legacy Encryption) o «Relleno de oráculo en Degradación a Cifrado Obsoleto» fue publicado por investigadores de Google en octubre de 2014. Se trata de una vulnerabilidad en el diseño de SSL 3.0, que hace que el modo CBC de operación con SSL 3.0 sea vulnerable al ataque de relleno (CVE-2014-3566). En promedio, los atacantes solo necesitan hacer 256 peticiones SSL 3.0 para revelar un byte de mensaje cifrado.
Aunque esta vulnerabilidad solo existe en SSL 3.0 y la mayoría de los clientes y servidores admiten TLS 1.0 y superiores, los principales navegadores rebajan voluntariamente a SSL 3.0 los requerimientos si los «handshake» con las nuevas versiones de TLS fallan. Es el usuario o administrador quien tiene que deshabilitar SSL 3.0, si el software proporciona la opción. De esta manera, el «hombre-en-el-medio» (MITM), primero tiene que realizar un ataque de «rollback» y luego aprovechar esta vulnerabilidad.
Lo cierto es que todavía algunos sitios web no usan TLS. Si tienes un sitio web, lo puedes verificar utilizando un analizador on line como: «SSLChecker.com» o «SSL Labs»
Protocolo de enlace TLS «TLS Handshake Protocol»
(apretón de manos)
Veamos como funciona el protocolo. Cuando un servidor y un cliente establecen una comunicación, por primera vez, negocian una versión del protocolo a utilizar, seleccionan los algoritmos criptográficos, se autentican mutuamente y utilizan cifrado de clave pública para generar secretos compartidos.
El protocolo TLS Handshake (apretón de manos) realiza los siguientes pasos:
- 1.- Intercambia mensajes de saludo para acordar algoritmos, intercambia aleatoriamente valores y comprueba la reanudación de la sesión.
- 2.- Intercambia los parámetros criptográficos necesarios para permitir a cliente y servidor acordar un secreto premaster.
- 3.- Intercambia certificados e información criptográfica para permitir a cliente y servidor su autenticación.
- 4.- Genera un secreto maestro a partir del secreto premaster e intercambia valores aleatorios.
- 5.- Proporciona parámetros de seguridad a la comunicación.
- 6.- Permite que el cliente y el servidor verifiquen que su par calculó los mismos parámetros de seguridad y que el «apretón de manos» ocurrió sin alteración por parte de un atacante.
Notificaciones de protocolo TLS y SSL
En la conexión, cualquiera de las partes que detecte un problema, activará un mensaje de alerta. Estos mensajes son:
Descripciones de alertas SSL
Close_Notify
Este mensaje notifica al destinatario que el remitente no enviará más mensajes en esta conexión. Notificación de cierre de la conexión.
Unexpected_message
Se recibió un mensaje inexperado. Es una alerta fatal que nunca debe darse en la comunicación entre implementaciones adecuadas.
Bad_record_mac
Esta alerta se produce si se recibe un registro con una MAC incorrecta. Esta alerta se devolverá si se envía una alerta porque un TLSCiphertext ha sido descifrado de una manera no válida: o no era un múltiplo par de la longitud del bloque, o sus valores de relleno no eran correctos.
Decryption_failed_RESERVED
Esta alerta, usada en algunas versiones anteriores de TLS permitió ciertos ataques contra el modo CBC.
Record_overflow
Se genera cuando se recibe un registro TLSCiphertext que tiene una longitud de más de 214 + 2048 bytes, o cuando un registro es descifrado a un registro TLSCompressed con más de 214 + 1024 bytes.
Decompression_failure
Se produce cuando la función de descompresión recibe una entrada incorrecta (por ejemplo, datos que se expanden a una longitud excesiva). Este mensaje siempre es fatal y nunca debe producirse en la comunicación entre implementaciones adecuadas.
Handshake_failure
El mensaje handshake_failure nos indica que el remitente no pudo negociar un conjunto aceptable de parámetros de seguridad dadas las opciones disponibles. Este es un error fatal.
No_certificate_RESERVED
Esta alerta no se utiliza en ninguna versión de TLS, solo se usó en SSLv3. No se debe producir en implementaciones compatibles.
Bad_certificate
Se produce cuando un certificado está dañado, contiene firmas que no se han verificado correctamente, etc.
Unsupported_certificate
El certificado es de un tipo no soportado o admitido.
Certificate_revoked
El firmante ha revocado un certificado.
Para más información podemos acceder a este enlace: Escáner SSL rápido y completo para encontrar configuraciones incorrectas que afectan a los servidores TLS/SSL: un análisis detallado
Descripciones de alertas de TLS
Certificate_expired
El certificado ha caducado o no es válido actualmente.
Certificate_unknown
Ha surgido algún otro problema (no especificado) al procesar el certificado, que lo ha vuelto inaceptable.
Illegal_parameter
Un campo en el «apretón de manos» estaba fuera de rango o era inconsistente con otros campos. Este mensaje siempre es fatal.
Unknown_ca
Se ha recibido una cadena de certificados válida o una cadena parcial, pero el certificado no se ha aceptado porque no se ha podido ubicar el certificado de CA o no se ha podido hacer coincidir con una CA de confianza conocida. Este mensaje siempre es fatal.
Access_denied
Se ha recibido un certificado válido, pero cuando se ha aplicado el control de acceso, el remitente ha decidido no continuar con la negociación. Este mensaje siempre es fatal.
Decode_error
No se ha podido decodificar un mensaje porque algún campo estaba fuera del rango especificado o la longitud del mensaje era incorrecta. Este mensaje siempre es fatal y nunca debe producirse en la comunicación entre implementaciones adecuadas (excepto cuando los mensajes se corrompen en la red).
Decrypt_error
Ha fallado una operación criptográfica de protocolo de enlace, incluida la imposibilidad de verificar correctamente una firma o validar un mensaje finalizado. Este mensaje siempre es fatal.
Export_restriction_RESERVED
Esta alerta se utilizó en algunas versiones anteriores de TLS. No debe producirse en implementaciones compatibles.
Protocol_version
La versión del protocolo que el cliente ha intentado negociar se reconoce pero no se admite. (Por ejemplo, las versiones de protocolo antiguas pueden evitarse por razones de seguridad). Este mensaje siempre es fatal.
Insufficient_security
Se devuelve en lugar de handshake_failure cuando una negociación ha fallado específicamente porque el servidor requiere cifrados más seguros que los admitidos por el cliente. Este mensaje siempre es fatal.
Internal_error
Un error interno no relacionado con el par o la corrección del protocolo (como un fallo en la asignación de memoria) hace que sea imposible continuar. Este mensaje siempre es fatal.
User_canceled
Este protocolo de enlace se cancela por algún motivo que no está relacionado con un error de protocolo. Si el usuario cancela una operación después de que se completa el protocolo de enlace, es más apropiado cerrar la conexión enviando un close_notify. Esta alerta debe ir seguida de un close_notify. Este mensaje es generalmente una advertencia.
No_renegotiation
Enviado por el cliente en respuesta a una solicitud de saludo o por el servidor en respuesta a un saludo del cliente después del protocolo de enlace inicial. Cualquiera de estos normalmente conduciría a una renegociación; cuando eso no sea apropiado, el destinatario debe responder con esta alerta. En ese momento, el solicitante original puede decidir si continúa con la conexión.
Un caso en el que esto sería apropiado es cuando un servidor ha generado un proceso para satisfacer una solicitud; el proceso puede recibir parámetros de seguridad (longitud de la clave, autenticación, etc.) al inicio, y puede ser difícil comunicar cambios a estos parámetros después de ese punto. Este mensaje es siempre una advertencia.
Unsupported_extension
Es enviado por los clientes que reciben un saludo de servidor que contiene una extensión que no pusieron en el saludo de cliente correspondiente. Este mensaje siempre es fatal.
Compatibilidad con TLS y SSL
Dado que existen varias versiones de TLS (1.0, 1.1, 1.2 y cualquier versión futura) y SSL (2.0 y 3.0), se necesitan medios para negociar la versión de protocolo específica que se utilizará.
El protocolo TLS proporciona un mecanismo integrado para la negociación de versiones para no interferir a otros componentes del protocolo con las complejidades de la selección de versiones.
Un cliente TLS 1.2 que desee negociar con servidores más antiguos enviará un ClientHello TLS 1.2 normal, que contiene {3,3} (TLS 1.2) en ClientHello.client_version.
Si el servidor no admite esta versión, responderá con un ServerHello que contiene un número de versión anterior. Si el cliente acepta utilizar esta versión, la negociación procederá según corresponda para el protocolo negociado.
En el caso de que un servidor TLS reciba un ClientHello que contiene un número de versión mayor que la versión más alta admitida por el servidor, responderá de acuerdo con la versión más alta admitida por el servidor.
Ejemplo
Por ejemplo, si el servidor admite TLS 1.0, 1.1 y 1.2, y la versión cliente es TLS 1.0, el servidor procederá con TLS 1.0 ServerHello. Si el servidor admite (o está dispuesto a usar) solo versiones superiores a la versión cliente es TLS 1.0, debe enviar un mensaje de alerta «protocol_version» y cerrar la conexión.
Siempre que un cliente ya sepa la versión de protocolo más alta conocida por un servidor (por ejemplo, al reanudar una sesión), debe iniciar la conexión en ese protocolo nativo.
Dentro de la complejidad del protocolo hay que advertir que hay más funciones. Si quieres más información sobre los atributos y funciones del protocolo TLS, puedes consultar RFC5246.
¿Tienes algún comentario que hacer sobre este artículo?, al pie del post tienes un formulario para hacerlo.
Si quieres contactar conmigo por cualquier otro asunto relacionado con el sitio, en la página de contacto, tienes un formulario más adecuado.
Y para suscribirte y recibir las novedades publicadas, tienes un enlace en el pie de la página o desde aquí mismo.
