SSL/TLS — qué es, protocolos y principio de funcionamiento del cifrado

¿Qué es SSL/TLS?

SSL (Secure Sockets Layer) es un protocolo desarrollado por Netscape en 1995 para proteger el tráfico web. La primera versión, SSL 1.0, nunca se publicó; SSL 2.0 (1995) y SSL 3.0 (1996) se usaron hasta principios de los 2000, pero contenían vulnerabilidades críticas. SSL fue sucedido por TLS (Transport Layer Security) — una versión mejorada estandarizada por la IETF. TLS 1.0 (1999) se basó en SSL 3.0, mientras que las versiones posteriores TLS 1.1 (2006), TLS 1.2 (2008) y TLS 1.3 (2018) se alejaron gradualmente de la arquitectura original, añadiendo nuevos algoritmos de cifrado y corrigiendo vulnerabilidades. Hoy en día, SSL se considera obsoleto y todos los sistemas modernos usan TLS, aunque ambos protocolos suelen mencionarse juntos como SSL/TLS por inercia.

Historia del protocolo

La historia de SSL/TLS comenzó con la necesidad de transmisión segura de datos en los inicios de la web. En 1994, Netscape desarrolló SSL 1.0 para su navegador Navigator, pero el protocolo nunca se publicó debido a graves problemas de seguridad. SSL 2.0 se lanzó en 1995 y tuvo uso práctico, aunque contenía numerosas vulnerabilidades: falta de protección contra ataques Man-in-the-Middle, algoritmos de cifrado débiles y susceptibilidad a ataques de truncamiento. SSL 3.0 (1996) solucionó la mayoría de los problemas, pero para 2014 se descubrió la vulnerabilidad POODLE, tras lo cual la IETF declaró oficialmente obsoletas todas las versiones de SSL. TLS 1.0–1.3 mejoraron progresivamente la solidez criptográfica, el rendimiento y la privacidad, reduciendo TLS 1.3 el handshake de dos a una sola ida y vuelta, algo crítico para aplicaciones móviles con conexiones inestables.

Cómo funciona el Handshake SSL/TLS

Handshake es el proceso de establecimiento de una conexión segura entre un cliente y un servidor. Consta de varios pasos secuenciales durante los cuales las partes acuerdan la versión del protocolo, seleccionan algoritmos de cifrado, intercambian claves y se autentican mutuamente. En TLS 1.3, el handshake requiere solo un viaje de ida y vuelta (1-RTT), mientras que TLS 1.2 necesitaba dos (2-RTT).

El primer paso es que el cliente envíe un ClientHello — un mensaje que contiene una lista de versiones TLS compatibles, conjuntos de cifrado y un número aleatorio. El servidor responde con un ServerHello que incluye la versión y el cifrado elegidos, su certificado X.509 y una firma digital. El cliente verifica el certificado a través de la cadena de autoridades certificadoras (CA), genera una clave de sesión y la envía cifrada con la clave pública del servidor extraída del certificado. Tras la confirmación del servidor, comienza la transmisión segura de datos. Todo el handshake toma entre 1 y 3 milisegundos en dispositivos modernos, lo que lo hace imperceptible para el usuario.

Certificados X.509 y cadena de confianza

La base de la autenticación TLS es la Infraestructura de Clave Pública (PKI) construida sobre certificados en formato X.509. Cada certificado contiene: un nombre de dominio (Common Name o Subject Alternative Name), la clave pública del servidor, el nombre del emisor (Autoridad Certificadora), una fecha de vencimiento y la firma digital de la CA. El cliente verifica el certificado del servidor a lo largo de la cadena de confianza: desde el certificado del servidor hasta la CA raíz, cuyo certificado está integrado en el sistema operativo. En dispositivos Android, los certificados raíz se almacenan en el almacén de claves del sistema, actualizado mediante Google Play Services; en iOS, mediante las actualizaciones de iOS. Si algún eslabón de la cadena se rompe (certificado vencido, discrepancia de dominio, CA desconocida), el cliente termina la conexión. Para certificados autofirmados (usados en desarrollo), se requiere confianza explícita — en Android mediante Network Security Config, en iOS mediante NSExceptionDomains en Info.plist. El proceso de validación de la cadena de certificados también incluye la verificación del estado de revocación mediante CRL (Lista de Revocación de Certificados) u OCSP (Protocolo de Estado de Certificados en Línea), aunque en dispositivos móviles las solicitudes OCSP a menudo se omiten para acelerar la conexión — este es un compromiso entre seguridad y rendimiento que los arquitectos deben considerar.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()