Visión general
OpenSSL es una potente biblioteca criptográfica de capa de conexión segura, que incluye los principales algoritmos criptográficos, las funciones de gestión de paquetes de certificados y claves de uso común y el protocolo SSL, y proporciona una gran cantidad de aplicaciones para pruebas u otros fines.
Este artículo explica principalmente cómo configurar SSL más fuerte en el servidor web nginx. No use SSLv3 y las siguientes versiones, que son vulnerables en el protocolo SSL / TLS, y configure un conjunto de cifrado más fuerte y habilite HSTS y HPKP al mismo tiempo, para lograr el secreto directo cuando sea posible.
Sitio web de verificación de prueba de seguridad SSL: https://www.ssllabs.com/ssltest/
Descripción de los archivos de configuración y las opciones de seguridad correspondientes
1) La ubicación del archivo de configuración, el puerto ssl predeterminado es 443, que se puede modificar según sea necesario en la práctica:
Ubuntu / Debian: /etc/nginx/sited-enabled/yoursite.com
RHEL / CentOS: /etc/nginx/conf.d/nginx.conf
Nota: Haga una copia de seguridad de los archivos u opciones relacionadas antes de modificar el archivo de configuración, preste especial atención al entorno de producción.
2) Riesgo:
(1) ataque BEAST y algoritmo RC4
Al manipular el modo de cifrado del bloque de cifrado CBC del algoritmo de cifrado, parte del tráfico cifrado se puede descifrar en secreto.
La nueva versión del cliente del navegador puede mitigar los ataques BEASE. Se recomienda deshabilitar todos los cifrados TLS 1.0 y usar solo RC4. Sin embargo, [RC4 tiene una lista cada vez mayor para prevenir ataques], (http://www.isg.rhul.ac.uk/tls/) muchos de ellos cruzan la teoría y la realidad. Y esta es la razón por la que la NSA ha descifrado RC4, lo que llamaron un "gran avance".
Hay varias consecuencias de deshabilitar RC4. 1. Los usuarios que utilicen navegadores incorrectos utilizarán 3DES en su lugar. 3-DES es más seguro que RC4. Pero significa más caro. Su servidor será más caro debido a estos usuarios. 2. RC4 puede aliviar el ataque BEAST. Por lo tanto, deshabilitar RC4 hace que los usuarios de TLS 1 sean vulnerables a los ataques al moverlos a AES-CBC (la "solución" habitual de BEAST del lado del servidor es priorizar RC4 por encima de todo). Estoy bastante seguro de que las fallas en RC4 en BEAST son obviamente mayores que los riesgos. De hecho, la mitigación del lado del cliente (proporcionada por Chrome y Firefox) BEAST ya no es un problema. Pero por el riesgo de crecer RC4: más criptoanálisis será superficial con el tiempo.
(2) ataque FREAK
FREAK es un ataque man-in-the-middle descubierto en INRIA, Microsoft Research e IMDEA por Cryptographic Experts Group. FREAK es "Factorizar claves RSA-EXPORT". Este ataque se remonta a la década de 1990, cuando el gobierno de EE. UU. Prohibió la venta de software de cifrado en el extranjero, a menos que la clave de cifrado en el conjunto de cifrado de salida no supere los 512 bits de longitud.
Resulta que algunos clientes TLS avanzados, incluidos SecureTransport de Apple y OpenSSL, tienen un error. Este error hizo que aceptaran el nivel de salida de la clave RSA incluso cuando el cliente no requería el nivel de salida de la clave RSA. El impacto de este error es bastante grave: si el cliente es vulnerable y el servidor admite RSA de salida, permite que una tercera persona ataque a través de un atacante activo para debilitar la calidad de la conexión.
Estos son los ataques de "nivel de salida RSA" que deben aceptar dos partes del servidor.
(3) Ataque MITM:
El proceso es el siguiente:
在客户端的Hello消息中，它请求一个标准的“RSA”密码套件。
MITM攻击者改变这个消息为了得到“RSA的输出”.
服务器返回一个512位的RSA输出密钥，并用它的永久密钥签名。
由于OpenSSL和SecureTransport存有bug，客户端就接受了这个弱密钥。
攻击者分析RSA模块为了恢复正在通信时RSA的解密密钥。
当客户端把加密的“预备主密钥”发送给服务器时，攻击者现在可以解密它从而得到TLS的“主密钥”。
从现在起，攻击者就可以看到明文了，并且可以注入任何他想的东西。
En esta página se proporcionan conjuntos de cifrado, pero admiten niveles de salida de contraseña. Asegúrese de que su OpenSSl sea la versión actualizada más recientemente y su cliente debe utilizar el software más reciente.
(4) Heartbleed (corazón sangrando)
Hearbleed es una vulnerabilidad de seguridad descubierta en la biblioteca criptográfica OpenSSL en abril de 2014. Se usa ampliamente en la implementación del protocolo Transport Layer (TLS). Heartbleed puede usarse independientemente de si se usa un OpenSSL vulnerable, como en un servidor o cliente. Se debe a una confirmación de entrada inapropiada (porque no hay verificación de límites) en la extensión de latido de DTLS (RFC6520), por lo que el nombre de esta vulnerabilidad es "latido". Esta vulnerabilidad se clasifica como un búfer de relectura, más de lo permitido. leer.
¿Qué versiones de OpenSSL se ven afectadas por Heartbleed?
La situación de diferentes versiones:
OpenSSL 1.0.1 到 1.0.1f (包括) 受攻击。
OpenSSL 1.0.1g不受攻击。
OpenSSL 1.0.0的分支不受攻击。
OpenSSL 0.9.8 的分支不受攻击。
OpenSSL descubrió esta vulnerabilidad en diciembre de 2011 y no tomó medidas hasta que OpenSSL1.0.1 fue lanzado el 14 de marzo de 2012. OpenSSL1.0.1g lanzado el 7 de abril de 2014 corrigió esta vulnerabilidad.
Al actualizar OpenSSL, puede evitar los ataques provocados por esta vulnerabilidad.
(5) Compresión SSL (ataque criminal)
En términos generales, los ataques criminales utilizan la compresión SSL para realizar su magia. La compresión SSL está deshabilitada de forma predeterminada en nginx1.1.6 + / 1.0.9 + (si se usa openssl 1.0.0+).
Si está utilizando nginx u otras versiones anteriores de OpenSSL, y su distribución no revierte esta opción, debe volver a compilar OpenSSL que no sea compatible con ZLIB. Esto prohibirá el uso del método de compresión DEFLATE para usar OpenSSL. Si lo hace, aún puede utilizar la compresión HTML DEFLATE normal.
(6) SSLV2 y SSLv3
SSL v2 no es seguro, por lo que debemos deshabilitarlo. También podemos deshabilitar SSL v3. Cuando TLS 1.0 sufre un ataque de degradación, podemos permitir que un atacante fuerce el uso de SSL v3 para conectarse, por lo que el "secreto de reenvío" está deshabilitado.
Edite este archivo de configuración nuevamente:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Ataque de caniche y TLS-FALLBACK-SCSV
SSLv3 permite la explotación de la vulnerabilidad "POODLE", que es una de las principales razones para desactivarla. Google ha propuesto una extensión de SSL / TLS llamada TLSFALLBACKSCSV para evitar degradaciones forzadas de SSL. Las siguientes son las versiones de OpenSSL que se habilitan automáticamente después de la actualización:
OpenSSL 1.0.1 有 TLSFALLBACKSCSV 在 1.0.1j 及更高的版本.
OpenSSL 1.0.0 有 TLSFALLBACKSCSV 在 1.0.0o 及更高的版本.
OpenSSL 0.9.8 有 TLSFALLBACKSCSV 在 0.9.8zc 及更高的版本.
(7) Conjunto de cifrado
Forward Secrecy garantiza la integridad de la clave de sesión en caso de que se filtre la clave permanente. PFS logra esto al realizar la derivación de una nueva clave para cada sesión.
Esto significa que cuando la clave privada se ve comprometida, no se puede utilizar para descifrar los registros de tráfico SSL.
El conjunto de cifrado proporciona la forma de Perfect Forward Secrecy temporalmente mediante el intercambio de claves Diffie-Hellman. Su desventaja es que son costosos, lo que puede mejorarse mediante la variación de la curva elíptica.
eg1:
ssl_ciphers 'AES128+EECDH:AES128+EDH';
eg2: de Mozilla Foundation, compatible con versiones anteriores (IE6 / WinXP)
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
Nota: Si el entorno utiliza una versión anterior de OpenSSL, las contraseñas que no se puedan utilizar se descartarán automáticamente. Nginx siempre usará el conjunto de cifrado completo y permitirá que OpenSSL elija el que admite. El orden del conjunto de cifrado también es muy importante, determina el algoritmo de prioridad utilizado en la comunicación. Los dos ejemplos de conjuntos de cifrado sugeridos anteriormente enfatizan que el algoritmo proporciona un secreto directo perfecto. Es posible que las versiones anteriores de OpenSSL no devuelvan una lista completa de algoritmos. AES-GCM está bastante cerca de algunos ECDHE y no está presente en la mayoría de las versiones de Ubuntu OpenSSL o RHEL.
En la nueva versión, puede usar el comando: nmap --script ssl-cert, ssl-enum-ciphers -p 443 host_ip, para obtener la siguiente información:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - fuerte
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - fuerte
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - fuerte
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - fuerte
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - fuerte
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - fuerte
| TLS_ECDHE_RSA_WITH_RC4_128_SHA - fuerte
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - roto
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA - roto
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA - roto
| TLS_ECDH_anon_WITH_RC4_128_SHA - roto
| TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - débil
| TLS_RSA_EXPORT_WITH_RC4_40_MD5 - débil
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - fuerte
| TLS_RSA_WITH_AES_128_CBC_SHA - fuerte
| TLS_RSA_WITH_AES_256_CBC_SHA - fuerte
| TLS_RSA_WITH_AES_256_CBC_SHA256 - fuerte
| TLS_RSA_WITH_AES_256_GCM_SHA384 - fuerte
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - fuerte
escena: A, B, C, C no cumple con los requisitos de esta categoría pertenecen
MD5: d272 52c0 b2ee 64ec ed34 07f1 643b 87a9
|_SHA-1: a098 6a65 4df2 cbb6 b859 e40a 953c bb91 c4f8 f639
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
En la salida anterior, los campos débiles, fuertes, débiles están todos cifrados de 40 bits y fuertes deben estar todos por encima de 128 bits. Cuando Nginx SSL no especifica ssl_ciphers, los algoritmos y protocolos de cifrado permitidos por defecto incluirán algunos algoritmos y protocolos que han demostrado ser inseguros, como algoritmos con claves de cifrado simétricas de menos de 128 bits; para garantizar que la conexión SSL sea suficientemente seguros, los algoritmos de encriptación débiles por debajo de 128 bits están deshabilitados, y el algoritmo debe especificarse claramente durante la configuración:
ssl_ciphers ALTO:! ADH:! MD5;
Además, openssl ha informado de la vulnerabilidad de divulgación de información del protocolo SSL / TLS (CVE-2016-2183), que se describe a continuación:
Los cifrados DES y Triple DES utilizados en TLS, SSH, negociación IPSec y otros productos tienen una fecha de nacimiento de aproximadamente 4 mil millones de yuanes. Esto permite a atacantes remotos atacar a través de Sweet32. La recomendación oficial es https://www.openssl.org/news/secadv/20160922.txt para actualizar los usuarios de OpenSSL 1.0.2 a 1.0.2i. Además, para mitigar el ataque SWEET32 basado en DES, en las versiones OpenSSL 1.0.1 y OpenSSL 1.0.2, el conjunto de cifrado DES se ha movido de una cadena de cifrado alto a una cadena de cifrado medio.
(8) Lógica de prioridad
首先选择 ECDHE + AESGCM 密码。这些都是 TLS 1.2 密码并没有受到广泛支持。这些密码目前没有已知的攻击目标。
PFS 密码套件是首选，ECDHE 第一，然后 DHE。
AES 128 更胜 AES 256。有讨论是否 AES256 额外的安全是值得的成本，结果远不明显。目前，AES128 是首选的，因为它提供了良好的安全，似乎真的是快，更耐时机攻击。
向后兼容的密码套件，AES 优先 3DES。暴力攻击 AES 在 TLS1.1 及以上，减轻和 TLS1.0 中难以实现。向后不兼容的密码套件，3DES 不存在.
RC4 被完全移除. 3DES 用于向后兼容。
(9) Descarte obligatorio
aNULL 包含未验证 diffie - hellman 密钥交换，受到中间人这个攻击
eNULL 包含未加密密码(明文)
EXPORT 被美国法律标记为遗留弱密码
RC4 包含了密码，使用废弃ARCFOUR算法
DES 包含了密码，使用弃用数据加密标准
SSLv2 包含所有密码,在旧版本中定义SSL的标准,现在弃用
MD5 包含所有的密码，使用过时的消息摘要5作为散列算法
3) Algoritmos de cifrado compatibles con openssl
(1) Algoritmo de cifrado simétrico
OpenSSL proporcionó un total de ocho tipos de método de algoritmo de cifrado simétrico , 7 de algoritmo de cifrado de paquetes es sólo un algoritmo de cifrado de flujo es el RC4 . Los algoritmos de cifrado de 7 bloques son AES, DES, Blowfish, CAST, IDEA, RC2, RC5, todos los cuales admiten el modo de libro de códigos electrónico (ECB), el modo de enlace de bloque cifrado (CBC), el modo de retroalimentación cifrada (CFB) y el modo de retroalimentación de salida ( OFB) Cuatro modos de cifrado de cifrado de bloques de uso común. Entre ellos, el modo de retroalimentación de cifrado (CFB) y el modo de retroalimentación de salida (OFB) utilizados por AES tienen una longitud de paquete de 128 bits, mientras que otros algoritmos usan 64 bits. De hecho, el algoritmo DES no solo es el algoritmo DES comúnmente utilizado, sino que también admite tres claves y dos algoritmos 3DES clave.
(2) Algoritmo de cifrado asimétrico
OpenSSL implementa un total de 4 algoritmos de cifrado asimétrico , incluido el algoritmo DH, el algoritmo RSA, el algoritmo DSA y el algoritmo de curva elíptica (EC).
Intercambio de claves de usuario general del algoritmo DH.
El algoritmo RSA se puede utilizar tanto para el intercambio de claves como para la firma digital.
El algoritmo DSA generalmente solo se usa para firmas digitales.
(3) Algoritmo de resumen de información
OpenSSL implementa cinco algoritmos de resumen de información, a saber, MD2, MD5, MDC2, SHA (SHA1) y RIPEMD. El algoritmo SHA en realidad incluye dos algoritmos de resumen de información, SHA y SHA1. Además, OpenSSL también implementa los dos algoritmos de resumen de información DSS y DSS1 especificados en el estándar DSS.
4) El algoritmo DES está deshabilitado en Nginx:
(1) Ver los algoritmos admitidos actualmente por openssl: openssl ciphers -V
Entre ellos, el algoritmo de intercambio de claves de tabla Kx: utilizado para negociar la clave de sesión; Algoritmo de verificación de tabla Au: utilizado para verificar la identidad del servidor; Algoritmo de cifrado simétrico Enc: mensaje cifrado; Algoritmo de resumen de Mac: manipulación anti-mensaje. La configuración predeterminada de nginx es HIGH:! ANULL:! MD5
(2) Desactive el cifrado DES:
Ejecute nginx -t para confirmar la ubicación actual del archivo de configuración nginx y modificarlo. La lista de algoritmos de opciones de cifrado en el archivo de configuración nginx contiene uno o más: separados por dos puntos. ¡El signo de exclamación! Significa que este algoritmo está prohibido, por lo que cuando el navegador utiliza algoritmos inseguros, la conexión se prohibirá automáticamente.
Verificación: nmap -Pn --script ssl-cert, ssl-enum-ciphers -p 443 host_ip
como se mencionó anteriormente, donde TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) y TLS_DHE_RSA_WITH_3DES_EDEWITH_ChBC
es otro servidor 20 porque no se ha configurado otro servidor_RSA_3DES_WC3. todavía. Después de deshabilitar el algoritmo de cifrado DES, lo probé de nuevo y el efecto es el siguiente
5) Nginx otra configuración de seguridad
Asegúrese de agregar las siguientes opciones en Nginx.conf para elegir un cifrado durante el protocolo de enlace SSLv3 o TLSv1:
ssl_prefer_server_ciphers on;
ssl_session_cache compartido: SSL: 10 m;
Seguridad de transporte estricta HTTP
Si es posible, debe habilitar HTTP Strict Transport Security (HSTS), que indica al navegador que acceda a su sitio solo a través de HTTPS.
Extensión de fijación de clave pública HTTP
También debe habilitar la extensión de fijación de clave pública HTTP.
La fijación de clave pública significa que la cadena de certificados debe contener la clave pública en la lista blanca. Garantiza que solo las CA de la lista blanca puedan firmar * .example.com, no ninguna CA guardada en el navegador.
6) Secreto hacia adelante
El concepto de secreto directo es simple: el cliente y el servidor negocian una clave confiable y la destruyen después de que finaliza la sesión. La clave privada RSA en el servidor se utiliza para firmar la clave Diffie-Hellman intercambiada entre el cliente y el servidor. La clave maestra secundaria se obtiene del protocolo de enlace Diffie-Hellman y se utiliza para el cifrado. Dado que la clave maestra secundaria es específica en la conexión entre el cliente y el servidor y se utiliza durante un tiempo limitado, se denomina efímera (de corta duración).
Debido a Forward Secrecy, incluso si el atacante tiene la clave privada del servidor, no puede descifrar las sesiones pasadas. La clave privada solo se usa para firmar el protocolo de enlace DH (Diffie-Hellman) y no revela la clave maestra adjunta. Diffie-Hellman asegura que la clave secundaria no saldrá del cliente y del servidor, ni será interceptada por el intermediario.
Todas las versiones de nginx se basan en OpenSSL al ingresar parámetros en Diffiel-Hellman. Desafortunadamente, esto significa que Diffiel-Hellman Ephemeral (DHE) usará este defecto en OpenSSL, incluida una clave de intercambio de 1024 bits. Dado que estamos utilizando un certificado de 2048 bits, los clientes DHE utilizarán un intercambio de claves más débil que los clientes no efímeros. Por lo tanto, necesitamos generar un parámetro DHE más fuerte, ejecutar:
cd / etc / ssl /
certs openssl dhparam -out dhparam.pem 4096
vi /etc/nginx/nginx.conf, escribir: ssl_dhparam / etc / ssl / certs / dhparam. pem; De esta manera, nginx usará dhparam.pem para el intercambio de claves DHE;
7) OCSP aplicable
OCSP se denomina Protocolo de estado de certificado en línea, es decir, protocolo de estado de certificado en línea.
Al conectarse con el servidor, el cliente verifica la validez del certificado del servidor mediante la lista de revocación de certificados (CRL) o el registro del protocolo de estado de certificados en línea (OCSP). Pero el problema con la CRL es que la lista de elementos de la CRL sigue aumentando y es necesario descargarla continuamente.
OCSP es más ligero porque solo recupera un registro a la vez . Pero el efecto secundario es que al conectarse al servidor, la solicitud OCSP debe enviarse al respondedor de terceros, lo que aumenta la demora y la posibilidad de falla. De hecho, la CA controla el respondedor OCSP. Debido a que a menudo no es confiable, el navegador falla porque no recibe una respuesta oportuna. Esto reduce la seguridad porque permite que un atacante realice un ataque DoS en el respondedor OCSP para cancelar la verificación .
La solución es permitir que el servidor envíe el registro OCSP en caché durante el protocolo de enlace TLS , evitando así el respondedor OCSP. Esta técnica ahorra un intercambio entre el cliente y el respondedor OCSP, referido OCSP cerrado (OCSP Stapling).
El servidor solo envía una respuesta OCSP en caché cuando el cliente lo solicita y declara soporte a través de la extensión status_request TLS de CLIENT HELLO.
La mayoría de los servidores almacenarán en caché las respuestas OCSP hasta por 48 horas. A intervalos regulares, el servidor se conectará al respondedor OCSP de la CA para obtener el registro OCSP más reciente. La ubicación del respondedor OCSP se obtiene del campo Acceso a la información de la autoridad del certificado firmado.
命令 检测 ：
openssl s_client -connect ffis.me:443 -servername ffis.me -status -tlsextdebug </ dev / null 2> & 1 | grep -i "respuesta OCSP"
# 开启 OCSP Stapling，开启后服务器在TLS握手时发送事先缓存的OCSP响应，用户只需验证该响应的有效性而不用再向数字证书认证机构（CA）发送请求
ssl_stapling on;
# 启用或禁用服务器对OCSP响应的验证
ssl_stapling_verify on;
# 证书的签发机构的ca证书，我的Let's Encrypt是acme.sh自动获取的证书，ca证书目录为：/root/.acme.sh/ffis.me/ca.cer
ssl_trusted_certificate /usr/local/nginx/conf/ssl/ffis.me_ca.cer;
# 添加resolver解析OSCP响应服务器的主机名，valid表示缓存。这里添加是为了解决DNS污染问题。
resolver 8.8.8.8 8.8.4.4 223.5.5.5 valid=60s;
# 网络超时时间
resolver_timeout 2s;
El problema persiste: la consulta OCSP se implementa en el lado del servidor, lo que evita que el navegador realice la verificación OCSP y, por lo tanto, afecta la velocidad de acceso;
pero la memoria caché de respuesta OCSP no está precargada, sino que se carga de forma asincrónica; después de que se inicia Nginx, solo si hay Cuando el cliente accede, Nginx comienza a solicitar la respuesta OCSP y la almacena en caché localmente, y cuando la caché de respuesta OCSP expira, no se actualiza activamente, sino que espera a que el cliente acceda a la actualización activada asincrónicamente;
esto conducirá to always Hubo varias visitas que no pasaron por la caché de respuesta de OCSP, lo que resultó en velocidades de acceso lentas.
[Vulnerabilidad de OCSP]:
existe una vulnerabilidad grave en la extensión de solicitud de estado de OpenSSL OCSP, que hace que el cliente malintencionado utilice la memoria del servidor. Aprovechando esta vulnerabilidad, el servidor configurado de forma predeterminada puede asignar una sección de la memoria de ID de OCSP cada vez que se negocia el acuerdo. La negociación repetida puede hacer que la memoria del servidor se consuma infinitamente, incluso si el servidor no está configurado con OCSP. En teoría, una identificación OCSP puede tener hasta 65.535 bytes y el atacante puede continuar reconsiderando el consumo de memoria del servidor de casi 64K cada vez. Sin embargo, en términos de implementación, en la versión OpenSSL 1.0.2, la longitud de ClientHello está limitada a 16,384 bytes, por lo que cada vez que el negocio pesado solo puede hacer que el consumo de memoria del servidor sea de aproximadamente 16K. Sin embargo, en la última versión 1.1.0, el límite en la longitud de ClientHello se incrementa a 131.396 bytes, por lo que para los servidores que usan la versión 1.1.0, el consumo de memoria será de casi 64K cada vez.
Versión afectada:
OpenSSL 0.9.8h a 0.9.8v
OpenSSL 1.0.1 hasta 1.0.1t
OpenSSL 1.0.2 a 1.0.1h
OpenSSL 1.1.0
Versión no afectada:
OpenSSL 1.0.1u
OpenSSL 1.0.2i
OpenSSL 1.1.0a
Solución: actualice a la última versión para evitar ser atacado. No es necesario cancelar la clave privada o el certificado, y el atacante no puede robar la clave privada. https://www.openssl.org/source/
5) Ejemplo de configuración de seguridad de Nginx
server {
listen [::]:443 default_server;
ssl on;
ssl_certificate_key /etc/ssl/cert/blue.pem;
ssl_certificate /etc/ssl/cert/ca-blue.pem;
ssl_ciphers 'AES128+EECDH:AES128+EDH:!aNULL';
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_cache shared:SSL:10m;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
add_header Strict-Transport-Security max-age=63072000;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
root /var/www/;
index index.html index.htm;
server_name raymii.org;
}