Eine der meistbesuchten Alexa-Webseiten (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 notwendiges Attribut jeder seriösen Website. Wenn sollte in eine PEM-Datei geschrieben und diese Datei über den Dialog „Optionen / Datenschutz & Sicherheit / Zertifikate / Zertifikate anzeigen / Behörden / Importieren“ importiert werden. es fehlt, zeigen fast alle modernen Browser eine Warnung an, dass die Verbindung zur Website "nicht gesichert" ist und empfehlen nicht, darauf vertrauliche Informationen zu übermitteln.

Es stellt sich jedoch heraus, dass das Vorhandensein von "Schloss" in der Adresszeile nicht immer Sicherheit garantiert. Eine Überprüfung von 10.000 führenden Webseiten aus dem Alexa-Ranking hat gezeigt: Viele von ihnen sind kritischen Schwachstellen der SSL/TLS-Protokolle ausgesetzt, oft durch Subdomains oder Abhängigkeiten. Laut den Forschern erhöht die Komplexität moderner Webanwendungen die Angriffsfläche erheblich.

Ergebnisse der Studie

Die Studie wurde von Experten der Universität Ca’ Foscari Venedig (Italien) und der Technischen Universität Wien durchgeführt. Einen detaillierten Bericht werden sie auf dem 40. IEEE-Symposium für Sicherheit und Datenschutz präsentieren, das vom 20. bis 22. Mai 2019 in San Francisco stattfindet.

Es wurden 10.000 der beliebtesten HTTPS-Websites aus der Alexa-Liste und 90.816 damit verbundene Hosts überprüft. Verwundbare kryptografische Konfigurationen wurden auf 5.574 Hosts festgestellt, also etwa 5,5 % der Gesamtzahl:

4.818 sind verwundbar für MITM
733 sind verwundbar für vollständige TLS-Dekodierung
912 sind verwundbar für partielle TLS-Dekodierung

898 Websites sind vollständig für Angriffe offen, d.h. sie erlauben die Injektion fremder Skripte, während 977 Websites Inhalte von schwach geschützten Seiten laden, mit denen Angreifer interagieren können.

Die Forscher betonen, dass unter den 898 "vollständig kompromittierten" Ressourcen Online-Shops, Finanzdienstleistungen und andere große Websites sind. 660 der 898 Websites laden externe Skripte von verwundbaren Hosts: das ist die Hauptquelle der Gefahr. Laut den Autoren erhöht die Komplexität moderner Webanwendungen die Angriffsfläche erheblich.

Es wurden auch weitere Probleme festgestellt: Bei 10 % der Anmeldeformulare gibt es Probleme mit der sicheren Übertragung von Informationen, was das Risiko von Passwortlecks birgt. 412 Websites ermöglichen das Abfangen von Cookies und "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 in den Protokollen SSL/TLS und in der Software eine Reihe von Sicherheitsanfälligkeiten 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 davor zu schützen, sind eine Reihe von Einstellungen auf der Server- und Clientseite erforderlich, um die Verwendung alter, anfälliger Versionen zu vermeiden. Doch dies ist eine durchaus komplexe Prozedur, da solche Einstellungen eine Auswahl aus einem umfangreichen Set von Verschlüsselungen und Protokollen erfordern, die schwer zu durchschauen sind. Es ist nicht immer klar, welche Verschlüsselungs- und Protokollsets als „ausreichend sicher“ gelten.

Empfohlene Einstellungen

Es gibt keine offiziell genehmigte und einheitliche Liste empfohlener HTTPS-Einstellungen. So bietet der Mozilla SSL Configuration Generator mehrere Konfigurationsoptionen, abhängig vom gewünschten Schutzniveau. Zum Beispiel sind hier die empfohlenen Einstellungen für den Server nginx 1.14.0:

Moderner Modus

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 mit einer 301 Permanently Moved Antwort an HTTPS weiter.
return 301 https://$host$request_uri;
}

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

# Zertifikate, die dem Client in SERVER HELLO gesendet werden, werden im 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;


# moderne Konfiguration. Passen Sie sie 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 speichern Sie sie im Cache
ssl_stapling on;
ssl_stapling_verify on;

## Überprüfen Sie die Vertrauenswürdigkeit der OCSP-Antwort mit Root-CA und Intermediate-Zertifikaten
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver ;

....
}

Mittlere 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;

# Leitet alle HTTP-Anfragen zu 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 dem Client im SERVER HELLO gesendet werden, sind in 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, empfohlen 2048 Bit
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 ---
# Holt OCSP-Daten von der URL im ssl_certificate und cached sie
ssl_stapling on;
ssl_stapling_verify on;

## Überprüfen der Vertrauenskette der OCSP-Antwort mithilfe des Root CA und Zwischenzertifikaten
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;

# Leitet alle HTTP-Anfragen zu 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 dem Client im SERVER HELLO gesendet werden, sind in 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, empfohlen 2048 Bit
ssl_dhparam /path/to/dhparam.pem;

# alte Konfiguration. Passen Sie sie an Ihre Bedürfnisse 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 im ssl_certificate und cached sie
ssl_stapling on;
ssl_stapling_verify on;

## Überprüfen der Vertrauenskette der OCSP-Antwort mithilfe des Root CA und Zwischenzertifikaten
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver ;

....
}

Es wird empfohlen, immer das vollständige Set an Verschlüsselungen und die neueste Version von OpenSSL zu verwenden. Das Verschlüsselungsset in den Servereinstellungen gibt die Priorität an, in der sie je nach den Client-Einstellungen verwendet werden.

Die Untersuchung zeigt, dass es nicht ausreicht, nur ein HTTPS-Zertifikat zu installieren. ‚Obwohl wir Cookies nicht mehr wie 2005 behandeln und „anständiges TLS“ zur Norm geworden ist, stellt sich heraus, dass diese grundlegenden Dinge für die Sicherheit einer überraschend großen Anzahl sehr populärer Websites nicht ausreichen‘, – sagen die Autoren der Arbeit. Um den Kanal zwischen Server und Client zuverlässig zu schützen, muss die Infrastruktur aus eigenen Subdomains und externen Hosts, von denen der Inhalt für die Website geliefert wird, genau überwacht werden. Vielleicht macht es Sinn, ein Audit von einem externen Unternehmen in Auftrag zu geben, das sich auf Informationssicherheit spezialisiert hat.