Az Alexa egyik legjobb oldala (középső kör), amely HTTPS védelemmel rendelkezik, aldomainjeivel (szürke) és függőségeivel (fehér), amelyek között találhatóak sebezhetőek (pontozott kitöltés).

Manapság a HTTPS biztonságos kapcsolatra vonatkozó ikonja a legtöbb komoly weboldal szokásos és elengedhetetlen attribútuma. Ha a tanúsítvány hiányzik, szinte minden modern böngésző figyelmeztetést jelenít meg arról, hogy a kapcsolat a weboldallal "nem biztonságos". Nem ajánlják, hogy érzékeny információkat továbbítsanak rajta.

De kiderül, hogy a címmezőben lévő "lakat" megléte nem mindig garantálja a védelmet. 10 000 vezető weboldal ellenőrzése az Alexa rangsorából kimutatta: közülük sok súlyos sebezhetőségeknek van kitéve az SSL/TLS protokollokkal kapcsolatban, általában az aldomainjeiken vagy függőségeiken keresztül. A kutatók szerint a modern webalkalmazások bonyolultsága többszörösen megnöveli a támadási felületet.

A kutatás eredményei

A vizsgálatot a Ca' Foscari Velencei Egyetem (Olaszország) és a Bécsi Műszaki Egyetem szakértői végezték. Részletes beszámolójukat a IEEE 40. biztonsági és adatvédelmi szimpóziumán fogják bemutatni, amely 2019. május 20-22. között San Franciscóban kerül megrendezésre.

A HTTPS 10 000 legnépszerűbb weboldalát ellenőrizték az Alexa listájáról, és 90 816 kapcsolódó hosztot. Sebezhető kriptográfiai konfigurációkat 5574 hoszton találtak, ami körülbelül az összesített szám 5,5%-át jelenti:

4818 sebezhető a MITM támadásokkal szemben.
733 sebezhető a TLS teljes visszafejtésével szemben.
912 sebezhető a TLS részleges visszafejtésével szemben.

898 weboldal teljesen nyitva áll a hackerek előtt, vagyis lehetővé teszi idegen szkriptek injektálását, míg 977 weboldal gyengén védett oldalakról tölt be tartalmat, amelyekkel a támadó kölcsönhatásba léphet.

A kutatók hangsúlyozzák, hogy az 898 "teljesen kompromittált" erőforrás között találhatóak webáruházak, pénzügyi szolgáltatások és egyéb nagy oldalak. Az 898 weboldal 660 külső szkriptet tölt be sebezhető hosztokról: ez a legfőbb veszélyforrás. A szerzők szerint a modern webalkalmazások bonyolultsága többszörösen megnöveli a támadási felületet.

Más problémák is felfedezhetők: a bejelentkezési űrlapok 10%-ának problémái vannak az információk biztonságos továbbításával, ami jelszóliszteséhez vezethet, 412 weboldal lehetővé teszi a sütik elfogását és a „session hijacking”-et, míg 543 weboldal a sütiek integritásával szembeni támadásoknak van kitéve (aldomainen keresztül).

A probléma az, hogy az utóbbi években az SSL/TLS protokollokban és szoftverekben több sebezhetőség is napvilágot látott.: POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587) és Heartbleed (CVE-2014-0160). Ezek védelméhez egy sor beállítás szükséges a szerveren és az ügyfélen, hogy elkerüljük a régi sebezhető verziók használatát. Ám ez egy meglehetősen nem trivális eljárás, mert ezek a beállítások széleskörű titkosítók és protokollok közül való választást igényelnek, amelyekben nehéz eligazodni. Nem mindig világos, hogy mely titkosítók és protokollok számítanak „megfelelően biztonságosnak”.

Ajánlott beállítások

Nincs egyetlen hivatalosan jóváhagyott és egyeztetett HTTPS ajánlott beállítások listája. Így a Mozilla SSL Configuration Generator több konfigurációs lehetőséget ajánl, a kívánt védelmi szinttől függően. Például itt vannak az ajánlott beállítások az nginx 1.14.0 szerverhez:

