Un protocolo de enlace de seguridad de la capa de transporte (TLS) establece una comunicación cifrada y autenticada entre un cliente (como un navegador web) y un serverEl apretón de manos implica intercambiar mensajes y acordar normas criptográficas. algoritmos, verificando la serverLa identidad del usuario (y opcionalmente la del cliente) y generar una identidad compartida. llaves secretas para cifrar posteriormente transferencias de datosEs la base para el intercambio seguro de datos, garantizando que la información transmitida permanezca confidencial y a prueba de manipulaciones.
¿Qué significa el protocolo de enlace TLS?
Un protocolo de enlace TLS es una serie de pasos que inician una conexión segura mediante la validación de las partes involucradas, la selección de parámetros de seguridad compatibles y la creación de claves de cifrado compartidas. El protocolo de enlace determina cómo se cifrarán los datos, verifica la servercertificado digital y establece el canal seguro necesario para proteger integridad de los datos y confidencialidad. Es una parte esencial de TLS, un protocolo diseñado para brindar privacidad y data security a través de redes.
¿Cuáles son los componentes de un protocolo de enlace TLS?
A continuación se muestran los componentes principales que hacen posible un protocolo de enlace TLS.
Cliente y Server
El protocolo de enlace involucra a dos entidades principales: el cliente, que inicia la conexión (por ejemplo, un navegador web u otros Práctica ), y la server, que aloja el recurso o servicio al que el cliente desea acceder. El cliente inicia el protocolo de enlace proponiendo varios parámetros para cifrado y autenticación, y el server responde con las opciones elegidas según las configuraciones compatibles.
Suites de cifrado
Un conjunto de cifrados es una colección de algoritmos criptográficos utilizados durante el protocolo de enlace y las transferencias de datos posteriores. Incluye el algoritmo de intercambio de claves, el cifrado de cifrado masivo, el algoritmo de código de autenticación de mensajes y, a veces, el algoritmo de firma digital. El cliente sugiere una lista de conjuntos de cifrados que admite y el cliente server selecciona uno que reconoce y considera aceptable.
Certificados
Los certificados son documentos digitales que se utilizan para confirmar la identidad de una parte que se comunica. En la mayoría de las conexiones TLS, el server presenta un certificado X.509, que es emitido por un proveedor de confianza. Autoridad certificada (CA). Este certificado vincula al server, dominio nombre a una clave pública. El cliente verifica la cadena de certificados para asegurarse de que no haya sido alterada y de que haya sido emitida por una CA legítima.
Claves públicas y privadas
Las claves públicas y privadas son parte integral de TLS. server posee una clave privada que corresponde a la clave pública que figura en su certificado. Durante el protocolo de enlace, estas claves participan en operaciones criptográficas asimétricas. Los clientes utilizan la clave pública en el server certificado para cifrar un fragmento de datos (como el secreto pre-master), y solo el serverLa clave privada de puede descifrar él.
Claves de sesión
Una vez que el cliente y server acuerdan un conjunto de parámetros criptográficos, generan simetría claves de sesiónEstas claves cifran y descifran los mensajes durante la fase de transferencia de datos, lo que proporciona ventajas tanto en términos de confidencialidad como de rendimiento. Los algoritmos de cifrado simétrico suelen ser mucho más rápidos que los asimétricos, por lo que el protocolo de enlace utiliza métodos asimétricos para la autenticación y el intercambio de claves, y luego recurre a métodos simétricos para el cifrado de datos en masa.
¿Cómo funciona el protocolo de enlace TLS?
El protocolo de enlace TLS generalmente se desarrolla en varios pasos que garantizan un canal seguro y autenticado. Cada fase tiene un propósito definido y consta de intercambios de mensajes que finalizan los parámetros de cifrado y verifican la autenticidad de los datos. server y posiblemente el cliente.
ClienteHola
El cliente inicia el protocolo de enlace enviando un mensaje ClientHello al serverEste mensaje contiene la siguiente información:
- Una lista de conjuntos de cifrado compatibles y versiones de TLS.
- Un valor aleatorio (aleatorio del cliente) utilizado posteriormente en la generación de clave.
- Soportado compresión métodos (aunque la compresión está en gran medida obsoleta en las versiones recientes de TLS).
ServerHola
El server responde con un ServerHola mensaje. Esta respuesta incluye:
- La versión de TLS seleccionada.
- El conjunto de cifrado elegido de la propuesta del cliente.
- Otro valor aleatorio (server aleatorio).
Intercambio de certificados y claves
El server envía su certificado, que contiene la serverLa clave pública de junto con la cadena de certificados. Después de eso, el server puede enviar parámetros de intercambio de clave adicionales si el conjunto de cifrado elegido lo requiere (por ejemplo, en Diffie-Hellman o cifrados Diffie-Hellman de curva elíptica).
El cliente verifica la servercertificado de, garantizando que sea válido, no esté vencido y esté firmado por una CA confiable.
Verificación del cliente y secreto pre-master
Después de que el cliente verifique la serverCertificado de 's, genera un secreto pre-master y lo encripta usando el serverLa clave pública de 's. Este secreto pre-maestro encriptado se envía luego a la server.
El server utiliza su clave privada para descifrar el secreto pre-maestro, y ambas partes derivan claves de sesión del secreto pre-maestro, la del cliente aleatoria y la del cliente server azar.
Finalización del apretón de manos
Tanto el cliente como server Se envían mensajes de “Finalizado” entre sí, que se cifran con las claves de sesión recién derivadas. Estos mensajes verifican que las claves acordadas funcionan correctamente y que no se ha producido ninguna manipulación.
Una vez que estos mensajes se intercambian y verifican con éxito, el protocolo de enlace se completa y las comunicaciones posteriores se cifran utilizando las claves de sesión.
¿Cuándo se produce un protocolo de enlace TLS?
Un protocolo de enlace TLS se produce siempre que un cliente inicia una nueva conexión segura a un server sobre TLS. Los escenarios más comunes incluyen:
- Acceder a un sitio web mediante HTTPS (HTTP sobre TLS).
- Iniciando correo electrónico seguro comunicaciones (como SMTPS, IMAPS o POP3S).
- Conectarse a aplicaciones seguras que dependen de TLS para el cifrado (por ejemplo, túneles VPN o seguro presentar transferencias).
El protocolo de enlace se repite si se establece una nueva sesión o si se activa una renegociación TLS para actualizar las claves criptográficas para conexiones de larga duración.
Ejemplo de protocolo de enlace TLS
A continuación se muestra un tutorial sobre cómo se produce un protocolo de enlace HTTPS (HTTP sobre TLS) típico entre un cliente y un server.
Paso 1: Página segura de solicitudes del cliente
El navegador web de un usuario inicia una conexión segura enviando un mensaje ClientHello al server en “example.com”. El mensaje ClientHello es parte del protocolo de enlace TLS y contiene varios datos importantes:
- Versiones de protocolo compatiblesEl cliente propone una o más versiones de TLS (por ejemplo, TLS 1.2, TLS 1.3) que puede utilizar.
- Cliente aleatorio. Un 32-byte Valor aleatorio generado por el cliente, utilizado posteriormente en la derivación de clave.
- ID de sesión o ticket de sesión. Si el cliente se ha conectado recientemente al mismo server y tiene un ticket de sesión válido o una ID de sesión, puede ofrecerlo para solicitar la reanudación de la sesión, lo que puede omitir o acortar algunos pasos del protocolo de enlace.
- Conjuntos de cifradosEstas suites son una lista de algoritmos criptográficos que el cliente admite. Cada suite de cifrado especifica un mecanismo de intercambio de claves (por ejemplo, RSA, ECDHE), un algoritmo de cifrado (por ejemplo, AES) y un código de autenticación de mensaje o un algoritmo de etiqueta de autenticación (por ejemplo, SHA256).
- Prórrogas de tiempo para presentar declaraciones de impuestosLas implementaciones modernas de TLS incluyen varias extensiones como server indicación del nombre (SNI), que indica la hostname El cliente está intentando acceder. Las extensiones adicionales pueden indicar curvas elípticas admitidas, algoritmos de firma y otros parámetros que mejoran la seguridad o el rendimiento.
Al recibir este ClientHello, el server examina los conjuntos de cifrados propuestos y las versiones de TLS para determinar si admite alguno de ellos. El protocolo de enlace TLS continúa solo si el server encuentra al menos un conjunto compatible de parámetros.
Paso 2: Server Responde
Después de procesar el ClientHello, el server responde con un ServerMensaje de saludo. Se incluyen varios elementos clave:
- Versión del protocolo elegida. server selecciona una versión de TLS (por ejemplo, TLS 1.2) que tanto el cliente como server apoyo.
- Server azar. Otro valor aleatorio de 32 bytes generado por el server, utilizado con el cliente aleatorio para derivar claves compartidas.
- Selección de conjuntos de cifrados. De la lista de clientes, el server Selecciona un único conjunto de cifrados que admita. Por ejemplo, podría elegir un intercambio de claves ECDHE_RSA, cifrado AES_128_GCM y SHA256 para la autenticación de mensajes.
- ID de sesión o ticket de nueva sesión. Si el server Admite la reanudación de sesión, puede aceptar la ID de sesión propuesta por el cliente o proporcionar una nueva.
- Prórrogas de tiempo para presentar declaraciones de impuestos. server Incluye respuestas de extensión relevantes, indicando parámetros o restricciones específicos.
Tras el ServerHola, la server Normalmente envía mensajes de protocolo de enlace adicionales:
- Certificado. server transmite su cadena de certificados, que incluye su certificado de entidad final (el certificado real) server certificado) y cualquier certificado intermedio necesario para vincularlo a una autoridad de certificación raíz (CA).
- Server intercambio de llavesDependiendo del conjunto de cifrado elegido, el server proporciona parámetros de intercambio de claves (por ejemplo, clave pública efímera Diffie-Hellman) que el cliente utilizará para generar un secreto compartido.
- Solicitud de certificado (opcional). Si el server Requiere autenticación del cliente, solicita un certificado de cliente en esta etapa. Esto es menos común en la navegación web típica, pero más frecuente en entornos que necesitan TLS mutuo.
Paso 3: Validación del certificado
El cliente examina el serverCertificado de 's para garantizar que la conexión es realmente con el host deseado y no con un impostor:
- Verificación de la cadena de certificadosEl cliente comprueba que el serverEl certificado de es emitido y firmado por una CA de confianza. El navegador o sistema operativo Mantiene un almacén de certificados raíz de confianza. El navegador también comprueba los certificados intermedios para formar una cadena de confianza válida hasta una CA raíz reconocida.
- Caducidad y vigenciaEl cliente inspecciona las fechas “No anterior” y “No posterior” del certificado para confirmar que el certificado sea válido actualmente.
- Coincidencia de nombres de dominioEl cliente confirma que el nombre de dominio que figura en el certificado (que suele encontrarse en el campo Nombre alternativo del sujeto) coincide con “example.com” o con el dominio solicitado.
- Comprobación de revocaciónEl cliente puede utilizar la lista de revocación de certificados (CRL) o el protocolo de estado de certificado en línea (OCSP) para ver si el certificado o algún certificado intermedio ha sido revocado.
Si alguna parte del proceso de validación falla (por ejemplo, una firma no válida, un certificado vencido o un nombre de dominio no coincidente), el cliente normalmente finaliza la conexión o muestra una advertencia al usuario.
Paso 4: Intercambio de claves y generación de claves de sesión
Una vez que el cliente haya validado la serverTras el certificado del cliente (y opcionalmente enviando su propio certificado si se solicita), el cliente procede al intercambio de claves:
- Intercambio de claves de clienteSi se utiliza un intercambio de claves RSA, el cliente genera una secreto pre-maestro y lo encripta con el serverLa clave pública de (obtenida de la server certificado). Si se utiliza un conjunto de cifrado ECDHE o DHE, el cliente también proporciona su propia clave pública efímera para los cálculos Diffie-Hellman.
- Descifrado o cálculo de clave compartida. server descifra el secreto pre-master con su clave privada o, en el caso de Diffie-Hellman/ECDHE, combina la del cliente y serverClaves públicas de para calcular un secreto compartido.
- Derivación del secreto maestro. Al utilizar el secreto pre-master (o secreto compartido DH), el cliente y server Ambos derivan un secreto maestro. Esta derivación también implica la aleatoriedad del cliente y server Aleatorio. Se utilizan funciones pseudoaleatorias (como las de TLS 1.2 o el “Handshake Secret” de TLS 1.3) para garantizar una aleatoriedad criptográfica sólida.
- Creación de clave de sesión. Del secreto maestro, el cliente y server Generar claves simétricas independientes para cifrar los datos salientes, descifrar los datos entrantes y verificar la integridad de los mensajes. Estas claves de sesión suelen negociarse para que sean efímeras (especialmente en cifrados basados en ECDHE), lo que proporciona secreto hacia adelante.
Paso 5: Transferencia segura de datos
Después de que ambos lados derivan las claves de sesión, el cliente y server intercambiar Terminados mensajes:
- Mensajes terminadosCada parte calcula un hash criptográfico de todos los mensajes de protocolo de enlace enviados hasta el momento (la transcripción del protocolo de enlace) y lo cifra con las claves de sesión recién establecidas. Estos mensajes de “Finished” (Terminado) verifican que ambas partes comparten el mismo estado de protocolo de enlace y que no se ha producido ninguna manipulación.
- Confirmación de apretón de manos. El cliente y server Confirmar la recepción del mensaje Finalizado de cada uno. Si los hashes coinciden, indica que el protocolo de enlace se completó con éxito y de forma segura.
- Datos de aplicación cifrados. Datos posteriores, como HTML archivos, imágenes o cualquier otro contenido de la capa de aplicación, se cifra con la clave simétrica acordada. El cifrado garantiza la confidencialidad, mientras que la protección criptográfica hachís o MAC (dependiendo del conjunto de cifrado) garantiza la integridad.
- Persistencia de la conexión y reanudación de la sesiónSi alguna de las partes admite la reanudación de la sesión TLS, pueden reutilizar el secreto maestro negociado para una conexión futura. Esto reduce la sobrecarga que supone realizar nuevamente un protocolo de enlace completo.
Una vez que se completa la fase de protocolo de enlace, el navegador y server Comunicarse a través de un canal seguro. Los navegadores suelen mostrar un icono de candado o un indicador similar en la barra de direcciones para indicar que la conexión está cifrada y autenticada mediante TLS.
¿Por qué son importantes los protocolos de enlace TLS?
Un protocolo de enlace TLS proporciona un método para establecer comunicaciones seguras en redes que pueden ser susceptibles a escuchas o manipulaciones.
De un apretón de manos exitoso surgen varios beneficios:
- AutenticaciónEl cliente tiene la seguridad de que serverLa identidad de, evitando ataques de hombre en el medio.
- ConfidencialidadTodo el tráfico que sigue al protocolo de enlace está encriptado, lo que garantiza que terceros no autorizados no puedan leer los datos.
- Integridad de datosLa autenticación de mensajes garantiza que los datos transmitidos no se hayan alterado durante el tránsito.
El proceso de protocolo de enlace, mediante el uso de algoritmos criptográficos y certificados, establece una sólida capa de confianza que protege la información durante el tránsito.
¿Qué pasa si falla un protocolo de enlace TLS?
Un protocolo de enlace TLS fallido da como resultado la imposibilidad de crear una conexión segura. La conexión a menudo se termina y los usuarios pueden encontrar mensajes de error como "SSL / TLS “Error en el protocolo de enlace” o “No se puede establecer una conexión segura”.
La falla ocurre cuando problemas como versiones TLS incompatibles, certificados no válidos, certificados vencidos o relojes de sistema incorrectos impiden una negociación exitosa.
¿Cómo solucionar un problema de protocolo de enlace TLS?
Administradores del sistema y los usuarios finales pueden resolver los fallos del protocolo de enlace abordando las causas fundamentales:
- Actualizar o instalar certificados válidosDebe reemplazar los certificados vencidos o no válidos. Los proveedores de alojamiento y los administradores deben asegurarse de que los certificados estén firmados por CA confiables y se mantengan actualizados.
- Comprobar configuración y protocolos soportados. Asegurarse de que tanto el cliente como server Es fundamental admitir las mismas versiones de TLS y conjuntos de cifrado. Deshabilitar protocolos antiguos como SSLv3 o TLS 1.0 elimina los problemas conocidos. vulnerabilidades y evita errores de protocolo de enlace relacionados con métodos de cifrado obsoletos.
- Sincronizar los relojes del sistemaLos relojes de sistema precisos son importantes para validar los tiempos de caducidad y validez de los certificados. server o un cliente con una configuración horaria incorrecta puede rechazar certificados que de otro modo serían válidos.
- Verificar almacenes de confianza de CAEl sistema operativo o la aplicación del cliente mantienen una lista de CA de confianza. Verificar que la CA raíz o intermedia relevante esté presente y no haya sido revocada ayuda a prevenir errores de protocolo de enlace.
- Inspeccciona server configuración. Mal configurado servers (por ejemplo, prioridades de conjuntos de cifrado incorrectos o cadenas de certificados incompletas) a menudo provocan problemas de protocolo de enlace. server Los registros y las configuraciones ayudan a identificar la falta de coincidencia y permiten una resolución rápida.
¿Cuál es la diferencia entre el protocolo de enlace SSL y TLS?
El término "protocolo de enlace SSL" se refiere al proceso de protocolo de enlace utilizado por el Capa de sockets seguros (SSL) Protocolo de enlace TLS, que era un estándar anterior para cifrar y proteger datos. El protocolo de enlace TLS es la evolución moderna de SSL, que ofrece medidas de seguridad más sólidas y algoritmos criptográficos actualizados.
Aunque los flujos de trabajo son similares, TLS introdujo mejoras con respecto a SSL, como conjuntos de cifrado mejorados, mejor manejo de certificados y mecanismos criptográficos más robustos. SSL ha quedado obsoleto debido a vulnerabilidades conocidas y la mayoría de los sistemas modernos utilizan TLS para comunicaciones seguras.
Muchas referencias aún utilizan “SSL” para describir el protocolo de enlace seguro incluso cuando se utiliza TLS en segundo plano, pero el término más preciso en las implementaciones actuales es “protocolo de enlace TLS”. El principio básico sigue siendo el mismo: un proceso de protocolo de enlace negocia parámetros de seguridad, intercambia certificados y establece claves compartidas para la comunicación cifrada.
