Unu el la ĉefaj retejoj de Alexa (centra rondo), sekurigita per HTTPS, kun subdomajnoj (grizaj) kaj dependecoj (blankaj), inter kiuj estas vundeblaj (strekita ombriĝo)
Nuntempe, la HTTPS-sekura konekto-ikono fariĝis normo kaj eĉ necesa atributo de iu ajn serioza retejo. Se mankas, preskaŭ ĉiuj lastatempaj retumiloj montras averton ke kaj ne rekomendas transdoni konfidencajn informojn al ĝi.
Sed rezultas, ke la ĉeesto de "seruro" en la adresbreto ne ĉiam garantias protekton. de la taksado, Alexa montris, ke multaj el ili estas submetataj al kritikaj vundeblecoj en la protokoloj SSL / TLS, kutime per subdomajnoj aŭ dependecoj. Laŭ la aŭtoroj de la studo, la komplekseco de modernaj TTT-aplikoj multe pliigas la ataksurfacon.
Esplorrezultoj
La studo estis farita de fakuloj de la Universitato de Venecio Ca' Foscari (Italio) kaj la Viena Teknika Universitato. Ili prezentos detalan raporton ĉe la 40-a IEEE-Simpozio pri Sekureco kaj Privateco, kiu okazos la 20-22-an de majo 2019 en San Francisco.
La supraj 10 Alexa-listaj HTTPS-ejoj kaj 000 rilataj gastigantoj estis testitaj. Vundeblaj kriptografaj agordoj estis detektitaj sur 90 gastigantoj, tio estas, proksimume 816% de la totalo:
- 4818 vundebla al MITM
- 733 estas vundeblaj al plena TLS-malĉifrado
- 912 estas vundeblaj al parta TLS-malĉifrado
898 retejoj estas tute malfermitaj al hakado, tio estas, ili permesas la injekton de eksterlandaj skriptoj, kaj 977 retejoj ŝarĝas enhavon de malbone protektitaj paĝoj, kun kiuj atakanto povas interagi.
La esploristoj emfazas, ke inter la 898 "tute kompromititaj" rimedoj estas interretaj vendejoj, financaj servoj kaj aliaj grandaj retejoj. 660 el 898 retejoj elŝutas eksterajn skriptojn de vundeblaj gastigantoj: ĉi tio estas la ĉefa fonto de danĝero. Laŭ la aŭtoroj, la komplekseco de modernaj TTT-aplikoj multe pliigas la ataksurfacon.
Aliaj problemoj ankaŭ estis trovitaj: 10% de rajtigaj formularoj havas problemojn kun la sekura transdono de informoj, kiu minacas liki pasvortojn, 412 retejoj permesas interkapton de kuketoj kaj seankaperon, kaj 543 retejoj estas submetataj al atakoj kontraŭ kuketa integreco (per subdomajnoj) .
La problemo estas, ke en la lastaj jaroj en la SSL/TLS protokoloj kaj programaro : POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), KRIME (CVE-2012-4929), BREACH (CVE-2013-3587), kaj Heartbleed (CVE-2014-0160). Por protekti kontraŭ ili, kelkaj agordoj estas postulataj ĉe la servilo kaj kliento por eviti uzi malnovajn vundeblajn versiojn. Sed ĉi tio estas sufiĉe ne bagatela proceduro, ĉar tiaj agordoj implicas elekti el ampleksa aro de ĉifroj kaj protokoloj, kiuj estas sufiĉe malfacile kompreneblaj. Ne ĉiam estas klare, kiuj ĉifroj kaj protokoloj estas konsiderataj "sufiĉe sekuraj".
Rekomenditaj agordoj
Neniu estas oficiale aprobita kaj interkonsentita listo de rekomenditaj HTTPS-agordoj. Do, ofertas plurajn agordajn opciojn, depende de la bezonata nivelo de protekto. Ekzemple, jen la rekomenditaj agordoj por servilo nginx 1.14.0:
Moderna Reĝimo
Plej malnovaj subtenataj klientoj: Fajrovulpo 27, Chrome 30, IE 11 en Vindozo 7, Edge, Opera 17, Safari 9, Android 5.0 kaj 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>;
....
}Meza subteno
Plej malnovaj subtenataj klientoj: Fajrovulpo 1, Chrome 1, IE 7, Opera 5, Safaro 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>;
....
}Malnova Subteno
Plej malnovaj subtenataj klientoj: 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>;
....
}Oni rekomendas, ke vi ĉiam uzu la plenan ĉifraĵon kaj la plej novan version de OpenSSL. La ĉifraĵo en la servilaj agordoj specifas la prioritaton en kiu ili estos uzataj, depende de la klientaj agordoj.
Esploro montras, ke ne sufiĉas nur instali HTTPS-atestilon. "Kvankam ni ne pritraktas kuketojn kiel ni faris en 2005, kaj "deca TLS" fariĝis ordinara, rezultas, ke ĉi tiuj bazaj aferoj ne sufiĉas por sekurigi surprize grandan nombron da tre popularaj retejoj," la aŭtoroj de la verko. Por fidinde protekti la kanalon inter la servilo kaj la kliento, vi devas zorge kontroli la infrastrukturon de viaj propraj subdomajnoj kaj triaj gastigantoj de kiuj enhavo por la retejo estas liverita. Eble havas sencon mendi revizion de iu triaparta firmao, kiu specialiĝas pri informa sekureco.
fonto: www.habr.com