Utilice este protocolo tls que lo permita. Cadena de acciones para la generación de certificados. Comparación con análogos.

Capítulos del maravilloso libro "Redes de navegador de alto rendimiento" de Ilya Grigorik. La traducción se realizó como parte de la redacción de un trabajo de curso, por lo que es muy gratuita, pero sin embargo será útil para aquellos que tienen poca idea de qué es TLS y para qué se utiliza.

Entendiendo TLS

El protocolo TLS (seguridad de la capa de transporte) se basa en el protocolo SSL (Secure Sockets Layer), desarrollado originalmente por Netscape para mejorar la seguridad del comercio electrónico en línea. El protocolo SSL se implementó en la capa de aplicación, directamente encima de TCP (Protocolo de control de transmisión), lo que permite que los protocolos de nivel superior (como HTTP o el protocolo de correo electrónico) funcionen sin modificaciones. Si SSL está configurado correctamente, un observador externo sólo puede conocer los parámetros de conexión (por ejemplo, el tipo de cifrado utilizado), así como la frecuencia de las transferencias y la cantidad aproximada de datos, pero no puede leerlos ni cambiarlos.

El lugar específico de TLS (SSL) en la pila de protocolos de Internet se muestra en el diagrama:

Después de que el protocolo SSL fuera estandarizado por el IETF (Internet Engineering Task Force), pasó a llamarse TLS. Por lo tanto, aunque los nombres SSL y TLS se usan indistintamente, siguen siendo diferentes porque cada uno describe una versión diferente del protocolo.

La primera versión del protocolo publicada se llamó SSL 2.0, pero fue rápidamente reemplazada por SSL 3.0 debido a vulnerabilidades descubiertas. Como se mencionó, SSL fue desarrollado por Netscape, por lo que en enero de 1999 el IETF lo estandarizó abiertamente bajo el nombre TLS 1.0. Luego, en abril de 2006, se publicó TLS 1.1, que amplió las capacidades originales del protocolo y cerró las vulnerabilidades conocidas. La versión actual del protocolo en este momento es TLS 1.2, lanzada en agosto de 2008.

Como se mencionó, TLS fue diseñado para funcionar sobre TCP, pero para trabajar con protocolos de datagramas como UDP (User Datagram Protocol), se desarrolló una versión especial de TLS llamada DTLS (Datagram Transport Layer Security).
 

Cifrado, autenticación e integridad

El protocolo TLS está diseñado para proporcionar tres servicios a todas las aplicaciones que se ejecutan en él: cifrado, autenticación e integridad. Técnicamente no se pueden utilizar los tres, pero en la práctica, para garantizar la seguridad, se suelen utilizar los tres:

• Cifrado: ocultar información transmitida de una computadora a otra;
• Autenticación: comprobar la autoría de la información transmitida;
• Integridad: detección de sustitución de información por información falsificada.

Para establecer un canal de datos criptográficamente seguro, los nodos conectados deben acordar los métodos de cifrado y las claves que se utilizarán. El protocolo TLS define claramente este procedimiento; esto se analiza con más detalle en el párrafo TLS Handshake. Cabe señalar que TLS utiliza criptografía de clave pública, que permite a los nodos establecer una clave de cifrado secreta compartida sin ningún conocimiento previo entre sí.

Además, como parte del procedimiento TLS Handshake, es posible autenticar la identidad tanto del cliente como del servidor. Por ejemplo, un cliente puede estar seguro de que el servidor que le proporciona la información de su cuenta bancaria es efectivamente un servidor bancario. Y viceversa: el servidor de la empresa puede estar seguro de que el cliente que se conecta a él es un empleado de la empresa y no un tercero (este mecanismo se llama Cadena de Confianza y se analizará en la sección correspondiente).

Finalmente, TLS garantiza que cada mensaje se envíe con un código MAC (Message Authentication Code), cuyo algoritmo de creación es una función hash criptográfica unidireccional (en realidad, una suma de verificación), cuyas claves son conocidas por ambos participantes en la comunicación. . Cada vez que se envía un mensaje se genera su valor MAC, el cual también puede ser generado por el receptor, esto asegura la integridad de la información y protección contra su sustitución.