Modern üzemmód

A legöregebb támogatott kliensek: Firefox 27, Chrome 30, IE 11 Windows 7 alatt, Edge, Opera 17, Safari 9, Android 5.0 és Java 8.

server {
listen 80 default_server;
listen [::]:80 default_server;

# Minden HTTP kérést átirányítunk HTTPS-re 301 Moved Permanently válasszal.
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# Az SERVER HELLO -ban az ügyfélnek küldött cert-eket összefűzik ssl_certificate-ben.
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 konfiguráció. a szükségeidnek megfelelően hangold.
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 szükséges) (15768000 másodperc = 6 hónap)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# OCSP rekordok lekérdezése az ssl_certificate címéről és tárolása
ssl_stapling on;
ssl_stapling_verify on;

## az OCSP válasz láncának ellenőrzése a gyökér-CA és köztes cert-ek felhasználásával.
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver ;

....
}

Közepes támogatás

A legöregebb támogatott kliensek: Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7.

szerver {
figyelj 80 default_server;
figyelj [::]:80 default_server;

# Minden HTTP kérést irányítson át HTTPS-re 301 Áthelyezve válaszsal.
return 301 https://$host$request_uri;
}

szerver {
figyelj 443 ssl http2;
figyelj [::]:443 ssl http2;

# A kliensnek a SERVER HELLO-ban küldött tanúsítványokat az ssl_certificate-ben összefűzik.
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 paraméter DHE titkosítási készletekhez, ajánlott 2048 bit
ssl_dhparam /path/to/dhparam.pem;

# középső konfiguráció. igazítsa az igényeihez.
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 szükséges) (15768000 másodperc = 6 hónap)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# OCSP rekordokat kérdezzen le az ssl_certificate URL-jén és tárolja
ssl_stapling on;
ssl_stapling_verify on;

## az OCSP válasz bizalom láncának ellenőrzése a Gyökér CA és Középfokú tanúsítványok segítségével
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver ;

....
}

Régi támogatás

A legöregebb támogatott kliensek: Windows XP IE6, Java 6

szerver {
figyelj 80 default_server;
figyelj [::]:80 default_server;

# Minden HTTP kérést irányítson át HTTPS-re 301 Áthelyezve válaszsal.
return 301 https://$host$request_uri;
}

szerver {
figyelj 443 ssl http2;
figyelj [::]:443 ssl http2;

# A kliensnek a SERVER HELLO-ban küldött tanúsítványokat az ssl_certificate-ben összefűzik.
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 paraméter DHE titkosítási készletekhez, ajánlott 2048 bit
ssl_dhparam /path/to/dhparam.pem;

# régi konfiguráció. igazítsa az igényeihez.
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 szükséges) (15768000 másodperc = 6 hónap)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# OCSP rekordokat kérdezzen le az ssl_certificate URL-jén és tárolja
ssl_stapling on;
ssl_stapling_verify on;

## az OCSP válasz bizalom láncának ellenőrzése a Gyökér CA és Középfokú tanúsítványok segítségével
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver ;

....
}

Mindig ajánlott a teljes titkosítási szett és az OpenSSL legújabb verziójának használata. A szerver beállításaiban a titkosítási szett a prioritást jelöli, amely alapján azok alkalmazásra kerülnek a kliens beállításai szerint.

A kutatások azt mutatják, hogy nem elég csak telepíteni az HTTPS tanúsítványt. "Bár már nem kezeljük a sütiket úgy, ahogyan 2005-ben, és a 'tisztes TLS' már köztudott, kiderül, hogy ezek az alapvető dolgok meglepően sok népszerű weboldal biztonságához nem elegendőek" — a gazdaság fejlődését. a tanulmány szerzői. A szerver és a kliens közötti kapcsolat biztonságának megőrzéséhez figylembe kell venni a saját aldomainstruktúrák és a külső hosztok átláthatóságát, ahonnan a weboldal tartalmát szállítják. Talán érdemes lenne auditot rendelni egy külső, információbiztonságra specializálódott cégtől.