Адзін з топавых сайтаў Alexa (цэнтральны гурток), абаронены HTTPS, з паддаменамі (шэрым) і залежнасцямі (белым), сярод якіх ёсць уразлівыя (штрыхавое заліванне)
У наш час значок абароненага злучэння HTTPS стаў стандартным і нават неабходным атрыбутам любога сур'ёзнага сайта. Калі адсутнічае, амаль усе апошнія браўзэры паказваюць папярэджанне, што і не рэкамендуюць перадаваць на яго канфідэнцыйную інфармацыю.
Але аказваецца, што наяўнасць "замочка" ў адрасным радку не заўсёды гарантуе абарону. з рэйтынгу Alexa паказала: шматлікія з іх схільныя крытычным уразлівасцям пратаколаў SSL/TLS, звычайна праз паддамены ці залежнасці. Па словах аўтараў даследавання, складанасць сучасных вэб-прыкладанняў шматкроць павялічвае паверхню нападу.
вынікі даследавання
Даследаванне правялі спецыялісты з Венецыянскага ўніверсітэта Ка' Фоскары (Італія) і Венскага тэхнічнага ўніверсітэта. Падрабязны даклад яны прадставяць на 40-м сімпозіуме IEEE па бяспецы і прыватнасці, які пройдзе 20-22 мая 2019 года ў Сан-Францыска.
Былі правераны 10 000 самых папулярных сайтаў HTTPS са спісу Alexa і 90 звязаных з імі хастоў. Уразлівыя крыптаграфічныя канфігурацыі выяўлены на 816 хастах, гэта значыць прыкладна на 5574% ад агульнай колькасці:
- 4818 уразлівыя для MITM
- 733 уразлівыя для поўнай дэшыфроўкі TLS
- 912 уразлівыя для частковай дэшыфроўкі TLS
898 сайтаў цалкам адкрыты для ўзлому, гэта значыць дапускаюць ін'екцыю старонніх скрыптоў, а 977 сайтаў загружаюць кантэнт са слаба абароненых старонак, з якімі можа ўзаемадзейнічаць зламыснік.
Даследнікі падкрэсліваюць, што сярод 898 «цалкам скампраметаваных» рэсурсаў – інтэрнэт-крамы, фінансавыя сэрвісы і іншыя буйныя сайты. 660 з 898 сайтаў загружаюць вонкавыя скрыпты з уразлівых хастоў: гэта асноўная крыніца небяспекі. Па словах аўтараў, складанасць сучасных вэб-прыкладанняў шматкроць павялічвае паверхню нападу.
Выяўлены і іншыя праблемы: у 10% формаў для аўтарызацыі праблемы з бяспечнай перадачай інфармацыі, што пагражае уцечкай пароляў, 412 сайтаў дапушчаюць перахоп кукісаў і «згон сесіі», а 543 сайта схільныя нападам на cookie integrity (праз паддамены).
Праблема ў тым, што за апошнія гады ў пратаколах SSL/TLS і праграмным забеспячэнні : POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587) і Heartbleed (CVE-2014-0160). Для абароны ад іх патрабуецца шэраг налад на боку сервера і кліента, каб пазбегнуць выкарыстанні старых уразлівых версій. Але гэта досыць нетрывіяльная працэдура, таму што такія налады прадугледжваюць выбар з шырокага набору шыфраў і пратаколаў, у якіх досыць складана разабрацца. Не заўсёды зразумела, якія менавіта наборы шыфраў і пратаколаў лічыць "дастаткова бяспечнымі".
Рэкамендаваны налады
Не існуе аднаго афіцыйна ўхваленага і ўзгодненага спісу рэкамендуемых налад HTTPS. Так, прапануе некалькі варыянтаў канфігурацыі, у залежнасці ад патрабаванага ўзроўня абароны. Напрыклад, вось рэкамендуемыя наладкі для сервера nginx 1.14.0:
Сучасны рэжым
Самыя старыя падтрымліваемыя кліенты: Firefox 27, Chrome 30, IE 11 на Windows 7, Edge, Opera 17, Safari 9, Android 5.0, і 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>;
....
}Сярэдняя падтрымка
Самыя старыя падтрымліваемыя кліенты: 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>;
....
}Старая падтрымка
Самыя старыя падтрымліваемыя кліенты: 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>;
....
}Рэкамендуецца заўсёды выкарыстоўваць поўны набор шыфраў і апошнюю версію OpenSSL. Набор шыфраў у наладах сервера паказвае прыярытэт, у якім яны будуць выкарыстоўвацца, у залежнасці ад налад кліента.
Даследаванне паказвае, што недастаткова проста ўсталяваць сертыфікат HTTPS. «Хоць мы не апрацоўваем печыва як у 2005 годзе, а „прыстойны TLS” стаў агульным месцам, але высвятляецца, што гэтых базавых рэчаў недастаткова для забеспячэння бяспекі на здзіўленне вялікай колькасці вельмі папулярных сайтаў», — аўтары працы. Для надзейнай абароны канала паміж серверам і кліентам трэба ўважліва адсочваць інфраструктуру з уласных паддаменаў і іншых хастоў, з якіх пастаўляецца кантэнт для сайта. Можа быць, мае сэнс замовіць аўдыт у якой-небудзь іншай кампаніі, якая спецыялізуецца на інфармацыйнай бяспецы.
Крыніца: habr.com