El saludo TLS y los certificados

El saludo, o handshake, es la fase de negociación que precede a cualquier dato de aplicación. Tiene un objetivo único y del que cuelga todo lo demás: que cliente y servidor acaben compartiendo una misma clave simétrica de sesión sin que esa clave haya viajado nunca en claro por la red.

Por el camino se resuelven otras tres cosas: se acuerda qué versión de TLS se va a hablar, se elige el conjunto de algoritmos que se van a usar, y el cliente comprueba la identidad del servidor a través de su certificado. El flujo normal autentica solo al servidor: el cliente sigue siendo un anónimo para él.

Todo el saludo existe para generar una clave simétrica compartida. Si una pregunta ofrece esa respuesta entre las opciones, casi siempre es la buena.

Este es el punto donde más se falla, porque las opciones del examen suelen ser las mismas cinco tramas en distinto orden. El flujo clásico, el de TLS 1.2, es el siguiente.

1. 1ClientHello. Lo manda el cliente y abre la conversación. Lleva la versión de TLS más alta que admite, un número aleatorio, las extensiones y la lista de suites de cifrado que sabe manejar.
2. 2ServerHello. El servidor responde eligiendo: una sola suite de entre las ofrecidas, la versión que se va a usar, su propio número aleatorio y el identificador de sesión. A continuación envía su certificado y, si el método lo requiere, sus parámetros de intercambio de clave.
3. 3Intercambio del pre-master. El cliente valida el certificado y genera el secreto previo o pre-master. Si el método es RSA, se lo envía cifrado con la clave pública del servidor, que es el único que puede descifrarlo con su privada. Si el método es Diffie-Hellman, cada uno aporta su parte y el secreto no llega a viajar.
4. 4Generación del master secret. Las dos partes derivan, cada una por su lado, el mismo secreto maestro a partir del pre-master y de los dos números aleatorios. De ahí salen las claves simétricas de la sesión.
5. 5Change Cipher Spec y Finished. Cada extremo avisa de que a partir de ese momento cifra, y manda un mensaje Finished ya cifrado que resume todo lo negociado. Si los dos Finished se verifican, el canal está listo y empiezan los datos de aplicación.

Dos observaciones que resuelven preguntas. Los números aleatorios de los dos primeros mensajes no son adorno: entran en la derivación de la clave y son lo que impide que alguien reutilice un saludo grabado. Y la clave simétrica nunca se transmite: se transmite el material con el que las dos partes la calculan.

La suite de cifrado es el paquete de algoritmos que se acuerda en el saludo. El cliente propone una lista y el servidor elige uno, no al revés. Su nombre parece críptico pero se lee por partes y cada parte responde a una función.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  ECDHE      intercambio de clave: Diffie-Hellman de curva elíptica efímero
  RSA        autenticación: con qué se firma y se valida el certificado
  AES_128    cifrado simétrico del canal, con clave de 128 bits
  GCM        modo de operación, que además autentica lo cifrado
  SHA256     función de resumen para la integridad y la derivación

La letra E final de ECDHE significa efímero: las claves del intercambio se generan para esa sesión y se tiran al acabar. De ahí sale la confidencialidad hacia el futuro, que consiste en que si mañana alguien roba la clave privada del servidor no puede descifrar el tráfico que grabó ayer. Con el intercambio clásico basado en RSA eso sí era posible, y es la razón por la que se abandonó.

En TLS 1.3 los nombres se acortan, como TLS_AES_128_GCM_SHA256, porque el intercambio de clave y la autenticación se negocian aparte y solo quedan cifrados autenticados. Es una pista útil: si el nombre de la suite no menciona el intercambio de clave, es una suite de TLS 1.3.

El certificado es un documento electrónico que vincula una identidad con una clave pública, expedido y firmado por una autoridad de certificación o CA. La legislación española llama a esas entidades prestadores de servicios de confianza. El formato es X.509 en su versión 3, y puede emitirse para un servidor, es decir para un dominio, o para una persona física o jurídica.

