Solución: no se puede conectar de forma segura a esta página en Microsoft Edge (resuelto). El cliente y el servidor admiten diferentes versiones del protocolo SSL o conjunto de cifrado. ¿Qué es un certificado SSL y por qué es necesario?

La ciberseguridad puede parecer un campo minado con todas sus complejidades. Quizás no sepas qué es SSL o TLS, pero es importante. TLS es lo que evita que los piratas informáticos espíen su tráfico y roben los datos de su tarjeta mientras utiliza la banca en línea. pero como funciona?

Definición de SSL y TLS

SSL y TLS son protocolos criptográficos que cifran y autentican los datos enviados desde un cliente (es decir, su dispositivo que solicita un sitio web) a un servidor, computadora o aplicación.

SSL es el predecesor de TLS. El protocolo SSL se lanzó por primera vez en 1995. Sin embargo, tenía muchas vulnerabilidades, por lo que un año después fue reemplazado por SSL v3.0. Esto último tampoco era ideal, por lo que se introdujo TLS en 1999. La mayoría de los dispositivos y navegadores han cambiado a TLS v1.2. Sin embargo, muchas personas están tan acostumbradas al término SSL que lo llamarán TLS SSL. La mayoría utiliza ahora el término dual SSL/TLS para una mejor comprensión.

¿Por qué los sitios web necesitan SSL/TLS?

SSL/TLS interactúa con HTTP y es lo que agrega S–HTTPS. HTTP es un protocolo de aplicación que transfiere datos desde el navegador al servidor o, en términos más simples, entrega resultados de búsqueda a su navegador. Sin embargo, las conexiones HTTP no son seguras en sí mismas. Es lo mismo que enviar tus datos al dominio público: cualquiera puede verlos. HTTP es vulnerable a ataques, lo que significa que cualquiera que espíe su tráfico podría robar sus datos de inicio de sesión o de su tarjeta.

Por eso se introdujo HTTPS. Es una combinación de HTTP, que maneja la mecánica de la transferencia de datos, y SSL/TLS, que maneja el cifrado de datos. Con el cifrado SSL/TLS, sus datos de seguridad significan que cualquiera que espíe su tráfico ahora sólo podrá ver los datos cifrados. Hoy en día, la mayoría de los sitios web utilizan HTTPS.

El cifrado SSL/TLS se puede dividir en dos etapas: protocolo de enlace SSL/TLS y capa de registro SSL/TLS. Merece la pena profundizar en ellos con más detalle.

¿Qué es el protocolo de enlace SSL?

Es una forma de comunicación entre un cliente y un servidor, donde ambos deciden qué versión del protocolo se utilizará para su comunicación posterior. ¿Cómo funciona esto en la práctica?

1. El cliente envía una solicitud de "hola" al servidor con el que desea contactar. Incluye los tipos de cifrados (algoritmos de cifrado) que el cliente puede admitir.
2. El servidor devuelve un 'hola' con su certificado SSL y su clave pública. Aquí el cliente y el servidor utilizan criptografía asimétrica para intercambiar mensajes seguros. Esto significa que el cliente necesita la clave pública del servidor para cifrar el mensaje y el servidor necesita dos claves, una privada y otra pública, para descifrarlo. Nadie que espíe el tráfico puede descifrar sus mensajes.
3. Luego, el cliente utiliza la clave pública del servidor para crear un pre-maestro y lo envía al servidor. Esto se utilizará para generar claves de sesión y actualizar las comunicaciones a cifrado simétrico. Ahora ambos extremos utilizarán sólo claves privadas. La criptografía simétrica hará que su comunicación sea mucho más rápida y utilice menos recursos.
4. El servidor descifra el pre-maestro, lo usa para crear una clave simétrica y la intercambia con el cliente. Con el cifrado simétrico instalado, ahora pueden intercambiar mensajes cifrados. El tráfico está protegido.

Nivel de grabación SSL/TLS

Aquí es donde ocurre el cifrado. Los datos se envían desde la aplicación del usuario y están cifrados. Dependiendo del cifrado, también puede estar comprimido. Luego se envía a la capa de transporte de red, que determina cómo enviar los datos al dispositivo de destino.

¿Qué es un certificado SSL y por qué es necesario?

Los servidores que soportan el protocolo TLS tendrán certificados SLS, aunque sería más exacto llamarlos certificados SSL/TLS. Estos se compran en plataformas de alojamiento y son necesarios durante el proceso de protocolo de enlace SSL/TLS para garantizar que sean realmente proveedores de conexión segura.

Sin embargo, los protocolos no son lo mismo que los certificados. Si la conexión utiliza SSL o TLS lo determina su navegador y las configuraciones del servidor de destino, no el certificado del sitio. Es posible conectarse a un sitio que tenga HTTPS pero utilice el protocolo SSL v3.0 heredado.

Estas conexiones son vulnerables a los ataques. La mayoría de los navegadores nuevos lo indicarán en su URL. Simplemente busque los candados verdes cerrados y los símbolos HTTPS. Si le preocupa conectarse accidentalmente a un sitio que solo admite SSL v3.0, puede desactivar manualmente las conexiones SSL. Pero esto puede provocar una pérdida de comunicación.

En vídeo: SSL/TLS: historia de vulnerabilidades

Según los requisitos de la legislación rusa, sólo se reconoce el uso de conexiones TLS establecidas según los algoritmos criptográficos rusos GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 y GOST R 34.10-2001. Por lo tanto, si necesita utilizar sitios que utilizan cifrado según algoritmos GOST, debe instalar el programa CryptoPro CSP.

Los sistemas operativos Windows utilizan el programa CryptoPro CSP, un conjunto de utilidades criptográficas para generar firmas electrónicas y trabajar con certificados.

Para instalar CryptoPro CSP, utilice los materiales del sitio web oficial:

Después de instalar CryptoPro CSP, el navegador verifica la presencia y funcionalidad de este programa.

Sitios que solicitan cifrado GOST TLS

