HTTPS y TLS

SSL, Secure Sockets Layer, lo creó Netscape a mediados de los años noventa. Cuando su desarrollo pasó al IETF, el protocolo se renombró TLS, Transport Layer Security. No son dos protocolos rivales: TLS es la continuación de SSL con otro nombre, aunque en el lenguaje corriente y en los productos se sigan escribiendo juntos.

Solo hay dos versiones admisibles hoy: TLS 1.2 y TLS 1.3. Cualquier opción de examen que dé por buena SSL 3.0 o TLS 1.0 está mal.

La criptografía se aplica a un activo de información para asegurar tres propiedades, y TLS las cubre las tres a la vez sobre el canal de comunicación.

Conviene saber también qué queda fuera. TLS no aporta disponibilidad: un servidor con el mejor certificado del mundo se cae igual. Y protege el canal, no el contenido almacenado: lo que llega cifrado al servidor se guarda allí en claro salvo que alguien lo cifre aparte.

TLS no es exclusivo de la web: es una capa genérica que se intercala entre el transporte y la aplicación, de modo que cualquier protocolo de aplicación puede apoyarse en él sin cambiar. HTTPS es sencillamente HTTP hablado dentro de un canal TLS, en el puerto 443 en vez del 80.

Hay dos formas de llegar a ese canal cifrado. Una es el puerto dedicado, como el 443: la conexión nace cifrada. La otra es STARTTLS, en la que se conecta al puerto de siempre en claro y se pide elevar la conexión a cifrada con una orden del propio protocolo, cosa habitual en correo. Cómo se aplica esto a cada servicio de correo corresponde a su tema de este mismo bloque.

Las dos familias de cifrado tienen defectos complementarios. El simétrico usa una sola clave para cifrar y descifrar, es muy rápido y sirve para volúmenes grandes, pero exige que las dos partes compartan ya esa clave, y hacérsela llegar a un desconocido por una red pública es justamente el problema. El asimétrico usa un par de claves, de forma que lo que se cifra con una solo se deshace con la otra, y no necesita compartir ningún secreto previo, pero es lento y no sirve para cifrar un canal entero.

TLS combina las dos y por eso se le llama sistema híbrido, igual que PGP. Se usa el cifrado asimétrico una sola vez, al principio, para acordar una clave simétrica, que es pequeña y por tanto barata de proteger así. A partir de ese momento todo el tráfico va con esa clave simétrica, que es lo único que aguanta el volumen de una conexión real.

Cómo funcionan por dentro el resumen, el cifrado asimétrico y la firma electrónica se estudia en el tema de administración electrónica del Bloque I, donde también está la diferencia entre MIC y HMAC y la tabla de codificaciones del certificado. Aquí basta con saber qué papel juega cada pieza dentro de la conexión. En la práctica nada de esto se programa a mano: se usan las bibliotecas del sistema, con OpenSSL como herramienta de referencia, o bibliotecas de terceros como BouncyCastle cuando la plataforma no trae lo necesario.

Asimétrico para acordar la clave, simétrico para cifrar el canal. Invertir esos dos papeles es el error más repetido del tema.

TLS se coloca entre el transporte y la aplicación: por debajo tiene TCP e IP, y por encima el protocolo que quiera protegerse, HTTP en el caso de HTTPS. Internamente se divide en dos niveles.

El nivel de abajo es el protocolo de registro, o TLS Record Protocol. Es el que hace el trabajo material sobre cada bloque de datos: lo trocea, lo cifra y le añade el código de autenticación que garantiza la integridad. La compresión que también contemplaba se retiró por los ataques que aprovechaban precisamente comprimir antes de cifrar.

Por encima corren cuatro subprotocolos, y cada registro lleva un identificador que dice cuál de ellos transporta. Esos números caen literales.