Uno dei siti di punta di Alexa (cerchio centrale), protetto da HTTPS, con sottodomini (grigio) e dipendenze (bianco), tra cui ci sono quelli vulnerabili (riempimento tratteggiato)
Al giorno d'oggi, l'icona della connessione protetta HTTPS è diventata uno standard e un attributo necessario per qualsiasi sito serio. Se è assente, quasi tutti i browser recenti mostrano un avviso che e sconsigliano di trasmettere informazioni riservate.
Ma risulta che la presenza del "lucchetto" nella barra degli indirizzi non garantisce sempre la sicurezza. dalla classifica di Alexa ha mostrato che molti di essi sono soggetti a vulnerabilità critiche nei protocolli SSL/TLS, di solito attraverso sottodomini o dipendenze. Secondo gli autori dello studio, la complessità delle moderne applicazioni web aumenta notevolmente la superficie d'attacco.
Risultati della ricerca
Lo studio è stato condotto da esperti dell'Università Ca' Foscari di Venezia (Italia) e dell'Università Tecnica di Vienna. Presenteranno un rapporto dettagliato al 40° simposio IEEE sulla sicurezza e la privacy, che si terrà dal 20 al 22 maggio 2019 a San Francisco.
Sono stati analizzati 10.000 dei siti HTTPS più popolari della lista Alexa e 90.816 host a essi collegati. Configurazioni crittografiche vulnerabili sono state rilevate in 5.574 host, ovvero circa il 5,5% del totale:
- 4.818 vulnerabili agli attacchi MITM
- 733 vulnerabili a una decifratura completa del TLS
- 912 vulnerabili a una decifratura parziale del TLS
898 siti completamente esposti a hacking, consentendo l'iniezione di script esterni, mentre 977 siti caricano contenuti da pagine poco protette che potrebbero essere sfruttate dagli aggressori.
I ricercatori sottolineano che tra le 898 risorse "completamente compromesse" ci sono negozi online, servizi finanziari e altri grandi siti. 660 dei 898 siti caricano script esterni da host vulnerabili: questa è la principale fonte di pericolo. Secondo gli autori, la complessità delle moderne applicazioni web aumenta esponenzialmente la superficie d'attacco.
Sono state riscontrate anche altre problematiche: il 10% dei moduli di autenticazione presenta problemi di trasmissione sicura delle informazioni, rischiando la fuga di password, 412 siti consentono il furto di cookie e "session hijacking", mentre 543 siti sono vulnerabili ad attacchi all'integrità dei cookie (attraverso sottodomini).
Il problema è che negli ultimi anni sono state identificate diverse vulnerabilità nei protocolli SSL/TLS e nel software. : POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587) e Heartbleed (CVE-2014-0160). Per proteggerci è necessaria una serie di configurazioni sia lato server che client, al fine di evitare l'uso di versioni vulnerabili obsolete. Tuttavia, questa è una procedura piuttosto complessa, poiché tali configurazioni richiedono la scelta tra un'ampia gamma di algoritmi e protocolli, il che può risultare difficile da gestire. Non è sempre chiaro quali set specifici di algoritmi e protocolli possano essere considerati "sufficientemente sicuri".
Configurazioni consigliate
Non esiste un elenco ufficiale approvato e concordato di impostazioni HTTPS consigliate. Ad esempio, offre diverse opzioni di configurazione, a seconda del livello di sicurezza richiesto. Ecco le impostazioni raccomandate per il server nginx 1.14.0:
Modalità moderna
I client più vecchi supportati sono: Firefox 27, Chrome 30, IE 11 su Windows 7, Edge, Opera 17, Safari 9, Android 5.0 e Java 8
server {
listen 80 default_server;
listen [::]:80 default_server;
# Reindirizza tutte le richieste HTTP a HTTPS con una risposta 301 Moved Permanently.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# i certificati inviati al client nel SERVER HELLO sono concatenati 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;
# configurazione moderna. modifica secondo le tue esigenze.
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 è richiesto) (15768000 secondi = 6 mesi)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# recupera i record OCSP dall'URL in ssl_certificate e cache
ssl_stapling on;
ssl_stapling_verify on;
## verifica la catena di fiducia della risposta OCSP utilizzando il Root CA e i certificati intermedi
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver ;
....
}Supporto medio
I client più vecchi supportati sono: 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;
# Reindirizza tutte le richieste HTTP a HTTPS con una risposta 301 Moved Permanently.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# certs inviati al client nel SERVER HELLO sono concatenati 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;
# parametro Diffie-Hellman per le suite di cifratura DHE, raccomandato 2048 bit
ssl_dhparam /path/to/dhparam.pem;
# configurazione intermedia. adatta alle tue esigenze.
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 è richiesto) (15768000 secondi = 6 mesi)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# recupera i record OCSP da URL in ssl_certificate e memorizzali
ssl_stapling on;
ssl_stapling_verify on;
## verifica la catena di fiducia della risposta OCSP utilizzando Root CA e certificati intermedi
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver ;
....
}Supporto vecchio
I client più vecchi supportati sono: Windows XP IE6, Java 6
server {
listen 80 default_server;
listen [::]:80 default_server;
# Reindirizza tutte le richieste HTTP a HTTPS con una risposta 301 Spostato Permanentemente.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# i certificati inviati al client in SERVER HELLO sono concatenati 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;
# parametro Diffie-Hellman per i ciphersuite DHE, raccomandato 2048 bit
ssl_dhparam /path/to/dhparam.pem;
# vecchia configurazione. modifica a tuo piacimento.
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 è richiesto) (15768000 secondi = 6 mesi)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# recupera i record OCSP dall'URL in ssl_certificate e memorizzali nella cache
ssl_stapling on;
ssl_stapling_verify on;
## verifica la catena di fiducia della risposta OCSP utilizzando il certificato CA Root e i certificati intermedi
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver ;
....
}Si consiglia di utilizzare sempre l'insieme completo di crittografie e l'ultima versione di OpenSSL. L'insieme di crittografie nelle impostazioni del server indica la priorità con cui saranno utilizzate, in base alle impostazioni del client.
La ricerca mostra che non basta semplicemente installare un certificato HTTPS. "Anche se non gestiamo i cookie come nel 2005 e il 'TLS decente' è diventato la norma, sembra che queste basi non siano sufficienti a garantire la sicurezza per un numero sorprendentemente elevato di siti molto popolari", affermano gli autori dello studio. Per una protezione affidabile del canale tra server e client, è necessario monitorare attentamente l'infrastruttura dei propri sottodomini e degli host esterni da cui proviene il contenuto del sito. Potrebbe avere senso richiedere un audit a qualche azienda esterna specializzata in sicurezza informatica.
Fonte: habr.com