Si un sitio solicita el cifrado GOST TLS, el navegador verifica si el programa CryptoPro CSP está instalado. Si el programa está instalado, se le transfiere el control.

Ejemplos de sitios que solicitan cifrado: www.gosuslugi.ru, sitios del dominio .gov.ru, .kamgov.ru, .nalog.ru.

Si el sitio no está en la lista, se solicita confirmación adicional. Si confía en el sitio y la conexión debe realizarse mediante cifrado GOST TLS, haga clic en el botón Continuar.

¿Qué es un protocolo de enlace TLS y cómo funciona?

TLS es una de las herramientas de seguridad más utilizadas en Internet. El protocolo trabaja activamente con muchos procesos de comunicación de red: transferencias de archivos, conexiones VPN (en algunas implementaciones para intercambio de claves), servicios de mensajería instantánea o telefonía IP.

Uno de los aspectos clave del protocolo es el apretón de manos. De esto es de lo que hablaremos en este artículo.

"Apretón de enlace SSL/TLS" es el nombre del paso para establecer una conexión HTTPS. La mayor parte del trabajo asociado con el protocolo SSL/TLS se realiza en esta etapa. El año pasado, el IETF finalizó TLS 1.3, renovando por completo el proceso de protocolo de enlace.
El artículo cubrirá dos tipos de protocolos de enlace: para los protocolos TLS 1.2 y TLS 1.3, que consideraremos, comenzando desde el nivel abstracto y profundizando gradualmente en los detalles:

• coordinación de protocolos criptográficos;
• autenticación mediante un certificado SSL;
• Generación de claves de sesión.

¿Cómo funciona un protocolo de enlace TLS?

Una conexión HTTPS involucra dos partes: el cliente (el iniciador de la conexión, generalmente un navegador web) y el servidor. El propósito del protocolo de enlace SSL/TLS es realizar todo el trabajo criptográfico para establecer una conexión segura, incluida la verificación de la autenticidad del certificado SSL en uso y la generación de la clave de cifrado.

Negociación de marcación

Cada software es único. Por lo tanto, incluso los navegadores web más populares tienen funciones diferentes. Del mismo modo, en el lado del servidor, Windows Server, Apache y NGINX también son diferentes entre sí. Las cosas se vuelven aún más complicadas cuando agregas configuraciones personalizadas.

Es por eso que el primer paso de un protocolo de enlace TLS es que el cliente y el servidor intercambien información sobre sus capacidades para seleccionar aún más las funciones criptográficas admitidas.

Una vez que el cliente y el servidor acuerdan el conjunto de cifrado que utilizarán, el servidor envía su certificado SSL al cliente.

Autenticación

Una vez recibido el certificado, el cliente comprueba su autenticidad. Este es un paso extremadamente importante. Para garantizar una conexión segura, no sólo necesita cifrar los datos, sino que también debe asegurarse de que se envíen al sitio web correcto. Los certificados SSL/TLS proporcionan esta autenticación y la forma en que lo hacen depende del conjunto de cifrado utilizado.

Todos los certificados SSL de confianza son emitidos por una autoridad certificadora (CA). Una CA debe seguir reglas estrictas para emitir y validar certificados para que sean confiables. Puede pensar en una CA como algo así como un notario público: su firma significa que los datos del certificado son reales.

Durante la parte de autenticación del protocolo de enlace TLS, el cliente realiza varias comprobaciones criptográficamente seguras para garantizar que el certificado emitido por el servidor sea válido. El proceso implica verificar la firma digital y si el certificado fue emitido por una CA confiable.

En este punto, el cliente comprueba indirectamente si el servidor posee la clave privada asociada con el certificado.

En RSA, el criptosistema de clave pública más utilizado, el cliente utiliza la clave pública para cifrar datos aleatorios que se utilizarán para generar la clave de sesión. El servidor podrá descifrar y utilizar estos datos sólo si dispone de una clave privada cuya presencia garantiza la autenticidad de la parte.

Si se utiliza un criptosistema diferente, el algoritmo puede cambiar, pero aún así se verificará la autenticidad de la otra parte.

Intercambio de llaves

La última parte del protocolo de enlace TLS implica la creación de una "clave de sesión" que realmente se utilizará para una comunicación segura.

Las claves de sesión son "simétricas", lo que significa que se utiliza la misma clave para cifrar y descifrar.

El cifrado simétrico es más rápido que el cifrado asimétrico, lo que lo hace más adecuado para enviar datos a través de una conexión HTTPS. El método exacto de generación de claves depende del conjunto de cifrado elegido; los dos más comunes son RSA y Diffie-Hellman.

Para completar el apretón de manos, cada parte le dice a la otra que ha realizado todo el trabajo necesario y luego verifica las sumas de verificación para garantizar que el apretón de manos se haya producido sin interferencias ni corrupción.

Todo el protocolo de enlace SSL se produce en unos pocos cientos de milisegundos. Esto es lo primero que sucederá en una conexión HTTPS, incluso antes de que se cargue la página web. Después del protocolo de enlace SSL, comienza una conexión HTTPS cifrada y autenticada, y todos los datos enviados y recibidos por el cliente y el servidor están protegidos.

Hasta TLS 1.3, cada vez que visitaba un sitio, el apretón de manos se producía nuevamente. El protocolo de enlace TLS 1.3 admite 0-RTT, o tiempo de reanudación de ida y vuelta cero, lo que aumenta considerablemente la velocidad para el visitante que regresa.

Proceso de protocolo de enlace paso a paso en TLS 1.2

Echemos un vistazo más de cerca al protocolo de enlace TLS utilizando RSA. El uso del algoritmo Diffie-Hellman se describirá a continuación.

