¿Qué son los protocolos de cifrado y cómo funcionan?

Publicado: mayo de 2021. Actualizado: agosto de 2026. Revisado por el equipo de asesoría de PKI de Encryption Consulting.

El cifrado transforma los datos legibles en texto cifrado, pero por sí solo no les indica a dos computadoras cómo acordar una clave, verificar su identidad o estructurar los bytes cifrados en la red. Esa es la función de un protocolo de cifrado. Cada conexión segura que utilizamos (una sesión de navegador, un túnel VPN, un inicio de sesión SSH, un correo electrónico firmado) se basa en un protocolo con nombre que especifica exactamente cómo se utiliza el cifrado, no solo qué algoritmo realiza los cálculos. Elegir el protocolo incorrecto, o una versión obsoleta del correcto, es uno de los errores más comunes que detectamos en nuestros servicios de consultoría de cifrado durante las revisiones de arquitectura.

¿Cuál es la diferencia entre un protocolo de cifrado y un algoritmo de cifrado?

Un algoritmo de cifrado es un procedimiento matemático específico, como AES , RSA o ECDSA, que transforma texto plano en texto cifrado, genera una firma digital o produce un hash. Un algoritmo, por sí solo, no tiene criterio sobre cómo dos partes se encuentran, acuerdan qué algoritmo usar, intercambian claves de forma segura o detectan un mensaje manipulado.

Un protocolo es el conjunto de reglas que integra uno o más algoritmos en un sistema de seguridad funcional para un propósito específico. TLS 1.3, definido en la RFC 8446 , especifica los mensajes exactos de establecimiento de conexión que intercambian un cliente y un servidor, qué conjuntos de cifrado están permitidos, cómo se deriva la clave de sesión y cómo se autentica la conexión con un certificado. Si se reemplaza AES por ChaCha20-Poly1305 dentro del mismo establecimiento de conexión TLS 1.3, el protocolo no cambia, solo el algoritmo que se negocia. Esta distinción es importante desde el punto de vista operativo: una versión de protocolo puede quedar obsoleta incluso cuando todos sus algoritmos se consideran robustos, porque la lógica de negociación en sí misma tiene una vulnerabilidad (esto es precisamente lo que sucedió con SSLv3, que se analiza más adelante).

La infraestructura de clave pública (PKI) funciona junto con la mayoría de los protocolos asimétricos . Una PKI emite los certificados digitales que TLS, IPsec y S/MIME utilizan para vincular una clave pública a una identidad, de modo que el protocolo de enlace tenga algo confiable que verificar con una cadena de confianza que se remonta a una autoridad de certificación . Sin esa capa de identidad, un protocolo aún puede cifrar un canal, pero no puede saber quién está al otro lado.

¿Cuáles son los principales protocolos de cifrado y cómo funciona cada uno?

TLS/SSL: Protección de las conexiones cliente-servidor

Transport Layer Security (TLS), sucesor del antiguo Secure Sockets Layer (SSL), es el protocolo que se muestra en la barra de direcciones de su navegador, donde aparece el icono del candado y "https". TLS no cifra nada directamente; negocia qué algoritmos realizarán esa tarea. El protocolo de enlace TLS selecciona la versión del protocolo, autentica el servidor (y opcionalmente el cliente) mediante un certificado X.509, acuerda un conjunto de cifrado y genera una clave de sesión compartida. TLS 1.3, estandarizado en el RFC 8446 , redujo el protocolo de enlace a un solo viaje de ida y vuelta, eliminó la compatibilidad con el intercambio de claves RSA estático y los cifrados en modo CBC, y restringe la negociación a una lista reducida de conjuntos de cifrado AEAD. Consulte nuestra introducción a los conjuntos de cifrado para obtener información precisa sobre las combinaciones de algoritmos que permiten TLS 1.2 y 1.3 y cómo se negocian durante el protocolo de enlace.

IPsec: Cifrado del tráfico de red y túneles VPN

