Transport Layer Security (TLS)-Konfiguration
Transport Layer Security (TLS) bietet Sicherheitsgarantien hinsichtlich Vertraulichkeit, Authentizität und Integrität aller Kommunikationen und sollte daher für alle eingehenden und ausgehenden Website-Kommunikationen verwendet werden.
TLS-Konfiguration
Problem
Wenn Daten unverschlüsselt über das Web gesendet werden, können sie von Dritten abgefangen, aufgerufen und verändert werden – dies wird oft als Man-in-the-Middle (MiTM)-Angriff bezeichnet. MiTM-Angriffe haben schwerwiegende Folgen für die Sicherheit Ihres Systems.
Alle Anfragen und Antworten sollten daher über HTTPS gesendet werden, das TLS zur Verschlüsselung der Daten verwendet. Das moderne Web erzwingt dies praktisch – alle Browser bewegen sich in Richtung einer standardmäßigen Anforderung von HTTPS, und viele Webfunktionen können nur in einem sicheren Kontext verwendet werden.
Lösung
Sie sollten Ihre Serversoftware so einrichten, dass sie eine sichere Konfiguration verwendet, welche die Nutzung von HTTPS mit sicheren TLS-Einstellungen erzwingt. Es gibt mehrere TLS-Konfigurationsgeneratoren, die dabei helfen können, z.B. den Mozilla SSL Configuration Generator. Dieses Tool bietet mehrere Optionen basierend auf Mozillas TLS-Richtlinien.
Laden von Ressourcen
Problem
Alle Ressourcen, unabhängig von ihrer Herkunft, sollten über sichere Kanäle geladen werden.
Sichere (HTTPS) Websites, die versuchen, aktive Ressourcen wie JavaScript über unsichere Verbindungen (HTTP) zu laden, werden von Browsern blockiert. Infolgedessen erleben Benutzer verschlechterte UIs und Mixed-Content-Warnungen. Im untenstehenden Code wird zum Beispiel HTTP fälschlicherweise verwendet, um eine JavaScript-Bibliothek zu laden:
<script src="http://code.jquery.com/jquery-1.12.0.min.js"></script>
Ähnlich führen Versuche, passive Inhalte wie Bilder unsicher zu laden, obwohl weniger riskant, dennoch zu verschlechterten UIs und Mixed-Content-Warnungen und können es Angreifern ermöglichen, Websites zu verunstalten oder Benutzer zu täuschen. Zum Beispiel:
<img src="http://very.badssl.com/image.jpg" />
Obwohl moderne Browser es offensichtlich machen, wenn Websites Ressourcen unsicher laden, treten diese Fehler im Web mit erheblicher Häufigkeit auf.
Lösung
Überprüfen Sie, dass alle Ressourcen über HTTPS geladen werden, bevor Sie sie bereitstellen.
Beispiele
In diesem Beispiel wird HTTPS korrekt verwendet, um eine JavaScript-Bibliothek zu laden:
<script src="https://code.jquery.com/jquery-1.12.0.min.js"></script>
HTTP-Weiterleitung
Problem
Websites könnten weiterhin auf Port 80 (HTTP) lauschen, um Verbindungsfehler zu verhindern, wenn Benutzer eine URL in ihre Adressleiste eingeben, da anfängliche Browser-Verbindungen oft über HTTP erfolgen. Dies stellt ein anfängliches Sicherheitsrisiko bei der ersten Verbindung zu Websites dar, da diese Verbindung nicht durch TLS geschützt ist.
Darüber hinaus sollten Websites Weiterleitungen von HTTP auf einem Host zu HTTPS auf einem anderen Host vermeiden, da dies verhindert, dass Strict-Transport-Security
für den ersten Host gesetzt werden kann (siehe HTTP Strict Transport Security).
Lösung
Websites, die auf Port 80 lauschen, sollten nur zum gleichen Resource auf HTTPS weiterleiten. Sobald die Weiterleitung erfolgt ist, sollte Strict-Transport-Security
sicherstellen, dass alle zukünftigen Versuche, die Website über HTTP zu erreichen, automatisch zur sicheren Website umgeleitet werden.
APIs oder Websites, die nicht für den öffentlichen Zugriff bestimmt sind, sollten die Verwendung von HTTP vollständig deaktivieren.
Um das "verschiedene Hosts"-Problem zu beheben:
- Zuerst von http://example.com/ auf https://example.com/ weiterleiten.
- Anschließend von https://example.com/ auf https://example.org/ weiterleiten.
Beispiele
Leiten Sie alle eingehenden HTTP-Anfragen zur gleichen Seite und URI auf HTTPS mit NGINX um:
server {
listen 80;
return 301 https://$host$request_uri;
}
Leiten Sie site.example.org
von HTTP auf HTTPS mit Apache um:
<VirtualHost *:80>
ServerName site.example.org
Redirect permanent / https://site.example.org/
</VirtualHost>
Implementierung von HTTP Strict Transport Security
Problem
Um Man-in-the-Middle (MiTM)-Angriffe zu verhindern, sollten Browser nur über HTTPS mit Websites verbinden.
Lösung
HTTP Strict-Transport-Security
(HSTS) ist ein HTTP-Header, der Browser darüber informiert, nur über HTTPS mit einer bestimmten Seite zu verbinden, selbst wenn das ursprünglich angegebene Schema HTTP war. Browser mit gesetztem HSTS für eine bestimmte Seite werden alle Anfragen an diese Seite automatisch zu HTTPS upgraden. HSTS weist Browser auch an, TLS- und zertifikatbezogene Fehler strenger zu behandeln, indem die Möglichkeit deaktiviert wird, die Zertifikat-Fehlerseite zu umgehen.
Strict-Transport-Security
unterstützt die folgenden Direktiven:
max-age
-
Legt die Dauer in Sekunden fest, für die Browser auf HTTPS umleiten.
includeSubDomains
Optional-
Gibt an, ob Browser Anfragen auf allen Subdomains zu HTTPS upgraden sollen. Beispielsweise wird durch das Setzen von
includeSubDomains
aufdomain.example.com
sichergestellt, dass Anfragen anhost1.domain.example.com
undhost2.domain.example.com
zusätzlich zudomain.example.com
ein Upgrade erhalten. preload
Optional-
Gibt an, ob die Seite vorab geladen werden soll. Das Hinzufügen dieser Direktive bedeutet, dass Ihre Seite in die HSTS-Preload-Liste aufgenommen werden kann.
Befolgen Sie diese Schritte, um HSTS korrekt auf Ihrer Website zu implementieren:
- Setzen Sie einen
max-age
-Wert von mindestens sechs Monaten (15768000
). Längere Zeiträume, wie etwa zwei Jahre (63072000
), werden empfohlen. Sobald dieser Wert gesetzt ist, muss die Seite bis zum Erreichen des Ablaufdatums HTTPS unterstützen. - Setzen Sie, wenn möglich,
includeSubDomains
um die Sicherheit auf allen Subdomains zu verbessern. Eine sorgfältige Prüfung ist erforderlich, wenn diese Direktive gesetzt wird, da sie Seiten auf Subdomains deaktivieren kann, die noch kein HTTPS aktiviert haben. - Setzen Sie, wenn möglich,
preload
, um Ihre Website in die HSTS-Preload-Liste aufzunehmen. Um sie zur Liste hinzuzufügen, besuchen Sie https://hstspreload.org/ und geben Sie Ihre Seiten-URL in das Formular oben auf der Seite ein und beheben Sie alle erwähnten Probleme. Webbrowser werden HTTPS-Upgrades zu vorab geladenen Seiten vornehmen, bevor der initialeStrict-Transport-Security
-Header empfangen wird. Dies verhindert Downgrade-Angriffe beim ersten Gebrauch und wird für alle hochriskanten Websites empfohlen. Beachten Sie, dass die Aufnahme in die HSTS-Preload-Liste auch erfordert, dassincludeSubDomains
gesetzt ist undmax-age
auf mindestens 1 Jahr (31536000
) festgelegt ist.
Zusammen mit Strict-Transport-Security
sollten Sie auch die upgrade-insecure-requests
-Direktive in Ihrer Content-Security-Policy
setzen. Diese weist Browser an, alle unsicheren URLs einer Seite (die über HTTP bereitgestellt werden) so zu behandeln, als wären sie über HTTPS bereitgestellt worden. upgrade-insecure-requests
ist für Websites gedacht, die viele unsichere Legacy-URLs haben, die umgeschrieben werden müssen.
Beispiele
Es wird empfohlen, sich zwei Jahre lang über HTTPS mit einer Website zu verbinden:
Strict-Transport-Security: max-age=63072000
Wenn möglich, zusätzlich Anfragen an Subdomains auf HTTPS upgraden und die Seite in die Preload-Liste aufnehmen:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Setzen Sie auch die upgrade-insecure-requests
CSP:
Content-Security-Policy: upgrade-insecure-requests;