1. El primer mensaje se llama "Cliente Hola". Este mensaje enumera las capacidades del cliente para que el servidor pueda seleccionar el conjunto de cifrado que se utilizará para la comunicación. El mensaje también incluye un número primo grande seleccionado al azar llamado "número aleatorio del cliente".
2. El servidor responde cortésmente con un mensaje de "Servidor Hola". Allí le dice al cliente qué parámetros de conexión se han seleccionado y devuelve su número primo seleccionado aleatoriamente, llamado "número aleatorio del servidor". Si el cliente y el servidor no comparten los mismos conjuntos de cifrado, la conexión falla.
3. En el mensaje "Certificado", el servidor envía su cadena de certificados SSL al cliente, incluidos los certificados hoja e intermedios. Una vez que el cliente los recibe, realiza varias comprobaciones para verificar el certificado. El cliente también debe verificar que el servidor tenga la clave privada del certificado, lo que ocurre durante el proceso de intercambio/generación de claves.
4. Este es un mensaje opcional, requerido solo para ciertos métodos de intercambio de claves (como Diffie-Hellman) que requieren datos adicionales del servidor.
5. El mensaje "Server Hello Done" notifica al cliente que el servidor ha terminado de transmitir datos.
6. Luego, el cliente participa en la creación de una clave de sesión. Los detalles de este paso dependen del método de intercambio de claves elegido en los mensajes de saludo originales. Dado que estamos hablando de RSA, el cliente generará una cadena de bytes aleatoria llamada secreto premaestro, la cifrará con la clave pública del servidor y la devolverá.
7. El mensaje "Cambiar especificación de cifrado" le permite a la otra parte saber que se ha generado la clave de sesión y que puede cambiar a una conexión cifrada.
8. Luego se envía un mensaje "Finalizado", que indica que el protocolo de enlace se completó en el lado del cliente. A partir de este momento la conexión queda protegida con una clave de sesión. El mensaje contiene datos (MAC) que se pueden utilizar para verificar que el protocolo de enlace no ha sido manipulado.
9. Ahora el servidor descifra el secreto previo al maestro y calcula la clave de sesión. Luego envía un mensaje "Cambiar especificación de cifrado" para notificar que está cambiando a una conexión cifrada.
10. El servidor también envía un mensaje "Finalizado" utilizando la clave de sesión simétrica recién generada y verifica la suma de verificación para verificar la integridad de todo el protocolo de enlace.

Después de estos pasos, se completa el protocolo de enlace SSL. Ambas partes ahora tienen una clave de sesión y pueden comunicarse a través de una conexión cifrada y autenticada.

En este punto, se pueden enviar los primeros bytes de la aplicación web (datos relacionados con el servicio real: HTML, Javascript, etc.).

Proceso de protocolo de enlace paso a paso en TLS 1.3

El protocolo de enlace TLS 1.3 es significativamente más corto que el de su predecesor.

1. Al igual que con TLS 1.2, el mensaje "Cliente Hola" inicia el protocolo de enlace, pero esta vez contiene mucha más información. TLS 1.3 redujo la cantidad de cifrados admitidos de 37 a 5. Esto significa que el cliente puede adivinar qué acuerdo de clave o protocolo de intercambio se utilizará, por lo que además del mensaje envía su parte de la clave pública del protocolo adivinado.
2. El servidor responderá con un mensaje de "Servidor Hola". Al igual que con el protocolo de enlace 1.2, en esta etapa se envía un certificado. Si el cliente adivinó correctamente el protocolo de cifrado con los datos adjuntos y el servidor lo aceptó, este último envía su parte de la clave pública, calcula la clave de sesión y completa la transmisión con el mensaje "Servidor finalizado".
3. Ahora que el cliente tiene toda la información necesaria, verifica el certificado SSL y utiliza las dos claves públicas para calcular su copia de la clave de sesión. Cuando se hace esto, envía un mensaje de "Cliente finalizado".

Generalidades del protocolo de enlace TLS

Históricamente, una de las quejas sobre SSL/TLS fue que sobrecargaba los servidores con gastos generales adicionales. Esto influyó en la noción ahora desaparecida de que HTTPS es más lento que HTTP.

Los apretones de manos antes de TLS 1.2 requerían muchos recursos y, a gran escala, podían cargar seriamente el servidor. Incluso los apretones de manos TLS 1.2 pueden ralentizarse si se producen muchos al mismo tiempo. La autenticación, el cifrado y el descifrado son procesos costosos.

En sitios web pequeños esto probablemente no causará ninguna desaceleración notable, pero en sistemas empresariales que reciben cientos de miles de visitantes todos los días esto puede ser un gran problema. Cada nueva versión del protocolo de enlace simplifica significativamente el proceso: TLS 1.2 realiza dos fases, mientras que TLS 1.3 cabe en una sola y admite 0-RTT.

Mejoras en el protocolo de enlace de TLS 1.3 sobre TLS 1.2

En la explicación anterior, el apretón de manos se divide en diez etapas separadas. En realidad, muchas de estas cosas suceden simultáneamente, por lo que a menudo se agrupan y se denominan fases.

El protocolo de enlace TLS 1.2 tiene dos fases. A veces pueden ser necesarios más, pero cuando se trata de cantidad, el escenario predeterminado es el óptimo.

A diferencia de 1.2, el protocolo de enlace TLS 1.3 encaja en una fase, aunque sería más exacto decir una y media, pero sigue siendo significativamente más rápido que TLS 1.2.

Reducción de conjuntos de cifrado

Nadie tuvo la intención de utilizar 37 suites para cifrar datos, y así fue como evolucionó el protocolo. Cada vez que se agregaba un nuevo algoritmo, se agregaban nuevas combinaciones y pronto la IANA administró 37 conjuntos de cifrado diferentes.

Esto es malo por dos razones:

1. Esta variabilidad conduce a configuraciones erróneas que dejan a los usuarios de Internet vulnerables a exploits conocidos.
2. Esto hizo que la configuración de SSL fuera más confusa.

El IETF eliminó el soporte para todos los algoritmos excepto los más seguros en TLS 1.3, eliminando la confusión al limitar las opciones. En particular, se ha eliminado la elección del método de intercambio de claves. El efímero esquema Diffie-Hellman se convirtió en la única forma para que un cliente enviara su información clave junto con el "Cliente Hola" en la primera parte del apretón de manos. El cifrado RSA se ha eliminado por completo junto con todos los demás esquemas de intercambio de claves estáticas.

