Ich weise andere stets auf eine mangelhafte TLS Konfiguration hin und wie wichtig neue Verschlüsselungstechnologien sind. Natürlich versuche ich auf meinem Server selber die beste Mischung aus Kompatibilität und Sicherheit umzusetzen.
Protokoll
Das gegenwärtig neuste und sicherste Protokoll ist TLS 1.3. Moderne Browser bevorzugen dieses standardmässig. Daneben gibt es noch TLS 1.2 und das kaum genutzte TLS 1.1. Für etwas ältere Browser kann zusätzlich noch TLS 1.0 angeboten werden. SSL 3, SSL 2 und SSL 1 sollten wegen bekannten Schwachstellen zwingend deaktiviert werden.
Da alle älteren TLS Versionen Mängel aufweisen wäre es naheliegend, immer nur die aktuellste Version zu aktivieren. Damit würde man aber einen grossen Teil der Besucher ausschliessen, da diese einen alten Browser verwenden. Für kritische Bereiche, wie etwa Logins, wäre das aber wünschenswert.
Zertifikat
Um einen Server eindeutig identifizieren zu können werden Zertifikate verwendet. Von diesen wird üblicherweise nur der Hashwert übermittelt, deshalb sollte dieser möglichst eindeutig sein. Die gängige Praxis ist SHA256. Wenn man eine Zertifikatswarnung im Browser verhindern möchte, muss das Zertifikat von einer autorisierten Stelle signiert werden. Dafür bietet sich die freie Zertifizierungsstelle Let's Encrypt an.
Serverschlüssel
Da mit dem Serverschlüssel die Verbindungen ver- und entschlüsselt werden, sollte dieser so sicher wie möglich sein. Die meisten Server verwenden einen RSA 2048-Bit Schlüssel. 4096-Bit sind aber aus meiner Sicht zu bevorzugen. Alternativ gäbe es Schlüssel auf der Basis von x25519. Hier entsprächen bereits 256-Bits einem RSA 3072-Bit Schlüssel. Bisher unterstützten den Standard jedoch erst wenige Zertifizierungsstellen und Clients.
Cipher suites
Ähnlich wie beim Protokoll werden serverseitig auch Verschlüsselungsmechanismen angeboten. Die Auflistung sollte nach dem Sicherheitsgrad priorisiert werden. Zwar hat auch der Browser eine priorisierte Auflistung, diese ist aber nicht immer nur nach dem Sicherheitsgrad sortiert, sondern auch nach der Performance.
Die Auswahl der Cipher Suites erfolgt nach den persönlichen Kriterien auf jedem Server nahezu individuell.
Ich habe meine Cipher Suites nach den Folgenden Kriterien sortiert:
- TLS 1.3
- Forward Secrecy
- AEAD Ciphers (TLS 1.2)
- Kompatibilität
Forward Secrecy
Mit Forward Secrecy wird, statt immer den selben Schlüssels zu verwenden, laufen ein neuer Schlüssel zur Verschlüsselung verwendet. Falls der Serverschlüssel abhanden kommen oder geknackt werden sollte, können so nicht alle alten Verbindungen auf einmal entschlüsselt werden. Spätestens seit dem Bekanntwerden der Heartbleed-Lücke sollte jedem die Notwendigkeit von Forward Secrecy bewusst sein.
BEAST vs. RC4
RC4 war ein sehr beliebter Verschlüsselungsmechanismus, da er den BEAST Angriff unter TLS 1.0 verhindern konnte. Gleichzeitig war RC4 sehr schnell und mit allen Clients kompatibel. RC4 galt schon länger als unsicher und wurde deshalb nur als Fallback für ältere Clients eingesetzt. Inzwischen sind praktische Angriffe auf RC4 bekannt und damit gilt die Empfehlung, RC4 zu Gunsten von BEAST zu deaktivieren.
Aus diesem Dilemma gibt es eigentlich nur einen möglichen Ausweg: Wenn alte Browser nicht unterstützt werden sollen, sollte TLS 1.0 deaktiviert werden. Damit wird der BEAST Angriff unterbunden.
Kompatibilität
Um sicherheitsbewussten Nutzern, welche die Liste akzeptabler CIpher Suites im Browser selber konfigurieren, einen möglichst grossen Spielraum zu bieten, habe ich möglichst alle als sicher geltenden Cipher Suites im Angebot.
Weitere Features
Neben dem Bisherigen gibt es diverse weitere Features, mit denen man eine weitere Sicherheitsstufe erreicht.
Strict Transport Security
Mit dem HSTS-Header weist man den Browser an, keine unverschlüsselten Verbindung von dieser Domain zu akzeptieren. Dies ist zusätzlicher Schutz gegen Session-Hijacking oder MITM-Angriffe Die Voraussetzung dafür ist, dass das die Seite komplett über https erreichbar ist.
Der HSTS-Status dieser Seite ist preloaded, dass heisst, meine Domain ist bereits im Code moderner Browser vermerkt, dass die Seite nur über https aufgerufen werden soll.
Public Key Pinning
Der Public Key meines Server Zertifikates, sowie meines Backup-Zertifikates ist im HPKP-Header enthalten. Der Browser merkt sich diesen Schlüssel beim ersten Besuch. Wenn das Zertifikat ausgetauscht oder gefälscht würde, schlägt der Browser Alarm.
Content Security Policity
Mit dem CSP-Header kann dem Browser mitgeteilt werden, von wo er Ressourcen laden darf. Grundsätzlich soll er dies nur von der eigen Domain können. Bei Bildern oder Videos kann es notwendig sein, dass diese auch von ausgewählten Domains geladen werden können, oder sogar immer, solange eine sichere Verbindung besteht (https). Damit wird auch Mixed Content serverseitig blockiert.
Dank dem Parameter unsafe-inline könnten auch XSS-Angriffe oder CSS-Injection vollständig verhindert werden. Leider sind viele Webapplikationen auf diese Funktionen angewiesen. Für sensible Seiten wäre es aber den Aufwand wert, die nötigen Vorkehrungen zu treffen.
OCSP Must Staple
Falls einem Zertifikat das Vertrauen entzogen wird, muss dies den Clients möglichst rasch mitgeteilt werden. Dafür gibt es das OCSP Protokoll. Der Client fragt damit die Zertifizierungsstelle nach dem aktuellen Gültigkeitsstaus für das Zertifikat. Leider ist diese Überprüfung optional und wird aus Performancegründen oft ganz ignoriert. Nur mit der "Must Staple" Erweiterung kann diese Überprüfung in modernen Browsern erzwungen werden.
Certificate Transparency & CAA
Zertifizierungsstellen haben eine grosse Macht die auch missbraucht werden kann. Aus diesem Grund zeichnet Let's Encrypt alle ausgestellten Zertifikate auf. Diese Aufzeichnungen können öffentlich eingesehen werden. Mit einem CAA Eintrag im DNS kann man andere Zertifizierungsstellen zusätzlich bitten, keine Zertifikate für diese Domain auszustellen. Eine vollständige Sicherheit kann jedoch nur Public Key Pinning bieten.
Um die eigene TLS Konfiguration zu testen empfehle ich den Test von SSL Labs.