Geekly articles weekly

HTTPS no siempre es tan seguro como parece. Vulnerabilidades encontradas en el 5.5% de los sitios HTTPS


Uno de los principales sitios de Alexa (el círculo central), protegido por HTTPS, con subdominios (gris) y dependencias (blanco), entre los cuales hay vulnerables (relleno discontinuo)

Hoy en día, el icono de conexión segura HTTPS se ha convertido en un atributo estándar e incluso necesario de cualquier sitio serio. Si falta el certificado , casi todos los navegadores recientes muestran una advertencia de que la conexión al sitio "no es segura" y no recomiendan transferirle información confidencial.

Pero resulta que la presencia de un "bloqueo" en la barra de direcciones no siempre garantiza la protección. Una verificación de 10,000 sitios líderes del ranking de Alexa mostró que muchos de ellos están sujetos a vulnerabilidades críticas en los protocolos SSL / TLS, generalmente a través de subdominios o dependencias. Según los autores del estudio, la complejidad de las aplicaciones web modernas aumenta enormemente la superficie de ataque.

Resultados de la investigación


El estudio fue realizado por expertos de la Universidad de Venecia Ca 'Foscari (Italia) y la Universidad Técnica de Viena. Presentarán un informe detallado en el 40 ° Simposio IEEE sobre Seguridad y Privacidad, que se realizará del 20 al 22 de mayo de 2019 en San Francisco.

Se revisaron 10,000 de los sitios HTTPS más populares de la lista de Alexa y 90,816 hosts relacionados. Se detectaron configuraciones criptográficas vulnerables en 5574 hosts, es decir, aproximadamente el 5,5% del total:

  • 4818 vulnerable a MITM
  • 733 vulnerable al descifrado completo de TLS
  • 912 vulnerable a descifrado parcial de TLS

898 sitios están completamente abiertos para hackear, es decir, permiten la inyección de scripts extraños, y 977 sitios descargan contenido de páginas poco protegidas con las que un atacante puede interactuar.

Los investigadores enfatizan que entre 898 recursos "completamente comprometidos" se encuentran las tiendas en línea, los servicios financieros y otros sitios grandes. 660 de 898 sitios descargan scripts externos de hosts vulnerables: esta es la principal fuente de peligro. Según los autores, la complejidad de las aplicaciones web modernas aumenta enormemente la superficie de ataque.

Se descubrieron otros problemas: el 10% de los formularios de autorización tienen problemas con la transmisión segura de información, lo que podría provocar una fuga de contraseña, 412 sitios permiten la interceptación de cookies y el "secuestro de sesión", y 543 sitios son susceptibles a ataques a la integridad de las cookies (a través de subdominios).

El problema es que en los últimos años, se han identificado una serie de vulnerabilidades en los protocolos y software SSL / TLS: POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE -2013-3587) y Heartbleed (CVE-2014-0160). Para protegerse contra ellos, se requieren varias configuraciones en el lado del servidor y del cliente para evitar el uso de versiones antiguas y vulnerables. Pero este es un procedimiento bastante trivial, porque tales configuraciones permiten elegir entre un amplio conjunto de cifrados y protocolos, que son bastante difíciles de entender. No siempre está claro qué conjuntos particulares de cifrados y protocolos se consideran "bastante seguros".

Configuraciones recomendadas


No hay una lista oficialmente aprobada y acordada de configuraciones recomendadas de HTTPS. Entonces, Mozilla SSL Configuration Generator ofrece varias opciones de configuración, dependiendo del nivel de protección requerido. Por ejemplo, aquí están las configuraciones recomendadas para el servidor nginx 1.14.0:

Modo moderno


Clientes admitidos más antiguos: Firefox 27, Chrome 30, IE 11 en Windows 7, Edge, Opera 17, Safari 9, Android 5.0 y Java 8

server { listen 80 default_server; listen [::]:80 default_server; # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response. return 301 https://$host$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate ssl_certificate /path/to/signed_cert_plus_intermediates; ssl_certificate_key /path/to/private_key; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # modern configuration. tweak to your needs. ssl_protocols TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; ssl_prefer_server_ciphers on; # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months) add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; ## verify chain of trust of OCSP response using Root CA and Intermediate certs ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; resolver <IP DNS resolver>; .... }

Soporte medio


Clientes compatibles más antiguos: Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7

 server { listen 80 default_server; listen [::]:80 default_server; # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response. return 301 https://$host$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate ssl_certificate /path/to/signed_cert_plus_intermediates; ssl_certificate_key /path/to/private_key; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits ssl_dhparam /path/to/dhparam.pem; # intermediate configuration. tweak to your needs. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'; ssl_prefer_server_ciphers on; # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months) add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; ## verify chain of trust of OCSP response using Root CA and Intermediate certs ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; resolver <IP DNS resolver>; .... }

Antiguo apoyo


Clientes compatibles más antiguos: Windows XP IE6, Java 6

 server { listen 80 default_server; listen [::]:80 default_server; # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response. return 301 https://$host$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate ssl_certificate /path/to/signed_cert_plus_intermediates; ssl_certificate_key /path/to/private_key; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits ssl_dhparam /path/to/dhparam.pem; # old configuration. tweak to your needs. ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP'; ssl_prefer_server_ciphers on; # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months) add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; ## verify chain of trust of OCSP response using Root CA and Intermediate certs ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; resolver <IP DNS resolver>; .... } DHE-RSA-AES128-GCM-SHA256: DHE-DSS-AES128-GCM-SHA256: kEDH + AESGCM: ECDHE-RSA-AES128-SHA256: ECDHE-ECDSA-AES128-SHA256: ECDHE- server { listen 80 default_server; listen [::]:80 default_server; # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response. return 301 https://$host$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate ssl_certificate /path/to/signed_cert_plus_intermediates; ssl_certificate_key /path/to/private_key; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits ssl_dhparam /path/to/dhparam.pem; # old configuration. tweak to your needs. ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP'; ssl_prefer_server_ciphers on; # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months) add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; ## verify chain of trust of OCSP response using Root CA and Intermediate certs ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; resolver <IP DNS resolver>; .... }

Se recomienda que siempre use el conjunto de cifrado completo y la última versión de OpenSSL. El conjunto de cifrado en la configuración del servidor indica la prioridad en la que se utilizarán, según la configuración del cliente.

La investigación muestra que instalar un certificado HTTPS no es suficiente. "Aunque no procesamos cookies como en 2005, y el TLS decente se ha convertido en un lugar común, resulta que estas cosas básicas no son suficientes para proporcionar seguridad a un número sorprendentemente grande de sitios muy populares", dicen los autores del trabajo. Para una protección confiable del canal entre el servidor y el cliente, debe monitorear cuidadosamente la infraestructura desde sus propios subdominios y hosts de terceros desde los cuales se suministra el contenido del sitio. Tal vez tenga sentido pedir una auditoría a una empresa externa que se especialice en seguridad de la información.




Source: https://habr.com/ru/post/446712/

More articles:


All Articles