El protocolo de seguridad de Internet (IPsec) protege el tráfico en la capa de red en lugar de la capa de aplicación, lo que lo hace independiente del protocolo: todo lo que se transmite por IP se protege sin que la aplicación necesite saber que se está aplicando cifrado. IPsec tiene dos subprotocolos principales: AH (Authentication Header) para la integridad y ESP (Encapsulating Security Payload) para la confidencialidad y la integridad, y dos modos: modo de transporte, que cifra solo la carga útil del paquete, y modo túnel, que cifra todo el paquete original, incluyendo su encabezado. El modo túnel es el que utilizan la mayoría de las VPN de sitio a sitio y de acceso remoto. Antes de que se pueda aplicar cualquier cifrado, ambos extremos necesitan una clave compartida, y aquí es donde entra en juego el protocolo de intercambio de claves de Internet (IKE). IKEv2, definido en la RFC 7296 , negocia y actualiza esas claves y es el estándar actual; su predecesor, IKEv1, fue declarado obsoleto formalmente por la RFC 9395 en 2023 y debería eliminarse de cualquier configuración que aún lo utilice.

SSH: Asegurando la administración remota

Secure Shell (SSH) protege los inicios de sesión remotos interactivos, las transferencias de archivos y el reenvío de puertos. Su arquitectura, descrita en el RFC 4251 , se divide en tres capas, cada una con su propio RFC: la capa de transporte ( RFC 4253 ) negocia los algoritmos y establece un canal cifrado con verificación de integridad mediante un intercambio de claves Diffie-Hellman; la capa de autenticación de usuario ( RFC 4252 ) verifica la identidad del cliente, normalmente con una clave pública en lugar de una contraseña; y la capa de conexión ( RFC 4254 ) multiplexa el transporte cifrado en múltiples canales lógicos para shells, transferencias de archivos y puertos reenviados. Dado que el acceso SSH suele autenticarse con pares de claves de larga duración en lugar de certificados que caducan, un conjunto de claves SSH no gestionado es un hallazgo común en las auditorías; esto es precisamente lo que las herramientas de gestión del ciclo de vida de las claves SSH están diseñadas para solucionar.

PGP y S/MIME: Cifrado y firma de correo electrónico

Tanto OpenPGP como S/MIME cifran y firman digitalmente el correo electrónico, pero generan confianza de forma diferente. OpenPGP, especificado actualmente en la RFC 9580 (que reemplaza a la anterior RFC 4880), se basa en una red de confianza descentralizada donde los usuarios firman directamente las claves de los demás. S/MIME, especificado en la RFC 8551 , se basa en certificados X.509 emitidos por una CA, lo que lo convierte en la opción más natural para organizaciones que ya utilizan una PKI para otros fines. Ambos protocolos proporcionan confidencialidad y no repudio para el cuerpo del mensaje; ninguno protege las cabeceras, los metadatos de enrutamiento ni los mensajes una vez descifrados y en la bandeja de entrada.

WireGuard: Un protocolo VPN moderno y ligero

WireGuard es un protocolo VPN más reciente, basado en un conjunto criptográfico fijo y mínimo (Curve25519 para el intercambio de claves, ChaCha20-Poly1305 para el cifrado y BLAKE2s para el hash), en lugar de la lista de cifrados negociables de IPsec. Su protocolo de enlace se basa en el Noise Protocol Framework , y su diseño completo está documentado en su propio documento técnico, en lugar de en un RFC de la IETF. Al no negociar algoritmos, no existe la posibilidad de que se produzcan errores de configuración con cifrados heredados, lo que explica en gran medida por qué las configuraciones de WireGuard suelen ser más pequeñas y fáciles de auditar que una configuración IPsec equivalente. La desventaja es una menor flexibilidad: si algún componente del conjunto fijo de WireGuard falla, el protocolo requiere una nueva versión en lugar de un cambio de configuración.

Kerberos: Autenticación de red

Kerberos es un protocolo de autenticación basado en tickets, conocido principalmente por ser la base de los inicios de sesión en Windows Active Directory. Un Centro de Distribución de Claves central autentica a un usuario una sola vez y emite un ticket con validez limitada, que el usuario presenta a cada servicio en lugar de tener que autenticarse nuevamente en cada uno. Kerberos está diseñado para redes internas de confianza y Active Directory; no sustituye a TLS, IPsec ni SSH en el tráfico que atraviesa una red no confiable.