En HTTPS lo que interesa es el certificado de servidor, y de sus campos hay tres que deciden si vale para el sitio que se está visitando: el sujeto, que es el dominio principal para el que se emitió; el SAN o nombre alternativo del sujeto, que es una extensión donde se listan los demás dominios que ampara el mismo certificado; y el periodo de validez. Es el SAN el que permite que un solo certificado sirva a llegandoalcorte.com, a www.llegandoalcorte.com y a app.llegandoalcorte.com.

El certificado comodín o wildcard es la variante que ampara un dominio y todos sus subdominios de un nivel con una sola entrada, escrita con un asterisco delante del punto. Cubre cualquier subdominio directo, pero no los subdominios de los subdominios.

En cuanto al fichero, en un servidor se manejan dos piezas: el certificado propiamente dicho, que es público, y la clave privada, que no sale de la máquina. Cuando hay que moverlas juntas se usa un contenedor PKCS#12, con extensión .pfx o .p12, protegido con contraseña, mientras que PKCS#7 solo transporta la parte pública y la cadena de certificación. Las codificaciones y extensiones completas están en el tema de administración electrónica del Bloque I.

El navegador no compara el dominio con el nombre común del sujeto, sino con la lista de SAN. Un certificado sin el dominio en su SAN da error aunque esté perfectamente emitido.

Recibir un certificado no es aceptarlo. El cliente ejecuta una comprobación en varios pasos, y basta que falle uno para que el navegador muestre la pantalla de aviso.

1. 1Que esté en vigor: la fecha actual tiene que caer dentro del periodo de validez.
2. 2Que se haya emitido para el dominio desde el que se ha descargado, comprobando el sujeto y los nombres alternativos.
3. 3Que la firma sea correcta, lo que verifica a la vez la integridad del documento y su autenticidad.
4. 4Que la autoridad que lo firmó esté en el almacén de confianza, siguiendo la cadena hasta un certificado raíz reconocido.
5. 5Que no esté revocado, consultando el estado por OCSP o descargando la lista de revocación CRL de la autoridad.

Los dos mecanismos de revocación no son equivalentes. OCSP es una consulta en línea sobre un certificado concreto, identificado por su número de serie, y da una respuesta inmediata. La CRL es la lista completa de certificados revocados por esa autoridad, que el cliente descarga y consulta localmente: pesa más y puede estar desactualizada.

El almacén de confianza no es único. En Windows, Chrome y Edge usan el del sistema operativo, mientras que Firefox mantiene el suyo propio, igual que hacen otros productos. Por eso un certificado emitido por una autoridad interna puede funcionar en un navegador y fallar en otro de la misma máquina si solo se instaló en uno de los dos almacenes.

En el saludo corriente solo se autentica el servidor. La autenticación mutua invierte también el otro sentido: el servidor pide al cliente que presente su propio certificado, y no continúa si no lo hace o si no lo reconoce.

Técnicamente el servidor añade una petición de certificado a su parte del saludo, junto con la lista de autoridades que acepta, y el cliente responde con su certificado y con una prueba de que posee la clave privada correspondiente. Desde el punto de vista del usuario, lo que ocurre es que el navegador le pide elegir uno de los certificados que tiene instalados.

Es lo habitual en las sedes electrónicas que admiten certificado o DNI electrónico y en la comunicación entre servidores de organismos, donde no puede haber un usuario tecleando una contraseña.

El protocolo ha ido corrigiéndose a golpe de ataque publicado, y varios de esos nombres aparecen en el examen como opciones. Conviene reconocer contra qué iba cada uno.

El hilo común es revelador: casi todos explotan compatibilidad hacia atrás, compresión o modos de cifrado antiguos. Por eso TLS 1.3 recortó drásticamente la lista de algoritmos admitidos, eliminó la compresión y la renegociación, y obliga a usar cifrado autenticado. Y por eso la recomendación práctica en administración de sistemas es la misma siempre: desactivar versiones antiguas en vez de confiar en que nadie las pida.

POODLE va con SSL 3.0 y BEAST con TLS 1.0. Si hay que asociar un ataque a una versión, son esas dos las que caen.