Por lo tanto, se revisan brevemente los tres mecanismos subyacentes a la criptoseguridad del protocolo TLS.
 

Apretón de manos TLS

Antes de iniciar el intercambio de datos a través de TLS, el cliente y el servidor deben acordar los parámetros de conexión, a saber: la versión del protocolo utilizado, el método de cifrado de datos y también verificar los certificados, si es necesario. El esquema de inicio de conexión se llama TLS Handshake y se muestra en la figura:

Echemos un vistazo más de cerca a cada paso de este procedimiento:

1. Dado que TLS funciona sobre TCP, primero se establece una conexión TCP entre el cliente y el servidor.
2. Después de instalar TCP, el cliente envía la especificación en texto plano (es decir, la versión del protocolo que desea utilizar, los métodos de cifrado admitidos, etc.) al servidor.
3. El servidor aprueba la versión del protocolo utilizado, selecciona un método de cifrado de la lista proporcionada, adjunta su certificado y envía una respuesta al cliente (si lo desea, el servidor también puede solicitar un certificado de cliente).
4. La versión del protocolo y el método de cifrado se consideran aprobados en este punto, el cliente verifica el certificado enviado e inicia el intercambio de claves RSA o Diffie-Hellman, según los parámetros establecidos.
5. El servidor procesa el mensaje enviado por el cliente, verifica la MAC y envía el mensaje final ("Terminado") al cliente en forma cifrada.
6. El cliente descifra el mensaje recibido, verifica la MAC y, si todo está bien, la conexión se considera establecida y comienza el intercambio de datos de la aplicación.

Está claro que establecer una conexión TLS es, en general, un proceso que requiere mucho tiempo y mano de obra, por lo que existen varias optimizaciones en el estándar TLS. En particular, existe un procedimiento llamado "apretón de manos abreviado", que le permite utilizar parámetros previamente acordados para restaurar la conexión (por supuesto, si el cliente y el servidor han establecido una conexión TLS en el pasado). Este procedimiento se analiza con más detalle en la sección "Reanudar una sesión".

También hay una extensión adicional al procedimiento Handshake llamada TLS False Start. Esta extensión permite que el cliente y el servidor comiencen a intercambiar datos cifrados tan pronto como se establezca el método de cifrado, lo que reduce el establecimiento de la conexión en una iteración de mensaje. Esto se analiza con más detalle en el párrafo "Inicio en falso de TLS".
 

Intercambio de claves en el protocolo TLS

Por diversas razones históricas y comerciales, el intercambio de claves más utilizado en TLS es RSA: el cliente genera una clave simétrica, la firma con la clave pública del servidor y la envía al servidor. A su vez, en el servidor, la clave del cliente se descifra utilizando la clave privada. Después de esto, el intercambio de claves se declara completo. Este algoritmo tiene un inconveniente: también se utiliza el mismo par de claves públicas y privadas para la autenticación del servidor. En consecuencia, si un atacante obtiene acceso a la clave privada del servidor, puede descifrar toda la sesión de comunicación. Además, un atacante puede simplemente grabar toda la sesión de comunicación en una versión cifrada y descifrarla más tarde, cuando consiga obtener la clave privada del servidor. Al mismo tiempo, el intercambio de claves Diffie-Hellman parece ser más seguro, ya que la clave simétrica establecida nunca sale del cliente o del servidor y, en consecuencia, no puede ser interceptada por un atacante, incluso si conoce la clave privada del servidor. El servicio para reducir el riesgo de comprometer sesiones de comunicación pasadas se basa en esto: para cada nueva sesión de comunicación se crea una nueva clave simétrica, llamada "temporal". En consecuencia, incluso en el peor de los casos (si el atacante conoce la clave privada del servidor), el atacante sólo puede obtener claves de sesiones futuras, pero no descifrar las registradas previamente.

Actualmente, al establecer una conexión TLS, todos los navegadores prefieren una combinación del algoritmo Diffie-Hellman y el uso de claves temporales para aumentar la seguridad de la conexión.

Cabe señalar nuevamente que el cifrado de clave pública solo se utiliza en el procedimiento de protocolo de enlace TLS durante la configuración de la conexión inicial. Después de configurar el túnel, entra en juego la criptografía simétrica y la comunicación dentro de la sesión actual se cifra con las claves simétricas establecidas. Esto es necesario para aumentar el rendimiento, ya que la criptografía de clave pública requiere una potencia informática significativamente mayor.
 