¿Qué protocolo de cifrado debería utilizar para cada caso de uso?

El protocolo adecuado se deriva directamente de lo que se está protegiendo y de quiénes son los destinatarios, no de cuál es el "más fuerte" en abstracto.

Caso de uso	Protocolo	Versión recomendada actual	Estado
Tráfico web y de API (cliente-servidor)	TLS / SSL	TLS 1.3 (RFC 8446); TLS 1.2 mínimo aceptable	TLS 1.0/1.1 y SSLv3 están obsoletos.
VPN de sitio a sitio, túneles de capa de red	IPsec	IKEv2 (RFC 7296)	IKEv1 está obsoleto (RFC 9395)
Administración remota interactiva, transferencia de archivos	SSH	SSH-2 (RFC 4251-4254)	SSH-1 está obsoleto, no lo utilice.
Confidencialidad del correo electrónico, PKI gestionada por la organización	S / MIME	S/MIME 4.0 (RFC 8551)	Current
Confidencialidad del correo electrónico, confianza descentralizada	OpenPGP	RFC 9580	Actual; RFC 4880 obsoleto
VPN ligera para acceso remoto/sitio	WireGuard	Conjunto de cifrado fijo según el documento técnico de WireGuard	Current
Autenticación interna de AD	Kerberos	Kerberos 5 (RFC 4120)	Válido únicamente para redes internas de confianza.

De esta tabla se derivan algunas reglas prácticas. Los puntos finales web y API de acceso público deben terminar con TLS 1.3 siempre que el soporte del cliente lo permita, y no recurrir a un protocolo inferior a TLS 1.2. Las conexiones sitio a sitio entre centros de datos o VPC en la nube suelen ser más adecuadas para IPsec/IKEv2, ya que funciona por debajo de la capa de aplicación y se integra con la infraestructura de enrutadores y cortafuegos existente. Los usuarios individuales que se conectan a recursos internos desde redes no administradas suelen beneficiarse más de WireGuard o un cliente IPsec, que del túnel SSH directo, que está pensado para el acceso administrativo y no para redes de propósito general. La elección entre S/MIME y OpenPGP para el correo electrónico generalmente depende de si la organización ya opera una PKI: si es así, S/MIME reutiliza esa inversión; si la audiencia es externa y descentralizada, la red de confianza de OpenPGP puede ser la opción más práctica.

Modelo de amenazas y protocolos obsoletos que se deben evitar.

Todos los protocolos mencionados anteriormente presuponen la existencia de un atacante activo en la red, capaz de leer, modificar, inyectar y reproducir paquetes, y no solo de un espía pasivo. Esta suposición explica por qué la negociación de versiones es un aspecto crítico para la seguridad de estos protocolos: un atacante que pueda forzar una degradación a una versión más débil a menudo puede eludir el cifrado sin romper ningún algoritmo. Varias versiones de protocolos han sido declaradas obsoletas precisamente por este motivo y deberían deshabilitarse en todos los lugares donde aún estén configuradas.

• SSLv3 fue descontinuado por RFC 7568 después de que el ataque del oráculo de relleno POODLE demostrara que podía ser degradado y roto de manera confiable.
• TLS 1.0 y TLS 1.1 fueron desaprobados por RFC 8996 En 2021, debido a la dependencia de construcciones MD5/SHA-1 débiles y vulnerabilidades en el modo CBC sin una configuración segura viable.
• IKEv1 fue descontinuado por RFC 9395 en 2023 junto con un conjunto de algoritmos IPsec obsoletos.
• Protocolo SSH versión 1 Se conocen debilidades criptográficas y ha sido reemplazado por SSH-2 hace casi dos décadas; cualquier servidor que aún lo ofrezca es un hallazgo crítico en cualquier evaluación.

La guía del NIST para las implementaciones federales de TLS, SP 800-52 Revisión 2 , exige TLS 1.2 como mínimo y orienta a las agencias hacia TLS 1.3, reflejando la misma lógica: una versión de protocolo sigue siendo aceptable solo mientras no exista una degradación práctica o un ataque criptográfico contra ella.

