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

En la actualidad, el ícono de conexión segura HTTPS se ha convertido en un atributo estándar e incluso necesario de cualquier sitio serio. Si el certificado faltante, la mayoría de los navegadores recientes muestran una advertencia de que la conexión al sitio "no es segura" y no recomiendan transmitir información confidencial a él.

Pero resulta que tener un "candado" en la barra de direcciones no siempre garantiza seguridad. La revisión de 10,000 de los principales sitios del ranking de Alexa mostró: muchos de ellos son vulnerables a fallas críticas en los protocolos SSL/TLS, generalmente a través de subdominios o dependencias. Según los autores de la investigación, la complejidad de las aplicaciones web modernas multiplica la superficie de ataque.

Resultados de la investigación

El estudio fue realizado por especialistas de la Universidad Ca’ Foscari de Venecia (Italia) y de la Universidad Técnica de Viena. Presentarán un informe detallado en el 40° simposio de IEEE sobre seguridad y privacidad, que tendrá lugar del 20 al 22 de mayo de 2019 en San Francisco.

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

4,818 son vulnerables a MITM
733 son vulnerables a la descifrado completo de TLS
912 son vulnerables a la descifrado parcial de TLS

898 sitios están completamente abiertos a hackeos, es decir, permiten la inyección de scripts externos, y 977 sitios cargan contenido de páginas poco protegidas, con las que un atacante puede interactuar.

Los investigadores subrayan que entre los 898 recursos "totalmente comprometidos" se encuentran tiendas en línea, servicios financieros y otros sitios importantes. 660 de los 898 sitios cargan scripts externos desde hosts vulnerables: esta es la principal fuente de peligro. Según los autores, la complejidad de las aplicaciones web modernas multiplica la superficie de ataque.

Se han detectado otros problemas: el 10% de los formularios de autenticación presentan problemas con la transmisión segura de información, lo que pone en riesgo las contraseñas, 412 sitios permiten la interceptación de cookies y el "secuestrador de sesión", y 543 sitios son vulnerables a ataques de integridad de cookies (a través de subdominios).

El problema es que en los últimos años se han encontrado vulnerabilidades en los protocolos SSL/TLS y en el software se han identificado varias vulnerabilidades: POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587) y Heartbleed (CVE-2014-0160). Para protegerse contra ellas, se requieren ciertos ajustes en el lado del servidor y del cliente para evitar el uso de versiones antiguas vulnerables. Pero este es un procedimiento bastante no trivial, ya que tales configuraciones implican la selección de un extenso conjunto de cifrados y protocolos, en los que es bastante complicado navegar. No siempre está claro cuáles conjuntos de cifrados y protocolos deben considerarse "suficientemente seguros".

Configuraciones recomendadas

No existe una lista oficialmente aprobada y acordada de configuraciones recomendadas para HTTPS. Así, 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

Los clientes más antiguos compatibles son: 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;

# Redirigir todas las solicitudes HTTP a HTTPS con una respuesta 301 Moved Permanently.
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# los certificados enviados al cliente en SERVER HELLO están concatenados en 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;


# configuración moderna. ajusta según tus necesidades.
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 es requerido) (15768000 segundos = 6 meses)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# obtener registros OCSP de la URL en ssl_certificate y almacenarlos en caché
ssl_stapling on;
ssl_stapling_verify on;

## verificar la cadena de confianza de la respuesta OCSP usando Root CA y certificados intermedios
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver ;

....
}

Soporte promedio

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

servidor {
listen 80 default_server;
listen [::]:80 default_server;

# Redirigir todas las solicitudes HTTP a HTTPS con una respuesta 301 Moved Permanently.
return 301 https://$host$request_uri;
}

servidor {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# los certificados enviados al cliente en SERVER HELLO se concatenan en 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;

# Parámetro Diffie-Hellman para DHE ciphersuites, recomendado 2048 bits
ssl_dhparam /path/to/dhparam.pem;

# configuración intermedia. ajusta a tus necesidades.
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 es requerido) (15768000 segundos = 6 meses)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# obtener registros OCSP de URL en ssl_certificate y almacenarlos en caché
ssl_stapling on;
ssl_stapling_verify on;

## verificar la cadena de confianza de la respuesta OCSP utilizando Root CA y certificados intermedios
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver ;

....
}

Soporte Antiguo

Los clientes más antiguos compatibles son: Windows XP IE6, Java 6

servidor {
listen 80 default_server;
listen [::]:80 default_server;

# Redirigir todas las solicitudes HTTP a HTTPS con una respuesta 301 Moved Permanently.
return 301 https://$host$request_uri;
}

servidor {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# los certificados enviados al cliente en SERVER HELLO se concatenan en 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;

# Parámetro Diffie-Hellman para DHE ciphersuites, recomendado 2048 bits
ssl_dhparam /path/to/dhparam.pem;

# configuración antigua. ajusta a tus necesidades.
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 es requerido) (15768000 segundos = 6 meses)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# obtener registros OCSP de URL en ssl_certificate y almacenarlos en caché
ssl_stapling on;
ssl_stapling_verify on;

## verificar la cadena de confianza de la respuesta OCSP utilizando Root CA y certificados intermedios
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver ;

....
}

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

La investigación muestra que no es suficiente con simplemente instalar un certificado HTTPS. "Aunque no tratamos las cookies como lo hacíamos en 2005, y el 'TLS decente' se ha vuelto común, resulta que estas cosas básicas son sorprendentemente insuficientes para garantizar la seguridad de una gran cantidad de sitios muy populares", que la internet lenta a menudo obliga a los jóvenes a abandonar las áreas rurales. Otro ejemplo: en Lagos (la ciudad más grande de Nigeria) los autores del trabajo. Para proteger de manera confiable el canal entre el servidor y el cliente, es necesario monitorear de cerca la infraestructura de los propios subdominios y los hosts externos desde donde se entrega el contenido para el sitio. Quizás valga la pena solicitar una auditoría a alguna empresa externa especializada en seguridad de la información.