Reanudar una sesión TLS

Como se señaló anteriormente, el procedimiento completo de protocolo de enlace TLS es bastante largo y costoso desde el punto de vista computacional. Por ello, se ha desarrollado un procedimiento que permite retomar una conexión previamente interrumpida en base a los datos ya configurados.

Desde la primera versión pública del protocolo (SSL 2.0), un servidor puede generar y enviar un identificador de sesión de 32 bytes como parte de un protocolo de enlace TLS (es decir, el mensaje inicial ServerHello). Naturalmente, en este caso, el servidor almacena un caché de identificadores generados y parámetros de sesión para cada cliente. A su vez, el cliente almacena el identificador enviado y lo incluye (por supuesto, si existe) en el mensaje ClientHello inicial. Si tanto el cliente como el servidor tienen identificadores de sesión idénticos, entonces se establece una conexión común según el algoritmo simplificado que se muestra en la figura. De lo contrario, se requiere la versión completa de TLS Handshake.

El procedimiento de reanudación de la sesión le permite omitir la etapa de generación de una clave simétrica, lo que aumenta significativamente el tiempo de configuración de la conexión, pero no afecta su seguridad, ya que se utilizan datos de la sesión anterior que no estaban comprometidos anteriormente.

Sin embargo, existe una limitación práctica: dado que el servidor debe almacenar datos sobre todas las sesiones abiertas, esto genera un problema con los recursos populares que son solicitados simultáneamente por miles o millones de clientes.

Para evitar este problema, se desarrolló el mecanismo "Ticket de sesión", que elimina la necesidad de almacenar los datos de cada cliente en el servidor. Si el cliente indicó durante la conexión inicial que admite esta tecnología, durante el protocolo de enlace TLS el cliente envía el llamado ticket de sesión (parámetros de sesión cifrados con la clave privada del servidor) al servidor. La próxima vez que se reanude la sesión, el cliente envía su ticket de sesión existente junto con ClientHello. Esto elimina la necesidad de que el servidor almacene datos sobre cada conexión, pero la conexión sigue siendo segura porque el ticket de sesión está cifrado con una clave que sólo conoce el servidor.
 

Inicio en falso de TLS

La tecnología de reanudación de sesión sin duda mejora el rendimiento del protocolo y reduce los costos computacionales, pero no es aplicable en la conexión inicial al servidor, o en el caso de que la sesión anterior ya haya expirado.

Para obtener un rendimiento aún mayor, se desarrolló la tecnología TLS False Start, que es una extensión opcional del protocolo y permite enviar datos cuando el TLS Handshake se completa solo parcialmente. El esquema detallado de inicio en falso de TLS se muestra en la figura:

Es importante tener en cuenta que TLS False Start no cambia el procedimiento de TLS Handshake de ninguna manera. Se basa en el supuesto de que en el momento en que el cliente y el servidor ya conocen los parámetros de conexión y las claves simétricas, ya se pueden enviar los datos de la aplicación y se pueden realizar todas las comprobaciones necesarias en paralelo. Como resultado, la conexión está lista para usarse una iteración de mensajería antes.
 

Cadena de confianza TLS

La autenticación es una parte integral de cada conexión TLS. Veamos el proceso de autenticación más simple entre Alice y Bob:

1. Tanto Alice como Bob generan sus propias claves públicas y privadas.
2. Alice y Bob intercambian claves públicas.
3. Alice genera un mensaje, lo cifra con su clave privada y se lo envía a Bob.
4. Bob utiliza la clave recibida de Alice para descifrar el mensaje y así verificar la autenticidad del mensaje recibido.

Obviamente, este plan se basa en la confianza entre Alice y Bob. Se supone que el intercambio de claves públicas tuvo lugar, por ejemplo, en una reunión personal y, por lo tanto, Alice confía en haber recibido la clave directamente de Bob, y Bob, a su vez, confía en haber recibido la clave pública de Alice.

