Isa sa mga nangungunang site ni Alexa (central circle), na sinigurado ng HTTPS, na may mga subdomain (grey) at dependencies (white), kung saan mayroong mga vulnerable (dashed shading)
Sa ngayon, ang icon ng secure na koneksyon ng HTTPS ay naging isang pamantayan at maging isang kinakailangang katangian ng anumang seryosong site. Kung nawawala, halos lahat ng kamakailang browser ay nagpapakita ng babala na at hindi inirerekomenda ang paglilipat ng kumpidensyal na impormasyon dito.
Ngunit lumalabas na ang pagkakaroon ng isang "lock" sa address bar ay hindi palaging ginagarantiyahan ang proteksyon. mula sa rating, ipinakita ni Alexa na marami sa kanila ang napapailalim sa mga kritikal na kahinaan sa mga protocol ng SSL / TLS, kadalasan sa pamamagitan ng mga subdomain o dependency. Ayon sa mga may-akda ng pag-aaral, ang pagiging kumplikado ng mga modernong web application ay lubos na nagpapataas ng pag-atake.
Mga resulta ng pananaliksik
Ang pag-aaral ay isinagawa ng mga eksperto mula sa University of Venice Ca' Foscari (Italy) at sa Vienna Technical University. Magpapakita sila ng detalyadong ulat sa 40th IEEE Symposium on Security and Privacy, na gaganapin sa Mayo 20-22, 2019 sa San Francisco.
Ang nangungunang 10 na listahan ng Alexa na mga site ng HTTPS at 000 kaugnay na host ay sinubukan. Ang mga masusugatan na cryptographic configuration ay nakita sa 90 host, ibig sabihin, humigit-kumulang 816% ng kabuuang:
- 4818 mahina sa MITM
- 733 ay mahina sa buong TLS decryption
- Ang 912 ay mahina sa bahagyang pag-decryption ng TLS
Ang 898 na mga site ay ganap na bukas sa pag-hack, ibig sabihin, pinapayagan nila ang pag-iniksyon ng mga extraneous na script, at ang 977 na mga site ay naglo-load ng nilalaman mula sa mga pahinang hindi pinoprotektahan kung saan maaaring makipag-ugnayan ang isang umaatake.
Binibigyang-diin ng mga mananaliksik na kabilang sa 898 na "ganap na nakompromiso" na mga mapagkukunan ay ang mga online na tindahan, serbisyong pinansyal at iba pang malalaking site. 660 sa 898 na mga site ang nagda-download ng mga panlabas na script mula sa mga mahihinang host: ito ang pangunahing pinagmumulan ng panganib. Ayon sa mga may-akda, ang pagiging kumplikado ng mga modernong web application ay lubos na nagpapataas ng pag-atake.
Natagpuan din ang iba pang mga problema: 10% ng mga form ng awtorisasyon ay may mga problema sa secure na pagpapadala ng impormasyon, na nagbabantang mag-leak ng mga password, pinapayagan ng 412 na site ang pagharang ng cookies at pag-hijack ng session, at 543 na site ang napapailalim sa mga pag-atake sa integridad ng cookie (sa pamamagitan ng mga subdomain) .
Ang problema ay na sa mga nakaraang taon sa SSL / TLS protocol at software : POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587), at Heartbleed (CVE-2014-0160). Upang maprotektahan laban sa mga ito, kailangan ng ilang mga setting sa server at client side upang maiwasan ang paggamit ng mga lumang vulnerable na bersyon. Ngunit ito ay isang medyo di-maliit na pamamaraan, dahil ang mga naturang setting ay kinabibilangan ng pagpili mula sa isang malawak na hanay ng mga cipher at protocol, na medyo mahirap maunawaan. Hindi palaging malinaw kung aling mga cipher suite at protocol ang itinuturing na "sapat na ligtas".
Mga inirekumendang setting
Walang opisyal na naaprubahan at napagkasunduan sa listahan ng mga inirerekomendang setting ng HTTPS. Kaya, nag-aalok ng ilang mga opsyon sa pagsasaayos, depende sa kinakailangang antas ng proteksyon. Halimbawa, narito ang mga inirerekomendang setting para sa isang nginx 1.14.0 server:
Modernong mode
Mga pinakalumang sinusuportahang kliyente: Firefox 27, Chrome 30, IE 11 sa Windows 7, Edge, Opera 17, Safari 9, Android 5.0, at 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>;
....
}Katamtamang suporta
Mga pinakalumang sinusuportahang kliyente: 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>;
....
}Lumang suporta
Mga pinakalumang sinusuportahang kliyente: 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>;
....
}Inirerekomenda na palagi mong gamitin ang buong cipher suite at ang pinakabagong bersyon ng OpenSSL. Ang cipher suite sa mga setting ng server ay tumutukoy sa priyoridad kung saan sila gagamitin, depende sa mga setting ng kliyente.
Ipinapakita ng pananaliksik na hindi sapat na mag-install lamang ng HTTPS certificate. "Bagama't hindi namin pinangangasiwaan ang cookies tulad ng ginawa namin noong 2005, at naging pangkaraniwan na ang 'disenteng TLS', lumalabas na ang mga pangunahing bagay na ito ay hindi sapat upang ma-secure ang isang nakakagulat na malaking bilang ng mga napakasikat na site," ang mga may-akda ng akda. Upang mapagkakatiwalaang protektahan ang channel sa pagitan ng server at ng kliyente, kailangan mong maingat na subaybayan ang imprastraktura mula sa iyong sariling mga subdomain at mga third-party na host kung saan ibinibigay ang nilalaman para sa site. Marahil ay makatuwiran na mag-order ng pag-audit mula sa ilang kumpanya ng third-party na dalubhasa sa seguridad ng impormasyon.
Pinagmulan: www.habr.com