Eine der Top-Seiten bei Alexa (zentraler Kreis), geschützt durch HTTPS, mit Subdomains (grau) und Abhängigkeiten (weiß), darunter verwundbare (schraffierte Füllung)
Heutzutage ist das Symbol für eine gesicherte HTTPS-Verbindung ein Standard und sogar ein notwendiges Attribut für jede ernsthafte Webseite. Wenn es fehlt, zeigen fast alle gängigen Browser eine Warnung an, dass und empfehlen, keine vertraulichen Informationen zu übermitteln.
Es stellt sich jedoch heraus, dass das Vorhandensein eines "Schlosses" in der Adresszeile nicht immer Schutz garantiert. aus dem Alexa-Ranking zeigte: viele von ihnen sind kritischen Schwachstellen der SSL/TLS-Protokolle ausgesetzt, meist über Subdomains oder Abhängigkeiten. Laut den Autoren der Studie erhöht die Komplexität moderner Webanwendungen die Angriffsfläche erheblich.
Die Forschungsergebnisse
Die Untersuchung wurde von Spezialisten der Universität Ca' Foscari in Venedig (Italien) und der Technischen Universität Wien durchgeführt. Einen ausführlichen Bericht werden sie auf dem 40. IEEE-Symposium über Sicherheit und Privatsphäre präsentieren, das vom 20. bis 22. Mai 2019 in San Francisco stattfindet.
10.000 der beliebtesten HTTPS-Websites aus der Alexa-Liste und 90.816 zugehörige Hosts wurden überprüft. Verwundbare kryptografische Konfigurationen wurden auf 5.574 Hosts gefunden, was etwa 5,5 % der Gesamtzahl ausmacht:
- 4.818 sind anfällig für MITM
- 733 sind anfällig für vollständige TLS-Dekodierung
- 912 sind anfällig für teilweise TLS-Dekodierung
898 Websites sind vollständig für Angriffe geöffnet, das heißt, sie erlauben die Einspeisung von unerwünschten Skripten, während 977 Websites Inhalte von schlecht gesicherten Seiten laden, mit denen Angreifer interagieren können.
Forschende betonen, dass unter den 898 „vollständig kompromittierten“ Ressourcen - Online-Shops, Finanzdienste und andere große Websites sind. 660 der 898 Websites laden externe Skripte von verwundbaren Hosts: dies ist die Hauptquelle der Gefahr. Laut den Autoren erhöht die Komplexität moderner Webanwendungen die Angriffsfläche erheblich.
Es wurden weitere Probleme festgestellt: Bei 10 % der Authentifizierungsformulare gibt es Probleme mit der sicheren Übertragung von Informationen, was zu Passwortlecks führt. 412 Websites erlauben das Abfangen von Cookies und führen zu „Sitzungsübernahmen“, während 543 Websites anfällig für Angriffe auf die Cookie-Integrität (über Subdomains) sind.
Das Problem ist, dass in den letzten Jahren eine Reihe von Schwachstellen in den SSL/TLS-Protokollen und der Software festgestellt wurden. : POODLE (CVE-2014-3566), BEAST (CVE-2011-3389), CRIME (CVE-2012-4929), BREACH (CVE-2013-3587) und Heartbleed (CVE-2014-0160). Um sich gegen diese Bedrohungen abzusichern, sind verschiedene Einstellungen auf der Server- und Client-Seite erforderlich, um die Verwendung veralteter, anfälliger Versionen zu vermeiden. Dies ist jedoch ein komplexer Prozess, da solche Einstellungen eine Wahl aus einem umfangreichen Set von Verschlüsselungen und Protokollen erfordern, was recht schwierig zu durchschauen ist. Es ist nicht immer klar, welche spezifischen Sets von Verschlüsselungen und Protokollen als „ausreichend sicher“ gelten.
Empfohlene Einstellungen
Es gibt keine offizielle, allgemein anerkannte Liste empfohlener HTTPS-Einstellungen. Daher mehrere Konfigurationsoptionen je nach benötigtem Schutzniveau an. Hier sind beispielsweise die empfohlenen Einstellungen für den nginx-Server 1.14.0:
Modus für moderne Clients
Die ältesten unterstützten Clients sind: Firefox 27, Chrome 30, IE 11 unter Windows 7, Edge, Opera 17, Safari 9, Android 5.0 und Java 8.
server {
listen 80 default_server;
listen [::]:80 default_server;
# Leite alle HTTP-Anfragen auf HTTPS mit einer 301 Moved Permanently-Antwort um.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Zertifikate, die an den Client im SERVER HELLO gesendet werden, sind in ssl_certificate verkettet
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;
# moderne Konfiguration. Passen Sie sie nach Ihren Bedürfnissen an.
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 ist erforderlich) (15768000 Sekunden = 6 Monate)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# holen Sie sich OCSP-Datensätze von der URL im ssl_certificate und cachen Sie sie
ssl_stapling on;
ssl_stapling_verify on;
## überprüfen Sie die Vertrauenskette des OCSP-Antworts mit Root CA und Zwischenzertifikaten
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver ;
....
}Durchschnittliche Unterstützung
Die ältesten unterstützten Clients sind: 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;
# Leiten Sie alle HTTP-Anfragen mit einer 301 Permanent Moved-Antwort auf HTTPS um.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Zertifikate, die dem Client im SERVER HELLO gesendet werden, sind im ssl_certificate zusammengefasst
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 für DHE-Verschlüsselungsverfahren, 2048 Bit empfohlen
ssl_dhparam /path/to/dhparam.pem;
# Zwischenkonfiguration. Passen Sie sie an Ihre Bedürfnisse an.
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 ist erforderlich) (15768000 Sekunden = 6 Monate)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# Holen Sie sich OCSP-Daten von der URL im ssl_certificate und cachen Sie sie
ssl_stapling on;
ssl_stapling_verify on;
## Verifizieren Sie die Vertrauenswürdigkeit der OCSP-Antwort mithilfe der Root-CA und der Zwischenzertifikate
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver ;
....
}Alte Unterstützung
Die ältesten unterstützten Clients sind: Windows XP IE6, Java 6
server {
listen 80 default_server;
listen [::]:80 default_server;
# Leite alle HTTP-Anfragen mit einer 301 Moved Permanently-Antwort auf HTTPS um.
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Die an den Client in SERVER HELLO gesendeten Zertifikate sind in ssl_certificate zusammengeführt.
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 für DHE-Ciphersuites, empfohlen 2048 Bit
ssl_dhparam /path/to/dhparam.pem;
# Alte Konfiguration. Passen Sie sie nach Ihren Bedürfnissen an.
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 ist erforderlich) (15768000 Sekunden = 6 Monate)
add_header Strict-Transport-Security max-age=15768000;
# OCSP-Stapling ---
# Holt OCSP-Daten von der URL in ssl_certificate und cached sie.
ssl_stapling on;
ssl_stapling_verify on;
## Überprüfen Sie die Vertrauenskette der OCSP-Antwort mit Root-CA und Zwischenzertifikaten.
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
resolver ;
....
}Es wird empfohlen, stets die vollständige Sammlung von Chiffren und die neueste Version von OpenSSL zu verwenden. Die Chiffren im Server-Setup geben die Priorität an, in der sie je nach den Einstellungen des Clients verwendet werden.
Forschung zeigt, dass es nicht ausreicht, einfach ein HTTPS-Zertifikat zu installieren. „Obwohl wir Cookies nicht mehr wie 2005 verarbeiten und ‚angemessener TLS‘ Standard geworden ist, zeigt sich, dass diese grundlegenden Dinge überraschend für die Sicherheit einer Vielzahl von sehr beliebten Webseiten unzureichend sind“, — die Autoren der Studie. Für den zuverlässigen Schutz des Kanals zwischen Server und Client ist es notwendig, die Infrastruktur der eigenen Subdomains und externer Hostanbieter, von denen Inhalte für die Website bereitgestellt werden, sorgfältig zu überwachen. Vielleicht ist es ratsam, eine Prüfung von einem externen Unternehmen zu beauftragen, das auf Informationssicherheit spezialisiert ist.
Quelle: habr.com
