Geekly articles weekly

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


L'un des meilleurs sites Alexa (le cercle central), protégé par HTTPS, avec des sous-domaines (gris) et des dépendances (blanc), parmi lesquels il y a vulnérable (remplissage en pointillés)

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

Mais il s'avère que la présence d'un «verrou» dans la barre d'adresse ne garantit pas toujours la protection. Une vérification de 10 000 principaux sites du classement Alexa a montré que beaucoup d'entre eux sont soumis à 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 recherche


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 de l'IEEE sur la sécurité et la confidentialité, qui se tiendra du 20 au 22 mai 2019 à San Francisco.

10000 des sites HTTPS les plus populaires de la liste Alexa et 90816 hôtes associés ont été vérifiés. Des configurations cryptographiques vulnérables ont été détectées sur 5574 hôtes, soit environ 5,5% du total:

  • 4818 vulnérable au MITM
  • 733 vulnérable au décryptage complet de TLS
  • 912 vulnérable au décryptage TLS partiel

898 sites sont complètement ouverts au piratage, c'est-à-dire qu'ils permettent l'injection de scripts superflus, et 977 sites téléchargent du contenu à partir de pages faiblement 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 des 898 sites téléchargent des scripts externes à partir d'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 été découverts: 10% des formulaires d'autorisation ont des problèmes avec la transmission sécurisée d'informations, ce qui pourrait conduire à une fuite de mot de passe, 412 sites permettent l'interception de cookies et le «détournement de session», et 543 sites sont susceptibles d'attaques sur l'intégrité des cookies (via des sous-domaines).

Le problème est que ces dernières années, un certain nombre de vulnérabilités ont été identifiées dans les protocoles et logiciels SSL / TLS: POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE -2013-3587) et Heartbleed (CVE-2014-0160). Pour se protéger contre eux, un certain nombre de paramètres sont requis côté serveur et côté client pour éviter l'utilisation d'anciennes versions vulnérables. Mais c'est une procédure plutôt simple, car ces paramètres permettent de choisir parmi un ensemble complet de chiffrements et de protocoles, qui sont assez difficiles à comprendre. Il n'est pas toujours clair quels ensembles particuliers de chiffrements et de protocoles sont considérés comme «assez sûrs».

Paramètres recommandés


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

Mode moderne


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

Support moyen


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


Clients les plus anciens pris en charge: 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 indique la priorité dans laquelle ils seront utilisés, selon les paramètres du client.

La recherche montre que l'installation d'un certificat HTTPS n'est pas suffisante. "Bien que nous ne traitions pas les cookies comme en 2005, et que le TLS décent soit devenu un lieu commun, il s'avère que ces éléments de base ne suffisent pas à assurer la sécurité d'un nombre étonnamment élevé de sites très populaires", disent les auteurs de l'ouvrage. Pour une protection fiable du canal entre le serveur et le client, vous devez surveiller attentivement l'infrastructure de vos propres sous-domaines et hôtes tiers à partir desquels le contenu du site est fourni. Il est peut-être judicieux de demander un audit à une société tierce spécialisée dans la sécurité de l'information.




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

More articles:


All Articles