Firmas digitales, certificados, y TLS

La lección anterior dejó una pregunta abierta: el cifrado asimétrico te permite enviarle un secreto a alguien de quien tienes la clave pública — pero ¿cómo sabes que esa clave pública en verdad le pertenece, y no a un atacante en medio? Las firmas digitales y los certificados responden eso, y juntos hacen posible TLS, el protocolo detrás de toda dirección https://.

Firmas digitales: prueba de origen, no de secreto

Una firma digital ejecuta el cifrado asimétrico al revés. En lugar de cifrar un mensaje con la clave pública de alguien para que solo esa persona pueda leerlo, quien envía firma un mensaje con su propia clave privada, y cualquiera puede verificarlo usando la clave pública de quien lo envió. Si la verificación funciona, dos cosas son ciertas: el mensaje vino de quien tiene esa clave privada, y no se alteró después — la misma propiedad de resistencia a colisiones de la discusión sobre el hash de la lección anterior es lo que hace detectable cualquier manipulación. Una firma prueba autenticidad e integridad; por sí sola, no mantiene el mensaje en secreto.

Certificados: una firma que avala una clave pública

Un certificado digital resuelve el problema de “de quién es realmente esta clave pública”. Como explica el Centro de Aprendizaje de Cloudflare, un certificado SSL/TLS es “un archivo de datos alojado en el servidor de origen de un sitio web” que contiene el nombre de dominio, la clave pública, una fecha de caducidad y — de forma crucial — “la firma digital de la autoridad certificadora.” Una autoridad certificadora (CA) es un tercero de confianza que revisa que un sitio web controla el dominio para el que solicita un certificado, y luego firma ese certificado con su propia clave privada. Tu navegador viene con una lista integrada de CA en las que confía, así que cuando recibe un certificado firmado por una de ellas, puede confiar en la clave pública que contiene sin haber conocido nunca a quien opera el sitio web. Un certificado autofirmado — uno que un sitio firma él mismo en vez de obtenerlo de una CA — no tiene ese aval externo, por eso los navegadores lo tratan como no confiable por defecto.

TLS: poniendo a trabajar a ambos

El RFC 8446, la especificación de TLS 1.3, describe un saludo (handshake) en fases: el intercambio de claves, en el que ambas partes establecen material secreto compartido; y luego la autenticación, donde, en palabras del propio RFC, “el lado del servidor del canal siempre se autentica; el lado del cliente se autentica de forma opcional” — normalmente solo el sitio web demuestra su identidad, no quien lo visita. El servidor demuestra quién es usando su certificado y una firma que solo él podría producir con su clave privada. Una vez que ambas partes confían en la conexión, derivan claves simétricas rápidas (el AES de la lección anterior, típicamente) para los datos reales. El RFC 8446 declara con claridad qué obtienes con esto: confidencialidad e integridad para los datos intercambiados, y autenticación del servidor. También declara, con la misma claridad, un límite: “TLS no oculta la longitud de los datos que transmite”, y metadatos como a qué servidor te conectaste y cuándo siguen siendo visibles para cualquiera que esté en posición de observar la conexión.

Qué significa y qué no significa el ícono del candado

Un sitio de phishing construido sobre un dominio parecido puede tener un certificado perfectamente válido: TLS autentica el dominio, no la intención de quien lo registró. Por eso la lección anterior sobre cómo se desarrollan los ataques trata una página de inicio de sesión falsa, candado incluido, como una amenaza real, no como una contradicción.