Dicho esto, existe un posible talón de Aquiles en TLS 1.3.

Tiempo de reanudación del viaje de ida y vuelta cero: 0-RTT

0-RTT es lo que todo el mundo tecnológico ha estado pidiendo a gritos, y ahora está aquí con TLS 1.3. Como se mencionó, el protocolo de enlace TLS históricamente ha sido lento, por lo que era importante acelerarlo. 0-RTT hace esto almacenando información secreta sobre el cliente, generalmente un ID de sesión o tickets de sesión, para usar en la siguiente conexión.

A pesar de todos los beneficios de 0-RTT, contiene un par de peligros potenciales. El modo hace que los clientes sean susceptibles a ataques de repetición, donde un atacante que de alguna manera logra acceder a la sesión cifrada puede obtener los datos 0-RTT, incluida la primera solicitud del cliente, y enviarlos de vuelta al servidor.

Sin embargo, el exploit no es fácil de utilizar. Este riesgo es probablemente un pequeño precio a pagar por una característica extremadamente útil.

Seguridad

Desde el principio, hubo preocupación por la cantidad de información enviada en texto claro durante un apretón de manos. Obviamente, esto no es seguro, por lo que cuantos más pasos de protocolo de enlace se realicen cifrados, mejor.

En el protocolo de enlace TLS 1.2, las etapas de negociación no estaban protegidas, sino que se utilizaba una función MAC simple para garantizar que nadie interfiriera con la transmisión. La fase de negociación incluye mensajes de "Hola del cliente" y "Hola del servidor".

La función MAC actúa como indicador, pero no ofrece ninguna garantía de seguridad. Es posible que haya oído hablar de un ataque que obliga a las partes a utilizar protocolos y funciones menos seguros (ataque de degradación). Si tanto el servidor como el cliente admiten conjuntos de cifrado obsoletos (la información al respecto se puede obtener fácilmente escuchando a escondidas la conexión), un atacante puede cambiar el cifrado elegido por el servidor por uno más débil. Estos ataques no son peligrosos en sí mismos, pero abren la puerta al uso de otros exploits conocidos de los conjuntos de cifrado a los que se cambió el original.

El protocolo de enlace TLS 1.3 utiliza una firma digital en las primeras etapas de la conexión, lo que la hace más segura y protege contra ataques que rompen el cifrado. La firma también le permite autenticar el servidor de forma más rápida y eficiente.

Ahora veamos cómo se implementarán estas actualizaciones del protocolo de enlace TLS 1.3 en las tres funciones principales del protocolo de enlace SSL/TLS.

Conjuntos de cifrado de protocolo de enlace TLS

Un conjunto de cifrado es un conjunto de algoritmos que determinan los parámetros de una conexión segura.

Al inicio de cualquier conexión, la primera interacción, "Cliente Hola", es una lista de conjuntos de cifrado admitidos. El servidor elige la mejor y más segura opción que admite y cumple con sus requisitos. Puede consultar el conjunto de cifrado y descubrir todos los parámetros de conexión y protocolo de enlace.

Conjuntos de cifrado TLS 1.2

• TLS es un protocolo.
• ECDHE es un algoritmo de intercambio de claves.
• ECDSA es un algoritmo de autenticación.
• AES 128 GCM es un algoritmo de cifrado simétrico.
• SHA256 es un algoritmo hash.

El ejemplo anterior utiliza el sistema efímero Elliptic Curve Diffie-Hellman (DH) para el intercambio de claves y el algoritmo de firma digital Elliptic Curve para la autenticación. DH también se puede combinar con RSA (que funciona como un algoritmo de firma digital) para realizar la autenticación.

A continuación se muestra una lista de los conjuntos de cifrado TLS 1.2 más compatibles:

Conjuntos de cifrado TLS 1.3

• TLS es un protocolo.
• AES 256 GCM es un algoritmo de cifrado autenticado con datos adjuntos (AEAD).
• SHA384 es el algoritmo de función de generación de clave hash (HKFD).

Ya sabemos que usaremos alguna versión del intercambio de claves efímeras Diffie-Hellman, pero no conocemos los parámetros, por lo que los dos primeros algoritmos del conjunto de cifrado TLS 1.2 ya no son necesarios. Estas funciones aún funcionan, simplemente ya no es necesario negociarlas durante un apretón de manos.

En el ejemplo anterior, puede ver que AES (Estándar de cifrado avanzado) se utiliza para cifrar una gran cantidad de datos. Funciona en modo contador Galois utilizando claves de 256 bits.

Estos son los cinco conjuntos de cifrado compatibles con TLS 1.3:

• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_128_GCM_SHA256;
• TLS_AES_128_CCM_8_SHA256;
• TLS_AES_128_CCM_SHA256.

¿Qué ha cambiado en TLS 1.3 en comparación con TLS 1.2?

Es importante recordar que la versión 1.3 se diseñó teniendo en cuenta las mejoras de seguridad y rendimiento. Para lograrlo, en TLS 1.3 se rediseñó el algoritmo de generación de claves y se solucionaron las vulnerabilidades conocidas.

El protocolo de enlace TLS 1.3 también mejora algunos procesos, como la autenticación de mensajes y las firmas digitales.

Finalmente, además de eliminar gradualmente los algoritmos de intercambio o generación de claves más antiguos, TLS 1.3 elimina los cifrados simétricos más antiguos. TLS 1.3 eliminó por completo los cifrados en bloque. El único tipo de cifrado simétrico permitido en TLS 1.3 se llama cifrado autenticado con datos adicionales (AEAD). Combina cifrado y autenticación de mensajes (MAC) en una sola función.

Autenticación en protocolo de enlace TLS

