Uno de los principales sitios de Alexa (círculo central), protegido por HTTPS, con subdominios (gris) y dependencias (blanco), entre los que se encuentran los vulnerables (sombreado discontinuo)
Hoy en día, el ícono de conexión segura HTTPS se ha convertido en un estándar e incluso en un atributo necesario de cualquier sitio serio. Si falta, casi todos los navegadores recientes muestran una advertencia que y no recomendamos transferirle información confidencial.
Pero resulta que la presencia de un "candado" en la barra de direcciones no siempre garantiza la protección. de la calificación, 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 considerablemente 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 llevará a cabo del 20 al 22 de mayo de 2019 en San Francisco.
Se probaron los principales 10 000 sitios HTTPS 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 son vulnerables al descifrado TLS completo
- 912 son vulnerables al descifrado TLS parcial
Los sitios 898 están completamente abiertos a la piratería, es decir, permiten la inyección de scripts de terceros, y los sitios 977 cargan contenido de páginas mal protegidas con las que un atacante puede interactuar.
Los investigadores destacan que entre los 898 recursos “completamente comprometidos” se encuentran tiendas online, servicios financieros y otros grandes sitios. 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 considerablemente la superficie de ataque.
También se encontraron otros problemas: el 10% de los formularios de autorización tienen problemas con la transmisión segura de información, lo que amenaza con filtrar contraseñas, 412 sitios permiten la interceptación de cookies y el secuestro de sesión, y 543 sitios están sujetos a ataques a la integridad de las cookies (a través de subdominios) .
El problema es que en los últimos años en los protocolos y software SSL/TLS : CANICHE (CVE-2014-3566), BESTIA (CVE-2011-3389), CRIME (CVE-2012-4929), INCUMPLIMIENTO (CVE-2013-3587) y Heartbleed (CVE-2014-0160). Para protegerse contra ellos, se requieren una serie de configuraciones en el lado del servidor y del cliente para evitar el uso de versiones antiguas vulnerables. Pero este es un procedimiento bastante no trivial, porque tales configuraciones implican elegir entre un amplio conjunto de cifrados y protocolos, que son bastante difíciles de entender. No siempre está claro qué conjuntos de cifrado y protocolos se consideran "suficientemente seguros".
Configuraciones recomendadas
No existe una lista oficialmente aprobada y acordada de configuraciones HTTPS recomendadas. Entonces, ofrece varias opciones de configuración, dependiendo del nivel de protección requerido. Por ejemplo, aquí están las configuraciones recomendadas para un 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 admitidos 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>;
....
}Soporte antiguo
Clientes admitidos 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>;
....
}Se recomienda que utilice siempre el paquete de cifrado completo y la última versión de OpenSSL. El conjunto de cifrado en la configuración del servidor especifica la prioridad en la que se utilizarán, según la configuración del cliente.
La investigación muestra que no es suficiente simplemente instalar un certificado HTTPS. "Si bien no manejamos las cookies como lo hacíamos en 2005, y el 'TLS decente' se ha convertido en un lugar común, resulta que estas cosas básicas no son suficientes para proteger una cantidad sorprendentemente grande de sitios muy populares". los autores de la obra. Para proteger de manera confiable el canal entre el servidor y el cliente, debe monitorear cuidadosamente la infraestructura de sus propios subdominios y hosts de terceros desde los cuales se suministra el contenido para el sitio. Tal vez tenga sentido solicitar una auditoría a una empresa externa que se especialice en seguridad de la información.
Fuente: habr.com