Cómo reforzar la configuración de su protocolo de cifrado

1. Inventariar todos los protocolos y versiones en uso. Analice los puntos finales externos e internos para determinar las versiones de TLS, IKE y SSH que aceptan actualmente, no solo la versión que usted tiene previsto utilizar.
2. Desactive las versiones obsoletas a nivel de configuración. Elimine SSLv3, TLS 1.0/1.1, IKEv1 y SSH-1 de las configuraciones del servidor y del balanceador de carga; no confíe en que los clientes simplemente "no elijan" una opción débil durante la negociación.
3. Establezca una versión mínima aceptada, no solo una preferida. Configure TLS 1.2 como estándar mínimo y TLS 1.3 como estándar preferido, y confirme que el servidor rechaza realmente los intercambios de claves anteriores en lugar de simplemente catalogarlos como de baja prioridad.
4. Restringir la negociación de conjuntos de cifrado a los conjuntos AEAD. Elimine los conjuntos CBC-mode y RC4 de cualquier configuración TLS 1.2 que aún deba admitirlo; consulte la guía de conjuntos de cifrado para una lista de recomendaciones basada en escenarios.
5. Verifique el certificado y las medidas de higiene clave para cada protocolo. Confirme que los certificados TLS y S/MIME estén encadenados a una raíz de confianza y que no estén próximos a caducar, y que los archivos de claves autorizadas de SSH no contengan claves huérfanas o no gestionadas.
6. Vuelva a realizar la prueba después de cada cambio. Vuelva a escanear los mismos puntos finales para confirmar que la versión obsoleta realmente ha desaparecido del protocolo de enlace negociado por el servidor, y no solo se ha eliminado de un archivo de configuración que nunca se ha vuelto a cargar.

Compromisos entre rendimiento e interoperabilidad

La elección del protocolo rara vez se trata solo de margen de seguridad; también tiene un costo operativo real. El protocolo de enlace de ida y vuelta único de TLS 1.3 reduce la latencia de conexión en comparación con TLS 1.2, lo cual es importante a la escala de millones de conexiones diarias, pero los clientes más antiguos, algunos balanceadores de carga heredados y ciertos dispositivos intermedios de inspección profunda de paquetes todavía solo admiten TLS 1.2, lo que obliga a muchos servicios de cara al público a mantener disponible una ruta de respaldo TLS 1.2. La lista de cifrado negociable de IPsec le brinda una amplia interoperabilidad entre hardware de diferentes proveedores, a costa de una mayor superficie de ataque debido a las opciones de algoritmos heredados que deben eliminarse activamente. El conjunto de cifrado fijo de WireGuard elimina esa sobrecarga de negociación y mantiene baja la sobrecarga de paquetes, razón por la cual funciona bien en redes móviles y con recursos limitados, pero no puede recurrir a algoritmos más antiguos si un cliente no puede admitir el conjunto actual, y carece del ecosistema de proveedores y dispositivos que IPsec ha construido durante dos décadas. La multiplexación por canal de SSH es eficiente para sesiones interactivas, pero no fue diseñada para el cifrado masivo de la capa de red, por lo que no debería utilizarse como sustituto general de una VPN, aunque técnicamente sea posible una "VPN de bajo coste" mediante tunelización SSH.

Dependencias de gestión de claves de cada protocolo

Ningún protocolo de esta lista es seguro sin un programa de gestión de claves que funcione correctamente, y cada uno depende de un tipo diferente de infraestructura de claves:

• TLS / SSL depende de una PKI que emite, renueva y revoca certificados X.509 antes de que caduquen o se vean comprometidos, funciona nuestro Administrador de CertSecure La plataforma automatiza la gestión de grandes conjuntos de certificados.
• IPsec Depende de claves precompartidas o de autenticación basada en certificados para su fase IKE, y de un cambio de clave periódico para limitar la cantidad de tráfico protegido por una sola clave.
• SSH Depende de la gestión de miles de pares de claves potencialmente duraderas y sin fecha de caducidad en servidores y cuentas de servicio, un conjunto de datos que crece sin gestión con mucha más facilidad que el acceso basado en certificados.
• PGP Depende de que cada usuario gestione correctamente sus propias claves privadas y de una red de confianza sin autoridad central de revocación.
• S / MIME Depende de la misma infraestructura PKI y CA que TLS, extendida a los buzones de correo individuales.
• WireGuard Depende de la distribución y rotación de pares de claves Curve25519 por nodo, normalmente fuera de cualquier PKI centralizada.