Históricamente, las dos principales opciones de intercambio de claves son RSA y Diffie-Hellman (DH); en la actualidad, DH se asocia a menudo con Elliptic Curve Key Exchange (ECDH). A pesar de algunas similitudes básicas, existen diferencias fundamentales entre estos dos enfoques del intercambio de claves.

En otras palabras, el protocolo de enlace RSA TLS es diferente del protocolo de enlace ECDH TLS.

RSA utiliza factorización prima y aritmética modular. Los números primos grandes requieren mucha potencia de CPU para calcularse y son difíciles de encontrar.

A Diffie-Hellman a veces se le llama intercambio de claves exponencial, lo que indica exponenciación (además de aritmética modular), pero DH en sí no cifra ni descifra nada en absoluto. Por lo tanto, llamarlo "método de cifrado" en lugar de "razonamiento matemático" puede resultar un poco engañoso.

Una breve excursión a la historia puede aclarar este punto.

Allá por 1976, Whitfield Diffie y Martin Hellman crearon un protocolo de intercambio de claves basado en el trabajo de Ralph Merkle, cuyo nombre, según ambos, también debería aparecer en el nombre del protocolo.

Intentaron resolver el problema del intercambio seguro de claves a través de un canal inseguro, incluso si un atacante lo está escuchando. Lo lograron, pero hubo un defecto importante: el intercambio de claves DH no incluía autenticación, por lo que no había forma de verificar la parte en el otro extremo de la conexión.

Esto puede considerarse el nacimiento de la criptografía de clave pública y la PKI. Poco después de que Diffie y Hellman introdujeran su protocolo de intercambio de claves, se completaron las primeras versiones del criptosistema RSA. Diffie y Hellman habían creado el concepto de cifrado de clave pública, pero aún no habían ideado la función de cifrado unidireccional.

Fue Ron Rivest (R en RSA) quien creó el concepto que eventualmente se convirtió en el criptosistema RSA.

En muchos sentidos, RSA es el sucesor espiritual de DH. Realiza:

• generación de claves;
• intercambio de llaves;
• cifrado;
• descifrado.

Por lo tanto, RSA es un algoritmo más capaz que puede manejar tanto el intercambio de claves como las firmas digitales, es decir, autenticación además del intercambio seguro de claves. Por tanto, RSA tiene claves más grandes: se debe proporcionar suficiente seguridad para la firma digital.

Mientras que RSA maneja la autenticación y el intercambio de claves, Diffie-Hellman solo facilita el intercambio de claves. Hay cuatro variantes comunes de la familia DH:

• Diffie-Hellman (DH);
• efímero (a corto plazo) Diffie-Hellman (DHE);
• curva elíptica Diffie-Hellman (ECDH);
• Curva elíptica efímera Diffie-Hellman (ECDHE).

Una vez más, Diffie-Hellman por sí sola no autentica nada. Debe utilizarse junto con un algoritmo de firma digital. Entonces, por ejemplo, si usó ECDH o ECDHE, la mayoría de los conjuntos de cifrado se combinarán con el algoritmo de firma digital de curva elíptica (ECDSA) o RSA.

Autenticación en el protocolo de enlace TLS 1.2

Como se acaba de mencionar, la funcionalidad adicional de RSA para la autenticación mediante firmas digitales requiere claves grandes que sean resistentes a ataques de fuerza bruta. El tamaño de estas claves aumenta en gran medida el costo de computarlas, cifrarlas y descifrarlas durante un protocolo de enlace.

Por otro lado, si Diffie-Hellman no realiza autenticación, ¿qué hace? Como se mencionó anteriormente, DH se usa a menudo junto con la criptografía de curva elíptica para proporcionar autenticación e intercambio de claves.

La criptografía elíptica (ECC) tiene tamaños de clave mucho más pequeños que se ajustan a la curva elíptica en la que se basa. Hay cinco curvas adecuadas para este contexto:

• 192 bits;
• 224 bits;
• 256 bits;
• 384 bits;
• 521 bits.

Pero esa no es la única diferencia entre las claves públicas/privadas de ECC y las claves RSA. Se utilizan para dos propósitos completamente diferentes durante un protocolo de enlace TLS.

En RSA, el par de claves pública/privada se utiliza tanto para la autenticación del servidor como para el intercambio de claves de sesión simétrica. De hecho, es el uso exitoso del secreto previo al maestro lo que autentica el servidor.

Con Diffie-Hellman, el par de claves pública/privada NO se utiliza para intercambiar una clave de sesión simétrica. Cuando se trata de Diffie-Hellman, la clave privada en realidad está asociada con el algoritmo de firma que la acompaña (ECDSA o RSA).

autenticación RSA

El proceso de autenticación RSA está relacionado con el proceso de intercambio de claves. Más precisamente, el intercambio de claves es parte del proceso de autenticación.

Cuando a un cliente se le presenta el certificado SSL de un servidor, verifica varios indicadores:

• firma digital mediante clave pública;
• una cadena de certificados para garantizar que el certificado provenga de uno de los certificados raíz en el almacén de confianza;
• fecha de vencimiento para asegurar que no haya caducado;
• estado de revocación del certificado.

Si todas estas comprobaciones han pasado, se lleva a cabo la última prueba: el cliente cifra el secreto previo al maestro utilizando la clave pública del servidor y lo envía. Cualquier servidor puede intentar hacer pasar cualquier certificado SSL/TLS como propio. Al fin y al cabo, se trata de certificados públicos. Y así el cliente puede autenticar el servidor viendo la clave privada "en acción".

Por lo tanto, si el servidor puede descifrar el secreto previo al maestro y usarlo para calcular la clave de sesión, obtiene acceso. Esto verifica que el servidor sea el propietario del par de claves pública/privada que se está utilizando.

autenticación DH

Cuando se utilizan Diffie-Hellman y ECDSA/RSA, la autenticación y el intercambio de claves funcionan en paralelo. Y eso nos lleva nuevamente a las claves y sus usos. La clave pública/privada RSA se utiliza tanto para el intercambio de claves como para la autenticación. En DH+ECDSA/RSA, el par de claves asimétricas se utiliza sólo para la fase de firma digital o autenticación.

