HTTPS n'est pas toujours aussi sécurisé qu'il n'y paraît. Vulnérabilités trouvées dans 5,5 % des sites HTTPS

HTTPS n'est pas toujours aussi sécurisé qu'il n'y paraît. Vulnérabilités trouvées dans 5,5 % des sites HTTPS
Un des meilleurs sites d'Alexa (cercle central), sécurisé par HTTPS, avec des sous-domaines (gris) et des dépendances (blanc), parmi lesquels il y a des vulnérables (ombrage en pointillés)

De nos jours, l'icône de connexion sécurisée HTTPS est devenue un standard et même un attribut nécessaire de tout site sérieux. Si certificat manquant, presque tous les navigateurs récents affichent un avertissement la connexion au site n'est "pas sécurisée" et ne recommande pas de lui transférer des informations confidentielles.

Mais il s'avère que la présence d'un "cadenas" dans la barre d'adresse ne garantit pas toujours la protection. Vérification de 10 000 sites leaders à partir de la note, Alexa a montré que beaucoup d'entre eux sont sujets à des vulnérabilités critiques dans les protocoles SSL / TLS, généralement via des sous-domaines ou des dépendances. Selon les auteurs de l'étude, la complexité des applications web modernes augmente considérablement la surface d'attaque.

Résultats de l'étude

L'étude a été menée par des experts de l'Université de Venise Ca' Foscari (Italie) et de l'Université technique de Vienne. Ils présenteront un rapport détaillé lors du 40e Symposium IEEE sur la sécurité et la confidentialité, qui se tiendra du 20 au 22 mai 2019 à San Francisco.

Les 10 000 meilleurs sites HTTPS de la liste Alexa et 90 816 hôtes associés ont été testés. Des configurations cryptographiques vulnérables ont été détectées sur 5574 hôtes, soit environ 5,5 % du total :

  • 4818 vulnérables au MITM
  • 733 sont vulnérables au décryptage TLS complet
  • 912 sont vulnérables au décryptage TLS partiel

898 sites sont complètement ouverts au piratage, c'est-à-dire qu'ils permettent l'injection de scripts étrangers, et 977 sites chargent du contenu à partir de pages mal protégées avec lesquelles un attaquant peut interagir.

Les chercheurs soulignent que parmi les 898 ressources "complètement compromises" figurent les boutiques en ligne, les services financiers et autres grands sites. 660 sites sur 898 téléchargent des scripts externes depuis des hôtes vulnérables : c'est la principale source de danger. Selon les auteurs, la complexité des applications Web modernes augmente considérablement la surface d'attaque.

D'autres problèmes ont également été constatés : 10 % des formulaires d'autorisation ont des problèmes de transmission sécurisée des informations, ce qui menace de faire fuir les mots de passe, 412 sites permettent l'interception de cookies et le détournement de session, et 543 sites sont sujets à des attaques sur l'intégrité des cookies (via des sous-domaines) .

Le problème est que ces dernières années dans les protocoles et logiciels SSL/TLS identifié un certain nombre de vulnérabilités: POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587) et Heartbleed (CVE-2014-0160). Pour s'en protéger, un certain nombre de paramètres sont nécessaires côté serveur et côté client pour éviter d'utiliser d'anciennes versions vulnérables. Mais il s'agit d'une procédure plutôt non triviale, car de tels paramètres impliquent de choisir parmi un ensemble étendu de chiffrements et de protocoles, qui sont assez difficiles à comprendre. Il n'est pas toujours clair quelles suites de chiffrement et quels protocoles sont considérés comme "suffisamment sécurisés".

Paramètres recommandés

Il n'y a pas de liste officiellement approuvée et convenue des paramètres HTTPS recommandés. Donc, Générateur de configuration SSL Mozilla offre plusieurs options de configuration, selon le niveau de protection requis. Par exemple, voici les paramètres recommandés pour un serveur nginx 1.14.0 :

Mode moderne

Clients pris en charge les plus anciens : Firefox 27, Chrome 30, IE 11 sur Windows 7, Edge, Opera 17, Safari 9, Android 5.0 et 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>;

....
}

Soutien moyen

Clients pris en charge les plus anciens : 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>;

....
}

Ancien soutien

Clients pris en charge les plus anciens : 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>;

....
}

Il est recommandé de toujours utiliser la suite de chiffrement complète et la dernière version d'OpenSSL. La suite de chiffrement dans les paramètres du serveur spécifie la priorité dans laquelle ils seront utilisés, en fonction des paramètres du client.

La recherche montre qu'il ne suffit pas d'installer un certificat HTTPS. "Bien que nous ne gérions pas les cookies comme nous le faisions en 2005, et que le "TLS décent" soit devenu monnaie courante, il s'avère que ces éléments de base ne suffisent pas à sécuriser un nombre étonnamment élevé de sites très populaires", говорят les auteurs de l'ouvrage. Pour protéger de manière fiable le canal entre le serveur et le client, vous devez surveiller attentivement l'infrastructure de vos propres sous-domaines et des hôtes tiers à partir desquels le contenu du site est diffusé. Il est peut-être judicieux de commander un audit auprès d'une société tierce spécialisée dans la sécurité de l'information.

HTTPS n'est pas toujours aussi sécurisé qu'il n'y paraît. Vulnérabilités trouvées dans 5,5 % des sites HTTPS

Source: habr.com