En la práctica, el protocolo rara vez es el origen del fallo de un programa de cifrado; la capa de gestión de claves subyacente sí lo es. Una organización puede utilizar TLS 1.3 en todas partes y aun así estar expuesta si la renovación de certificados es manual y alguno caduca sin que nadie se dé cuenta, o si las claves SSH de un empleado que se marchó hace dos años siguen autorizadas en los servidores de producción.

Ejemplos de implementación

Un sitio de comercio electrónico público finaliza TLS 1.3 en su balanceador de carga, respaldado por certificados emitidos y renovados automáticamente a través de una PKI administrada, manteniendo TLS 1.2 disponible solo para la pequeña proporción de clientes heredados que no pueden negociar 1.3. Dos centros de datos conectados por un enlace permanente ejecutan IPsec en modo túnel con IKEv2, por lo que cada paquete entre ellos se cifra en la capa de red independientemente de la aplicación que lo haya generado. Un equipo de plataforma proporciona a los ingenieros acceso SSH a los hosts de producción a través de un host bastión que emite certificados de corta duración en lugar de claves estáticas, solucionando el problema más común de propagación de claves SSH. Un equipo legal cifra y firma la correspondencia con los clientes con certificados S/MIME emitidos desde la propia PKI de la firma, de modo que los destinatarios pueden verificar al remitente sin intercambiar claves manualmente. Un equipo de trabajo remoto se conecta a la red corporativa a través de WireGuard en lugar de un cliente IPsec más pesado, sacrificando la agilidad de cifrado configurable por una conexión más pequeña, rápida y fácil de auditar.

Limitaciones

Ningún protocolo de cifrado protege los datos una vez descifrados en un punto final; TLS protege los datos en tránsito, no el texto plano que permanece en la memoria del servidor o en un registro de la aplicación posteriormente. La robustez del protocolo también depende de la configuración: una configuración deficiente de TLS 1.3 (por ejemplo, con una cadena de certificados débil o inválida) ofrece menos protección real que una implementación de TLS 1.2 correctamente configurada. Ninguno de estos protocolos aborda la vulnerabilidad de claves a posteriori; si se roba una clave privada, todas las sesiones autenticadas por ella se consideran sospechosas retroactivamente hasta que dicha clave se revoque y se reemplace. Por último, la compatibilidad con el protocolo no es universal: el hardware antiguo, algunos dispositivos IoT y ciertos entornos regulados pueden no poder migrar inmediatamente a la versión recomendada actual, lo que hace necesario, en lugar de opcional, un plan documentado de control compensatorio y migración.

¿Qué recomendaría Encryption Consulting?

La mayoría de las organizaciones con las que trabajamos no tienen tanto un problema de protocolo como de visibilidad y ciclo de vida: TLS 1.3 es la opción correcta en casi todas partes, pero los certificados que lo respaldan caducan sin que nadie se dé cuenta, las claves SSH se acumulan sin propietario y las configuraciones de IPsec se desvían con el tiempo de su línea base de seguridad original. Nuestro equipo de Asesoría en Cifrado comienza cada revisión de protocolo con un análisis exhaustivo de su entorno y luego asigna los hallazgos a un plan de remediación en lugar de una lista de verificación genérica de mejores prácticas. Para los conjuntos de certificados que respaldan TLS y S/MIME, CertSecure Manager automatiza la emisión, renovación y revocación, de modo que el seguimiento de los certificados que caducan deja de ser una tarea manual. Para la propia PKI, nuestro equipo de Servicios de PKI puede diseñar o reconstruir la jerarquía de CA y la documentación CP/CPS de la que depende cada protocolo basado en certificados que se menciona en esta página. Si su organización todavía utiliza SSLv3, TLS 1.0/1.1 o IKEv1 en algún entorno de producción, no se trata de un proyecto futuro, sino de una brecha actual y explotable que conviene cerrar este trimestre.