Cuando el cliente recibe el certificado, todavía realiza las comprobaciones estándar:

• verifica la firma en el certificado,
• cadena de certificados,
• validez,
• estado de revisión.

Pero la propiedad de una clave privada se verifica de manera diferente. Durante el intercambio de claves de protocolo de enlace TLS (paso 4), el servidor utiliza su clave privada para cifrar el número aleatorio del cliente y del servidor, así como su parámetro DH. Actúa como una firma digital para el servidor y el cliente puede utilizar la clave pública asociada para verificar que el servidor es el propietario legítimo del par de claves.

Autenticación en el protocolo de enlace TLS 1.3

En TLS 1.3, la autenticación y las firmas digitales siguen desempeñando un papel importante, pero se han eliminado de los conjuntos de cifrado para simplificar la negociación. Se implementan en el lado del servidor y utilizan varios algoritmos admitidos por el servidor debido a su seguridad y ubicuidad. TLS 1.3 permite tres algoritmos de firma principales:

• RSA (solo firma),
• Algoritmo de firma digital de curva elíptica (ECDSA),
• Algoritmo de firma digital de Edwards (EdDSA).

A diferencia del protocolo de enlace TLS 1.2, la parte de autenticación del protocolo de enlace TLS 1.3 no está asociada con el intercambio de claves en sí. Más bien, se procesa en paralelo con el intercambio de claves y la autenticación de mensajes.

En lugar de ejecutar un circuito MAC simétrico para verificar la integridad del protocolo de enlace, el servidor firma todo el hash de descifrado cuando devuelve un "Servidor Hola" con su parte de la clave compartida.

El cliente recibe toda la información transmitida desde el "Servidor Hola" y realiza una serie estándar de comprobaciones de autenticación de certificados SSL/TLS. Implica verificar la firma en el certificado y luego compararla con la firma que se agregó al hash de descifrado.

Una coincidencia confirma que el servidor posee la clave secreta.

Intercambio de claves en el protocolo de enlace TLS

Si resaltas la idea principal de esta sección, sonará así:

RSA facilita el intercambio de claves al permitir que el cliente cifre un secreto compartido y lo envíe al servidor, donde se utiliza para calcular la clave de sesión correspondiente. El intercambio de claves DH en realidad no requiere ningún intercambio de clave pública, sino que ambas partes crean una clave juntas.

Si esto suena un poco abstracto ahora, todo debería quedar más claro al final de esta sección.

Intercambio de claves RSA

Llamarlo intercambio de claves RSA es en realidad un nombre inapropiado. En realidad, esto es cifrado RSA. RSA utiliza cifrado asimétrico para crear la clave de sesión. A diferencia de DH, el par de claves pública/privada juega un papel importante.

Así es como sucede:

1. X Y y
2. El cliente genera secreto previo a la maestría(a) y luego utiliza la clave pública del servidor para cifrarla y enviarla al servidor.
3. El servidor descifra secreto previo a la maestría utilizando la clave privada correspondiente. Ahora ambos lados tienen las tres variables de entrada y las mezclan con algunas funciones pseudoaleatorias (PRF) para crear una clave maestra.
4. Ambas partes mezclan la clave maestra con aún más PRF y obtienen claves de sesión coincidentes.

Intercambio de claves DH

Así es como funciona ECDH:

1. El cliente y el servidor intercambian dos números primos ( X Y y), que se llaman números aleatorios.
2. Una de las partes elige un número secreto llamado secreto previo a la maestría(a), y calcula: x un mod y. Luego envía el resultado (A) al otro participante.
3. El otro lado hace lo mismo, eligiendo el suyo. secreto previo a la maestría(b) y calcula x b mod y y luego devuelve su valor (B).
4. Ambas partes completan esta parte aceptando los valores dados y repitiendo la operación. uno calcula b un mod y, el otro calcula a b mod y.

Hay una propiedad de módulo que dice que cada lado recibirá el mismo valor, que será la clave utilizada para el cifrado simétrico durante la conexión.

Apretón de manos TLS 1.2 para DH

Ahora que hemos aprendido en qué se diferencia DH de RSA, echemos un vistazo a cómo se ve un protocolo de enlace TLS 1.2 basado en DH.

Una vez más, existen muchas similitudes entre los dos enfoques. Usaremos ECDHE para el intercambio de claves y ECDSA para la autenticación.

1. Al igual que con RSA, el cliente comienza con un mensaje de "Cliente Hola", que incluye una lista de conjuntos de cifrado, así como el número aleatorio del cliente.
2. El servidor responde con su mensaje "Servidor Hola", que incluye el conjunto de cifrado seleccionado y el número aleatorio del servidor.
3. El servidor envía su certificado SSL. Al igual que con el protocolo de enlace RSA TLS, el cliente realizará una serie de comprobaciones de la autenticidad del certificado, pero como DH no puede autenticar el servidor, se necesita un mecanismo adicional.
4. Para realizar la autenticación, el servidor toma los números aleatorios del cliente y del servidor, así como el parámetro DH que se utilizará para calcular la clave de sesión, y los cifra con su clave privada. El resultado actuará como una firma digital: el cliente utilizará la clave pública para verificar la firma y que el servidor es el propietario legítimo del par de claves, y responderá con su propio parámetro DH.
5. El servidor finaliza esta fase con un mensaje "Servidor Hola, listo".
6. A diferencia de RSA, el cliente no necesita enviar el secreto pre-maestro al servidor mediante cifrado asimétrico; en cambio, el cliente y el servidor utilizan los parámetros DH que intercambiaron previamente para obtener el secreto pre-maestro; Luego, todos usan el secreto previo al maestro que acaban de calcular para obtener la misma clave de sesión.
7. El cliente envía un mensaje "Cambiar especificación de cifrado" para informar a la otra parte que está cambiando a cifrado.
8. El cliente envía un mensaje final "Finalizado" para indicar que ha completado su parte del protocolo de enlace.
9. Asimismo, el servidor envía un mensaje "Cambiar especificación de cifrado".
10. El apretón de manos finaliza con un mensaje "Finalizado" del servidor.

