Tema 18
Los algoritmos criptográficos no se usan aislados en la práctica. Se integran dentro de protocolos que combinan autenticación, intercambio de claves, cifrado, verificación de integridad y reglas operativas para proteger comunicaciones reales entre navegadores, servidores, aplicaciones, redes y usuarios.
Hasta aquí estudiamos algoritmos y construcciones como AES, RSA, Diffie-Hellman, ECC, hashes, HMAC, firmas digitales y certificados. Sin embargo, los sistemas reales rara vez usan una sola pieza por separado. Lo habitual es que combinen varios mecanismos dentro de un protocolo completo.
Ese protocolo debe definir cómo se autentican las partes, cómo acuerdan claves, cómo protegen los mensajes durante la sesión, qué errores invalidan la conexión y cómo responder ante intentos de manipulación o intercepción.
Un algoritmo resuelve una función concreta, como cifrar un bloque, generar una firma o producir un hash. Un protocolo, en cambio, define una conversación segura entre partes que necesitan coordinarse paso a paso.
Sin ese nivel adicional, no bastaría con decir "usamos AES" o "usamos RSA". Haría falta saber qué clave se usa, cómo se obtuvo, quién la validó, cómo se detecta una modificación y qué ocurre si un atacante intenta intervenir el canal.
Un protocolo seguro normalmente necesita cubrir varias funciones al mismo tiempo:
Eso explica por qué los protocolos aplicados son más complejos que un simple cifrado o una firma tomada aisladamente.
| Componente | Función | Ejemplos |
|---|---|---|
| Intercambio de claves | Permitir acordar secretos sobre canal inseguro | Diffie-Hellman, ECDHE |
| Autenticación | Verificar identidad o pertenencia de una clave | Certificados, firmas, claves conocidas |
| Cifrado simétrico | Proteger confidencialidad del tráfico de sesión | AES-GCM, ChaCha20 |
| Integridad/autenticidad | Detectar modificaciones y mensajes falsos | HMAC, modos AEAD |
| Derivación de claves | Obtener claves específicas para cada uso | KDF, HKDF |
TLS, Transport Layer Security, es uno de los protocolos criptográficos más importantes de la informática moderna. Su función principal es proteger comunicaciones entre aplicaciones a través de redes inseguras, proporcionando autenticación, confidencialidad e integridad.
Se usa como base en muchísimos servicios, pero su caso más conocido es HTTPS. También puede proteger correo, APIs, servicios internos y múltiples comunicaciones cliente-servidor.
Sin TLS, una conexión a través de internet podría ser observada o alterada por terceros. Un atacante podría leer datos sensibles, modificar mensajes, inyectar contenido falso o hacerse pasar por un servidor legítimo.
TLS intenta evitar ese escenario combinando certificados, validación de identidad, establecimiento seguro de claves y cifrado de la sesión una vez que la negociación inicial finaliza correctamente.
La fase inicial de TLS se conoce como handshake. Allí cliente y servidor negocian cómo se protegerá la sesión.
La idea central es que la criptografía asimétrica suele concentrarse en la autenticación y el establecimiento inicial, mientras que el tráfico posterior se protege con criptografía simétrica, que es mucho más eficiente.
HTTPS no es más que HTTP funcionando sobre TLS. Es decir, el protocolo web habitual se encapsula dentro de una sesión protegida criptográficamente.
Eso permite que cuando navegas en un sitio confiable, no solo se oculte el contenido intercambiado, sino que además puedas verificar que estás hablando realmente con el dominio correcto, siempre que la validación del certificado sea satisfactoria.
Sin embargo, HTTPS no vuelve automáticamente seguro a un sitio desde todos los puntos de vista. Un sitio puede usar HTTPS y seguir teniendo lógica vulnerable, mala gestión de sesiones o contenido malicioso propio.
En implementaciones modernas, se busca que las sesiones ofrezcan forward secrecy, o confidencialidad hacia adelante. Esto significa que comprometer la clave privada del servidor en el futuro no debería permitir descifrar sesiones pasadas capturadas anteriormente.
Ese objetivo se logra usando intercambios efímeros de claves, como ECDHE, en lugar de depender directamente de la clave privada del certificado para proteger todo el tráfico de la sesión.
Una VPN, Virtual Private Network, crea un canal protegido entre equipos o redes a través de infraestructura no confiable, como internet. Desde la perspectiva criptográfica, su objetivo es encapsular tráfico dentro de un túnel autenticado y cifrado.
Esto permite proteger comunicaciones entre sedes, trabajadores remotos y recursos internos, o incluso entre dos sistemas que necesitan intercambiar tráfico como si estuvieran dentro de una red más controlada.
Una VPN puede proteger la confidencialidad e integridad del tráfico entre sus extremos y autenticar a los participantes del túnel. También reduce la exposición del tráfico frente a observadores intermedios.
Pero no resuelve por sí sola todos los problemas de seguridad. Si un equipo extremo está comprometido, si se roba una credencial o si la aplicación dentro del túnel es insegura, la VPN no corrige esos fallos.
SSH, Secure Shell, es un protocolo usado principalmente para acceso remoto seguro, administración de sistemas, transferencia protegida de archivos y tunelización de conexiones. Reemplazó a herramientas más antiguas e inseguras que transmitían credenciales en texto claro.
SSH combina autenticación, establecimiento de claves y cifrado de la sesión para permitir que un cliente administre un servidor remoto sin exponer fácilmente el contenido del canal.
SSH puede autenticar al servidor y luego autenticar al usuario por distintos mecanismos, como contraseña o claves públicas. En entornos maduros suele preferirse el uso de pares de claves en lugar de depender solo de contraseñas.
Un aspecto muy importante de SSH es la verificación de la identidad del servidor mediante su huella o clave host. Si esa identidad cambia inesperadamente, puede ser señal de reconfiguración legítima o de un posible ataque de intermediario.
La mensajería segura moderna busca que el contenido solo sea legible por los extremos legítimos de la conversación. Esto suele llamarse cifrado de extremo a extremo.
En ese modelo, los servidores pueden participar en entrega, sincronización o gestión de identidad, pero idealmente no deberían poder leer el contenido de los mensajes si el protocolo está bien diseñado y aplicado.
La mensajería no necesita solo cifrar un canal en un momento fijo. También debe manejar usuarios offline, múltiples dispositivos, rotación de claves, autenticación de interlocutores y, en algunos casos, propiedades adicionales como secreto hacia adelante y recuperación posterior frente a compromiso.
Eso hace que los protocolos de mensajería segura sean particularmente complejos y combinen varias capas criptográficas y operativas.
| Tecnología | Uso típico | Qué protege | Modelo general |
|---|---|---|---|
| TLS | Comunicaciones cliente-servidor | Canal entre aplicaciones | Autenticación, handshake y cifrado de sesión |
| HTTPS | Navegación web y APIs | HTTP sobre canal seguro | TLS aplicado a tráfico web |
| VPN | Conectar redes o usuarios remotos | Túnel de tráfico entre extremos | Encapsulación autenticada y cifrada |
| SSH | Administración remota | Sesión de control y transferencia | Canal seguro con autenticación del host y del usuario |
| Mensajería segura | Chats y comunicación personal | Contenido entre usuarios finales | Cifrado de extremo a extremo |
Aunque sus usos sean distintos, TLS, HTTPS, VPN, SSH y los sistemas de mensajería segura comparten una misma lógica de fondo:
Muchas veces los problemas no están en que AES, RSA o SHA estén rotos, sino en errores de integración, configuración o gestión.
Este tema integra prácticamente todo lo visto hasta ahora:
Por eso es un tema de integración: muestra cómo las piezas criptográficas cobran sentido dentro de sistemas que realmente usamos todos los días.
La criptografía aplicada no consiste en memorizar nombres de algoritmos, sino en comprender cómo se combinan para sostener comunicaciones seguras en escenarios concretos. TLS, HTTPS, VPN, SSH y mensajería segura muestran que la seguridad real es una arquitectura de piezas coordinadas, no una única fórmula mágica.
En el próximo tema profundizaremos en otro aspecto crítico de la práctica: la gestión de claves, su almacenamiento, rotación y protección dentro de sistemas reales.