Deje que Alice reciba ahora un mensaje de Charlie, a quien no conoce, pero que dice ser amigo de Bob. Para demostrarlo, Charlie ha pedido por adelantado firmar su propia clave pública con la clave privada de Bob y adjunta esta firma al mensaje dirigido a Alice. Alice primero verifica la firma de Bob en la clave de Charlie (puede hacerlo porque ya conoce la clave pública de Bob), se asegura de que Charlie sea realmente amigo de Bob, acepta su mensaje y realiza la verificación de integridad ya conocida, asegurándose de que el mensaje es realmente de Charlie:

Lo que se describe en el párrafo anterior es la creación de una “cadena de confianza” (o “Chain of trust”, en inglés).
En el protocolo TLS, estas cadenas de confianza se basan en certificados de autenticidad proporcionados por autoridades especiales llamadas autoridades certificadoras (CA). Las autoridades de certificación realizan comprobaciones y, si el certificado emitido se ve comprometido, el certificado se revoca.

La cadena de confianza ya comentada se forma a partir de los certificados emitidos. Su raíz es el llamado "certificado CA raíz", un certificado firmado por un gran centro, cuya credibilidad es innegable. En general, la cadena de confianza se parece a esto:

Naturalmente, surgen casos en los que es necesario revocar o revocar un certificado ya emitido (por ejemplo, la clave privada de un certificado se ha visto comprometida o todo el procedimiento de certificación se ha visto comprometido). Para lograrlo, los certificados de autenticidad contienen instrucciones especiales para garantizar que estén actualizados. Por tanto, al construir una cadena de confianza, es necesario comprobar la relevancia de cada nodo de confianza.

El mecanismo de esta verificación es simple y se basa en el llamado. “Lista de Certificados Revocados” (CRL – “Lista de Certificados Revocados”). Cada CA tiene esta lista, que es una lista simple de números de serie de certificados revocados. En consecuencia, cualquiera que quiera verificar la autenticidad de un certificado simplemente descarga esta lista y busca en ella el número del certificado que se está verificando. Si se encuentra el número, significa que el certificado ha sido revocado.

Obviamente hay algo de irracionalidad técnica en esto: para verificar un solo certificado, es necesario solicitar la lista completa de certificados de revocación, lo que ralentiza el trabajo. Para combatir esto, se desarrolló un mecanismo llamado Protocolo de estado de certificados en línea (OCSP). Le permite verificar el estado del certificado de forma dinámica. Naturalmente, esto reduce la carga en el ancho de banda de la red, pero al mismo tiempo crea varios problemas:

• Las CA deben manejar la carga en tiempo real;
• Las AC deben garantizar su disponibilidad en todo momento;
• Gracias a consultas en tiempo real, las autoridades certificadoras reciben información sobre qué sitios ha visitado cada usuario específico.

De hecho, en todos los navegadores modernos, ambas soluciones (OCSP y CRL) se complementan y, por regla general, es posible configurar la política preferida para comprobar el estado del certificado.

Por lo tanto, este artículo analiza todas las características clave que proporciona el protocolo TLS para proteger la información. Pido disculpas por algunas bromas en el artículo; estos son los costos del propósito original de realizar la traducción.

La sesión SMTP entre el servidor y el cliente no está cifrada de forma predeterminada. Esto permite interceptar paquetes y obtener información confidencial transmitida en texto claro (a menos que se utilicen otros métodos de cifrado).

Utilizar el protocolo TLS nos ayudará a corregir esta situación, lo que garantizará:

1. Confidencialidad (La interacción entre el cliente y el servidor se produce en formato cifrado
sesión);

2. Integridad (es imposible infiltrarse en una sesión sin ser detectado; la corrupción de datos se detectará inmediatamente);