Conclusión

Los protocolos de cifrado son las reglas que convierten los algoritmos de cifrado en sistemas de seguridad funcionales: TLS/SSL para el tráfico web cliente-servidor, IPsec para túneles de capa de red, SSH para administración remota, PGP y S/MIME para correo electrónico, y WireGuard para VPN modernas y ligeras. La elección correcta depende del caso de uso, no del protocolo que parezca más seguro, y todos ellos dependen de una capa de gestión de claves o PKI para cumplir con su promesa de seguridad. Mantenga las versiones obsoletas, SSLv3, TLS 1.0/1.1 e IKEv1 fuera de producción, establezca una versión mínima aceptada documentada para cada protocolo que utilice y trate la gestión del ciclo de vida de certificados y claves como parte integral del protocolo, no como un añadido posterior.

Preguntas Frecuentes

¿TLS es lo mismo que SSL?
No. SSL fue el predecesor de TLS y todas las versiones de SSL, incluida SSLv3, están ahora obsoletas (RFC 7568). En marketing y documentación, todavía se usa informalmente el término "SSL" para referirse a "TLS", pero ninguna implementación actual debería utilizar el protocolo SSL.

¿Debería deshabilitar TLS 1.2 ahora que existe TLS 1.3?
No necesariamente. TLS 1.2, configurado correctamente con los conjuntos de cifrado AEAD, sigue siendo un mínimo aceptado según NIST SP 800-52 Rev. 2. Desactive TLS 1.0/1.1 y SSLv3, pero mantenga TLS 1.2 disponible como alternativa hasta que haya confirmado que todos los clientes que debe admitir pueden negociar TLS 1.3.

¿Es WireGuard lo suficientemente seguro como para reemplazar a IPsec?
Para muchos casos de uso de acceso remoto y comunicación entre sitios, sí. El conjunto de cifrado fijo y moderno de WireGuard, junto con su código fuente reducido, facilita la auditoría en comparación con una pila IPsec completa. La contrapartida es que IPsec ofrece una mayor compatibilidad con proveedores y dispositivos, así como una mayor flexibilidad en la configuración del cifrado, características que aún requieren algunos entornos regulados o heredados.

¿Por qué SSH necesita tres RFC separados en lugar de uno solo?
Las funciones de transporte, autenticación y conexión de SSH están deliberadamente organizadas en capas para que cada una pueda evolucionar de forma independiente. Los RFC 4253 (transporte), RFC 4252 (autenticación) y RFC 4254 (conexión) se basan en la arquitectura base del RFC 4251, lo que permite que los métodos de autenticación cambien sin alterar el transporte cifrado subyacente.

¿Es más importante elegir el protocolo "más seguro" que la gestión de claves?
No. En nuestras evaluaciones, la configuración incorrecta del protocolo y las claves o certificados no gestionados generan mucha más exposición en el mundo real que la elección del algoritmo dentro de un protocolo moderno. Una implementación de TLS 1.2 correctamente gestionada es más segura en la práctica que una implementación de TLS 1.3 con certificados caducados o un almacenamiento de claves débil.

Referencias

• IETF, RFC 8446: Protocolo de seguridad de la capa de transporte (TLS) versión 1.3
• IETF, RFC 8996: Rechazo de TLS 1.0 y TLS 1.1
• IETF, RFC 7568: Rechazo de la versión 3.0 de Secure Sockets Layer
• IETF, RFC 7296: Protocolo de intercambio de claves de Internet versión 2 (IKEv2)
• IETF, RFC 9395: Desuso del protocolo de intercambio de claves de Internet versión 1 (IKEv1) y algoritmos obsoletos
• IETF, RFC 4251: Arquitectura del protocolo Secure Shell (SSH)
• IETF, RFC 4253: El protocolo de capa de transporte Secure Shell (SSH)
• IETF, RFC 9580: OpenPGP
• IETF, RFC 8551: Especificación de mensajes S/MIME versión 4.0
• NIST, SP 800-52 Revisión 2: Directrices para implementaciones de TLS
• WireGuard, WireGuard: Túnel de red del kernel de próxima generación