Ventajas de DHE sobre RSA

Hay dos razones principales por las que la comunidad de criptógrafos prefiere utilizar DHE en lugar de RSA: secreto directo perfecto y vulnerabilidades conocidas.

Secreto directo perfecto

Quizás te hayas preguntado anteriormente qué significa la palabra “efímero” al final de DHE y ECDHE. Efímero significa literalmente "de corta duración". Y esto puede ayudar a comprender el Perfect Forward Secrecy (PFS), que es una característica de algunos protocolos de intercambio de claves. PFS garantiza que las claves de sesión intercambiadas entre las partes no puedan verse comprometidas, incluso si la clave privada del certificado está comprometida. En otras palabras, protege las sesiones anteriores contra la extracción y el descifrado. A PFS se le dio máxima prioridad después de que se descubrió el error Heartbleed. Este es un componente central de TLS 1.3.

Vulnerabilidad del intercambio de claves RSA

Existen vulnerabilidades que pueden explotar el relleno ( relleno), utilizado durante el intercambio de claves en versiones anteriores de RSA (PKCS #1 1.5). Este es un aspecto del cifrado. Con RSA, el secreto previo al maestro debe cifrarse con la clave pública y descifrarse con la clave privada. Pero cuando este secreto previo al maestro más pequeño se coloca en una clave pública más grande, se debe rellenar. En la mayoría de los casos, si intenta adivinar el contenido y envía una solicitud falsa al servidor, se equivocará, reconocerá la discrepancia y la filtrará. Pero existe una buena posibilidad de que pueda enviar suficientes solicitudes al servidor para adivinar el llenado correcto. Luego, el servidor enviará un mensaje completo erróneo, lo que a su vez reducirá el posible valor del secreto previo al maestro. Esto permitirá que un atacante calcule y comprometa la clave.

Esta es la razón por la que se eliminó RSA en favor de DHE en TLS 1.3.

Intercambio de claves en el protocolo de enlace TLS 1.3

En un protocolo de enlace TLS 1.3, debido a la elección limitada de esquemas de intercambio de claves, un cliente puede adivinar con éxito el esquema y enviar su parte de la clave compartida durante la fase inicial (Cliente Hola) del protocolo de enlace.

RSA no fue el único esquema de intercambio de claves que se eliminó en TLS 1.3. También se eliminaron los esquemas Diffie-Hellman no efímeros, así como la lista de parámetros Diffie-Hellman insuficientemente seguros.

¿Qué quieres decir con configuraciones insuficientemente seguras? Sin entrar demasiado en matemáticas, la complejidad de Diffie-Hellman y la mayoría de los criptosistemas de clave pública es la complejidad de resolver problemas de logaritmos discretos. El criptosistema debe ser lo suficientemente complejo como para poder calcularlo si se desconocen los parámetros de entrada (números aleatorios de cliente y servidor); de lo contrario, todo el esquema será inútil. Los esquemas Diffie-Hellman, que no podían proporcionar parámetros suficientemente grandes, se eliminaron en TLS 1.3.

1. Al comienzo de un protocolo de enlace TLS 1.3, sabiendo que se utilizará el esquema de acuerdo de clave DHE, el cliente incluye su parte de la clave compartida según el esquema de intercambio de claves previsto en su mensaje "Cliente Hola".
2. El servidor recibe esta información y, si el cliente tiene razón, devuelve su parte de la clave pública en un "Servidor Hola".
3. El cliente y el servidor calculan la clave de sesión.

Esto es muy similar a lo que sucede con DH en un protocolo de enlace TLS 1.2, excepto que en TLS 1.3 el intercambio de claves ocurre antes.

En lugar de una conclusión

El protocolo de enlace SSL/TLS es un proceso fascinante que es clave para una Internet segura, pero ocurre con tanta rapidez y fluidez que la mayoría de la gente ni siquiera piensa en ello.

Al menos hasta que algo salga mal.

Al acceder a cualquier portal gubernamental o de servicios (por ejemplo, EIS), el usuario puede encontrar repentinamente el error “No es posible conectarse de forma segura a esta página. Es posible que el sitio esté utilizando configuraciones de seguridad TLS desactualizadas o débiles". Este problema es bastante común y se ha observado durante varios años entre varias categorías de usuarios. Veamos la esencia de este error y las opciones para solucionarlo.

Como usted sabe, la seguridad de las conexiones de los usuarios a los recursos de la red está garantizada mediante el uso de SSL/TSL, protocolos criptográficos responsables de la transmisión segura de datos en Internet. Utilizan cifrado simétrico y asimétrico, códigos de autenticación de mensajes y otras características especiales que le permiten mantener la confidencialidad de su conexión, evitando que terceros descifren su sesión.

Si, al conectarse a un sitio, el navegador detecta que el recurso utiliza parámetros de protocolo de seguridad SSL/TSL incorrectos, el usuario recibe el mensaje anterior y se puede bloquear el acceso al sitio.

Muy a menudo, la situación con el protocolo TLS surge en el navegador IE, una herramienta popular para trabajar con portales gubernamentales especiales asociados con diversas formas de informes. Trabajar con este tipo de portales requiere la presencia del navegador Internet Explorer, y es en él donde surge con especial frecuencia el problema en cuestión.

Los motivos del error "El sitio puede estar utilizando configuraciones de seguridad TLS obsoletas o inseguras" pueden ser las siguientes:

Cómo solucionar la disfunción: se están utilizando configuraciones de seguridad TLS débiles

La solución al problema pueden ser los métodos que se describen a continuación. Pero antes de describirlos, le recomiendo que simplemente reinicie su PC; aunque este método es trivial, a menudo resulta bastante efectivo.

Si no ayuda, haga lo siguiente:

• Desactiva temporalmente tu antivirus. En bastantes casos, el antivirus bloqueó el acceso a sitios no fiables (según su evaluación). Deshabilite temporalmente el programa antivirus o deshabilite la verificación de certificados en la configuración del antivirus (por ejemplo, "No verificar conexiones seguras" en el antivirus Kaspersky);
• Instale la última versión del programa CryptoPro en su computadora (en caso de haber trabajado previamente con este programa). Una versión desactualizada del producto puede causar un error que indica que la página no está conectada de forma segura;
• Cambia la configuración de IE. Vaya a "Opciones del navegador", seleccione la pestaña "Seguridad", luego haga clic en "Sitios de confianza" (la dirección de su portal ya debería estar ingresada allí, si no, ingrésela). En la parte inferior, desmarque la opción "Habilitar modo protegido".

  

  Luego haga clic en el botón "Sitios" de arriba y desmarque la opción "Para todos los sitios en esta zona...". Haga clic en "Aceptar" e intente ir al sitio problemático.

• Eliminar las cookies del navegador IE. Inicie el navegador y presione el botón Alt para mostrar el menú. Seleccione la pestaña "Herramientas" - "Eliminar el historial del navegador", marque la casilla (si no está presente) en la opción "Cookies...", luego haga clic en "Eliminar";

  

• Deshabilite el uso de programas VPN (si los hay);
• Intente utilizar un navegador diferente para navegar hasta el recurso problemático (en caso de que no sea necesario utilizar ningún navegador específico);
• Revise su PC en busca de virus (por ejemplo, el probado Doctor Web Curate le ayudará);
• Deshabilite la opción "Arranque seguro" en el BIOS. A pesar del cierto carácter no estándar de este consejo, ha ayudado a más de un usuario a deshacerse del error de “parámetros TLS obsoletos o poco confiables”.

  

  Desactive la opción “Arranque seguro” en la BIOS

Conclusión

La causa del error "El sitio puede estar utilizando parámetros de seguridad del protocolo TLS obsoletos o poco fiables" suele ser un antivirus de PC local que, por determinadas razones, bloquea el acceso al portal de Internet deseado. Si surge una situación problemática, se recomienda que primero desactive su antivirus para asegurarse de que no esté causando el problema en cuestión. Si el error continúa reapareciendo, le recomiendo seguir implementando otros consejos que se describen a continuación para resolver el problema de la configuración de seguridad del protocolo TSL poco confiable en su PC.

En contacto con

Si tiene un problema en el que falla el acceso a un sitio específico y aparece un mensaje en su navegador, existe una explicación razonable para ello. Las causas y soluciones al problema se darán en este artículo.

SSL-TLS

Protocolo SSL TLS

Los usuarios de organizaciones presupuestarias, y no solo presupuestarias, cuyas actividades están directamente relacionadas con las finanzas, en interacción con organizaciones financieras, por ejemplo, el Ministerio de Finanzas, Hacienda, etc., realizan todas sus operaciones utilizando exclusivamente el protocolo SSL seguro. Básicamente, utilizan el navegador Internet Explorer en su trabajo. En algunos casos, Mozilla Firefox.

Error SSL

La principal atención a la hora de realizar estas operaciones, y el trabajo en general, se presta al sistema de seguridad: certificados, firmas electrónicas. Para el funcionamiento se utiliza la versión actual del software CryptoPro. Sobre problemas con los protocolos SSL y TLS, Si Error de SSL apareció, lo más probable es que no haya soporte para este protocolo.

error TLS

error TLS en muchos casos también puede indicar una falta de soporte de protocolo. Pero… veamos qué se puede hacer en este caso.

Soporte de protocolo SSL y TLS

Entonces, cuando usa Microsoft Internet Explorer para visitar un sitio web seguro con SSL, la barra de título muestra Asegúrese de que los protocolos ssl y tls estén habilitados. En primer lugar, debe habilitar la compatibilidad con el protocolo TLS 1.0 en Internet Explorer.

Si está visitando un sitio web que ejecuta Internet Information Services 4.0 o superior, configurar Internet Explorer para que admita TLS 1.0 ayuda a proteger su conexión. Por supuesto, siempre que el servidor web remoto que esté intentando utilizar admita este protocolo.

Para hacer esto en el menú Servicio selecciona un equipo opciones de Internet.

en la pestaña Además en el capitulo Seguridad, asegúrese de que las siguientes casillas de verificación estén seleccionadas:

Utilice SSL 2.0
Utilice SSL 3.0
Utilice TLS 1.0

Clic en el botón Aplicar , y luego DE ACUERDO . Reinicia tu navegador .

Después de habilitar TLS 1.0, intente visitar el sitio web nuevamente.

Política de seguridad del sistema

Si todavía ocurren errores con SSL y TLS Si aún no puede utilizar SSL, es probable que el servidor web remoto no admita TLS 1.0. En este caso, debe deshabilitar la política del sistema que requiere algoritmos compatibles con FIPS.

Para hacer esto, en Paneles de control seleccionar Administración y luego haga doble clic política de seguridad local.

En Configuración de seguridad local, expanda Políticas locales y luego haga clic en el botón Configuraciones de seguridad.

De acuerdo con la política en el lado derecho de la ventana, haga doble clic Criptografía del sistema: utilice algoritmos compatibles con FIPS para cifrado, hash y firma y luego haga clic en el botón Desactivado.

¡Atención! El cambio entra en vigor después de que se vuelva a aplicar la política de seguridad local. Eso es encenderlo Y reinicia tu navegador .

CryptoPro TLS SSL

Actualizar CryptoPro

Configurar SSL TLS

Configuración de la red

Otra opción podría ser deshabilitar NetBIOS sobre TCP/IP— ubicado en las propiedades de conexión.

registro de DLL

Inicie el símbolo del sistema como administrador e ingrese el comando regsvr32 cpcng. Para un sistema operativo de 64 bits, debe utilizar el mismo regsvr32 que está en syswow64.