3. Confianza en la autenticación (El cliente y el servidor pueden intercambiar certificados certificados por una Autoridad de Certificación (CA).

Cómo funciona TLS

El protocolo TLS sólo cifra la conexión entre dos hosts. Una sesión que utiliza este protocolo se desarrolla de la siguiente manera:

1. El cliente establece una conexión con el servidor.

2. Los hosts inician la comunicación utilizando el protocolo SMTP.

3. El servidor, utilizando la palabra clave STARTTLS, sugiere utilizar TLS dentro de las interacciones SMTP.

4. Si el cliente puede usar TLS, responde al servidor con la palabra clave STARTTLS.

5. El certificado público del servidor se firma con la clave privada y se envía al cliente.

6. El cliente verifica la autenticidad del certificado del servidor comprobando la firma de la autoridad de certificación con la firma pública de la autoridad de certificación que tiene en el almacén raíz.

7. El cliente compara el certificado del servidor con la cadena que contiene. Nombre común nombre de dominio del servidor.

8. El cliente y el servidor habilitan el modo de cifrado de datos.

9. Los anfitriones intercambian datos.

10. Finaliza la sesión.

Comencemos a crear certificados para el servidor de correo. servidor.midominio.ru , en el que Postfix actúa como MTA y Dovecot desempeña el papel de MDA.

Crear un nuevo certificado es fácil: simplemente ejecute el script y algunos comandos.

Generemos 2 archivos: la clave secreta del servidor y una solicitud de firma de certificado con el comando:

# openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr

donde servidor es el nombre del servidor (en este caso puede ser cualquier cosa)

Complete los campos (al presionar “Enter” sale el valor predeterminado):

Nombre del país (código de 2 letras): RU
Nombre del Estado o Provincia (nombre completo): Oremburgo
Nombre de la localidad (por ejemplo, ciudad): Orsk
Nombre de la organización (p. ej., empresa): Mi empresa
Nombre de la unidad organizativa (p. ej., sección): ÉL
Nombre común (p. ej., SU nombre): servidor.midominio.ru
Dirección de correo electrónico: administrador de correo @ midominio.ru
Una contraseña reto:
Un nombre de empresa opcional:

Es muy importante indicar en el campo Nombre común nombre de host completo (FQDN) correspondiente a los registros DNS de tipos MX y A

Aprovechamos la oportunidad para obtener certificados COMODO gratuitos con un período de validez de 90 días en el servicio FreeSSL.su. Estos certificados son fácilmente reconocidos por todos los navegadores y clientes de correo electrónico.

En la página principal, complete todos los campos obligatorios, en la columna "Seleccione el software a usar", seleccione "Otro". en el campo RSE ingrese el contenido del archivo generado previamente servidor.csr .

Después de enviar la solicitud y confirmarla, recibimos un archivo. certificados.zip , que contiene los siguientes archivos:

1. AddTrustExternalCARoot.crt;
2. server_mydomain_ru.crt;
3. ComodoUTNSGCCA.crt;
4. EsencialSSLCA_2.crt;
5. UTNAddTrustSGCCA.crt

El archivo server_mydomain_ru.crt es el certificado requerido. ¿Qué debemos hacer con los archivos restantes? Hagamos esto: combinemos sus contenidos en un solo archivo. ca.txt (certificado de CA confiable CALIFORNIA. ) en el siguiente orden:

1. EsencialSSLCA_2.crt
2. ComodoUTNSGCCA.crt
3. UTNAddTrustSGCCA.crt
4. AddTrustExternalCARoot.crt

Archivo recibido ca.txt Usaremos más:

Configuremos nuestro servidor de correo. Para hacer esto, hacemos cambios en las configuraciones. palomar Y sufijo .

Para palomar:

palomar.conf:

protocolos = pop3 imap imaps pop3s

protocolo pop3 (
escuchar = *:110
ssl_listen = *:995
...........
}

imagen de protocolo (
escuchar = *: 143
ssl_listen = *:993
...........
}

enable_plaintext_auth = no # No prohibimos el inicio de sesión de forma abierta
ssl = sí # Habilitar soporte SSL
ssl_cert_file = /etc/ssl/certs/dovecot.pem # archivo de certificado,
# establecer permisos en él: root:root 0444
ssl_key_file = /etc/ssl/private/dovecot.pem # clave del servidor,
# se recomienda establecer permisos: root:root 0400

ssl_verify_client_cert = yes # comprobar la validez de los certificados del cliente
ssl_parameters_regenerate = 1 # regenerar parámetros cada hora
# (el valor "0" desactiva la regeneración)
ssl_cipher_list = TODOS:!BAJO:!SSLv2 # cifrado SSL
verbose_ssl = sí # registrar errores de ssl

Para obtener archivo_cert_ssl necesitas fusionar el contenido de los archivos servidor_midominio_en.crt Y ca.txt , cambie el nombre del archivo resultante a dovecot.pem. en el papel archivo_clave_ssl aparece el archivo de clave secreta del servidor renombrado servidor.clave , generado anteriormente.

Para sufijo:

principal.cf

Smtp_use_tls = yes # use TLS si el servidor remoto informa soporte TLS
smtpd_use_tls = yes # informar a los clientes sobre la compatibilidad con TLS
smtpd_tls_auth_only = no # usar autenticación SMTP para algo más que conexiones TLS
smtp_tls_note_starttls_offer = yes # registrar nombres de servidores,
# emitir un mensaje STARTTLS para el cual la compatibilidad con TLS no está habilitada

smtpd_tls_CAfile = /etc/ssl/ca.txt # certificado confiable
smtpd_tls_key_file = /etc/ssl/smtpd.key # clave privada del servidor
smtpd_tls_cert_file = /etc/ssl/smtpd.crt # certificado de servidor

smtpd_tls_loglevel = 2 # detalle de los mensajes de actividad TLS
smtpd_tls_received_header = yes # solicitar encabezados de mensajes con información
# sobre la versión del protocolo y el algoritmo de cifrado
smtpd_tls_session_cache_timeout = 3600s # tiempo que los datos se almacenan en caché
# sesiones TLS se consideran actuales
tls_random_source = dev:/dev/urandom # nombre del dispositivo generador de números pseudoaleatorios (PRNG)

Para que Postfix acepte conexiones TLS en un puerto especial (465/SMTPS, no 25/SMTP), en el archivo maestro.cf necesitas descomentar las líneas:

maestro.cf

Smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=sí
-o smtpd_sasl_auth_enable=sí
-o smtpd_client_restrictions=permit_sasl_authenticated,rechazar

Reinicie postfix y dovecot, verifique los registros.

No olvides abrir los puertos necesarios en el firewall: 993 (imaps), 995 (pop3s), 465 (smtps)

Nuestro servidor de correo está listo para trabajar. TLS !

Para que los clientes de correo electrónico utilicen correctamente las nuevas capacidades del servidor, debe configurar la configuración del protocolo en FQDN servidor, como se especificó durante la clave y la solicitud, y seleccione el tipo de seguridad de conexión SSL/TLS y relevante puertos.

Al finalizar el período de validez de 90 días de los certificados, deberá seguir el mismo procedimiento utilizando el mismo expediente para solicitar servidor.csr , por lo que deberás guardar una copia en un lugar seguro. ¡Todo el proceso de actualización no te llevará más de 10 minutos!

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:

• Distribución de CryptoPro CSP
• Un paquete de instrucciones para instalar y usar CryptoPro CSP

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 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.

Nota. Los sitios pueden requerir la instalación de certificados. Las instrucciones para instalar certificados generalmente se encuentran en los sitios que los solicitan.

Habilitar y deshabilitar la compatibilidad con el navegador CryptoPro CSP

De forma predeterminada, el navegador admite CryptoPro CSP. Recomendamos comprobar esto.

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:

• Distribución de CryptoPro CSP
• Un paquete de instrucciones para instalar y usar CryptoPro CSP

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 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.

Nota. Los sitios pueden requerir la instalación de certificados. Las instrucciones para instalar certificados generalmente se encuentran en los sitios que los solicitan.

Habilitar y deshabilitar la compatibilidad con el navegador CryptoPro CSP

De forma predeterminada, el navegador admite CryptoPro CSP. Recomendamos comprobar esto.

Todos nuestros argumentos se basan en el hecho de que el sistema operativo es Windows XP o posterior (Vista, 7 u 8), en el que están instaladas todas las actualizaciones y parches adecuados. Ahora hay una condición más: estamos hablando de las últimas versiones de navegadores, y no de "Ognelis esféricos en el vacío".

Por lo tanto, configuramos los navegadores para que utilicen las últimas versiones del protocolo TLS y no utilicen sus versiones obsoletas ni SSL en absoluto. Al menos, en la medida de lo posible en teoría.

Y la teoría nos dice que aunque Internet Explorer ya soporta TLS 1.1 y 1.2 desde la versión 8, en Windows XP y Vista no lo forzaremos a hacerlo. Haga clic en: Herramientas/Opciones de Internet/Avanzado y en la sección “Seguridad” encontramos: SSL 2.0, SSL 3.0, TLS 1.0… ¿encontraste algo más? ¡Felicitaciones, tendrá TLS 1.1/1.2! Si no lo encontraron, tienes Windows XP o Vista, y en Redmond te consideran retrasado.

Entonces, desmarque todas las casillas SSL, marque todas las casillas TLS disponibles. Si solo está disponible TLS 1.0, que así sea; si hay versiones más actuales disponibles, es mejor seleccionarlas solo y desmarcar TLS 1.0 (y no sorprenderse más adelante de que algunos sitios no se abran a través de HTTPS). Luego haga clic en los botones "Aplicar" y "Aceptar".

Es más fácil con Opera: nos ofrece un verdadero banquete de diferentes versiones de protocolo: Herramientas/Configuración general/Avanzado/Seguridad/Protocolo de seguridad. ¿Qué vemos? El conjunto completo, del que dejamos las casillas de verificación solo para TLS 1.1 y TLS 1.2, luego de lo cual hacemos clic en el botón "Detalles" y allí desmarcamos todas las líneas excepto las que comienzan con "AES de 256 bits" - están en el mismo fin. Al principio de la lista hay una línea "AES de 256 bits ( Anónimo DH/SHA-256), desmárquelo también. Haga clic en "Aceptar" y disfrute de la seguridad.

Sin embargo, Opera tiene una propiedad extraña: si TLS 1.0 está habilitado, si es necesario establecer una conexión segura, inmediatamente utiliza esta versión del protocolo, independientemente de si el sitio admite versiones más actuales. ¿Para qué molestarse? Todo está bien, todo está protegido. Cuando solo están habilitados TLS 1.1 y 1.2, se intentará primero la versión más avanzada y solo si el sitio no la admite, el navegador cambiará a la versión 1.1.

Pero el esférico Ognelis Firefox no nos agradará en absoluto: Herramientas/Configuración/Avanzado/Cifrado: todo lo que podemos hacer es desactivar SSL, TLS está disponible sólo en la versión 1.0, no hay nada que hacer, lo dejamos con una marca de verificación.

Sin embargo, lo peor se aprende en comparación: Chrome y Safari no contienen ninguna configuración sobre qué protocolo de cifrado utilizar. Hasta donde sabemos, Safari no admite versiones TLS superiores a 1.0 en las versiones para el sistema operativo Windows y, dado que se suspendió el lanzamiento de nuevas versiones para este sistema operativo, no lo será.

Chrome, hasta donde sabemos, es compatible con TLS 1.1, pero, como en el caso de Safari, no podemos rechazar el uso de SSL. No hay forma de desactivar TLS 1.0 en Chrome. Pero con el uso real de TLS 1.1 surge una gran pregunta: primero se encendió, luego se apagó debido a problemas operativos y, hasta donde se puede juzgar, aún no se ha vuelto a encender. Es decir, parece haber soporte, pero parece estar desactivado y no hay forma de que el usuario vuelva a activarlo. Lo mismo ocurre con Firefox: en realidad es compatible con TLS 1.1, pero aún no está disponible para el usuario.

Resumen de la multiletra anterior. ¿Cuáles son los peligros generales de utilizar versiones obsoletas de protocolos de cifrado? El hecho de que otra persona acceda a su conexión segura al sitio y obtenga acceso a toda la información "allí" y "allí". En términos prácticos, obtendrá acceso completo a su casilla de correo electrónico, cuenta en el sistema del banco cliente, etc.

Es poco probable que puedas acceder accidentalmente a la conexión segura de otra persona; solo estamos hablando de acciones maliciosas. Si la probabilidad de que se produzcan tales acciones es baja, o la información transmitida a través de una conexión segura no es particularmente valiosa, entonces no tiene que molestarse y utilizar navegadores que solo admitan TLS 1.0.

De lo contrario, no hay elección: sólo Opera y sólo TLS 1.2 (TLS 1.1 es sólo una mejora de TLS 1.0, heredando parcialmente sus problemas de seguridad). Sin embargo, es posible que nuestros sitios favoritos no sean compatibles con TLS 1.2 :(