2015-10: sicherst-mögliche Einstellungen für SSL/TLS mit Apache-Webserver
(laufende Anpassung nach dem Stand der Technik sowie u.a. BSI und ENISA Kryptorichtlinien)
SSLEngine on
- Aktivierung des SSL-Systems.
SSLCipherSuite DHE-RSA-AES256-SHA
(alternativ zusätzlich ":ECDHE-RSA-AES256-SHA" - für Elliptic-Curve, mind. Apache 2.4.x)
- ausschließlicher Einsatz:
a) Authentifizierung der Gegenstelle über RSA Public-Key-Verfahren aus X.509-Zertifikat,
b) Integritätssicherung über SHA-2 Hashverfahren,
c) Verschlüsselung der Sitzungsinhalte mit AES-Verfahren und 256 Bit Schlüssel im CBC-Modus,
d) Aushandlung des symetrischen Sitzungsschlüssels über Diffie-Hellman kurzzeitige Schlüssel inkl. PFS (Perfect Forward Secrecy).
(alternativ zusätzlich ":DHE-RSA-AES256-GCM-SHA384" - zur Unterstützung real-creepy Internet Explorer ...)
SSLProtocol TLSv1.2 -SSLv2 -SSLv3
- ausschließlicher Einsatz von TLS Version 1.2 (oder besser wie 1.3 tbd).
SSLCompression Off
- keine Verwendung von SSL- Kompression.
SSLHonorCipherOrder on
- Präferenz des Servers für die Reihenfolge von Verschlüsselungsverfahren nutzen.
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
- HTTP Strict Transport Security (siehe Wikipedia)
Server Name Indication
- bei Einsatz von Apache mit Name-Based-Virtual Hosts und pro-Host individueller TLS-Konfiguration und/oder individuellen SSL-Zertifikaten als Webserver oder Reverse Proxy bspw. ab Apache 2.2.x implizit bereits aktiviert: Apache SNI
Weshalb genau diese Konfiguration?
- kein Einsatz schwächerer bzw. vermutlich bereits gebrochener Verschlüsselungsverfahren wie RC4 oder 3DES.
- kein Einsatz schwächerer bzw. vermutlich bereits gebrochener Hashverfahren wie MD5 oder SHA-1.
- kein Einsatz schwächerer bzw. in ihrer Sicherheit für den Schlüsselaustausch nicht so klarer Public-Key Verfahren wie ElGamal/DSA.
- höchstmögliche Sicherheitsparameter für den Einsatz von AES statt kürzerer Schlüssellänge oder schwächerer Betriebsmodi (GCM, ECB - GCM im obigen Beispiel leider nötig für Internet Explorer).
- extrem wichtiger Einsatz von Perfect Forward Secrecy (PFS), erkennbar an "...DHE" (E = "ephemeral"), um selbst bei derzeitiger Speicherung von https-Daten durch Dritte wie Geheimdiensten und zukünftiger Kompromittierung des geheimen RSA-Schlüssels des Webservers keine nachträgliche vollständige Entschlüsselbarkeit sämtlicher übertragenen Dateninhalte zu riskieren. (siehe auch hier, weshalb SSL-Verschlüsselung ohne PFS quasi nutzlos ist),
-> jedoch Achtung bei DHE/Diffie-Hellmann: "How Diffie-Hellmann Fails in Practice" (Nadia Heninger, ECC 2015 Bordeaux)
- enge Vorschrift der sicheren Verfahren und TLS-Parameter zum Schutz vor Protokollangriffen durch den Webserver, da zahlreiche Clients selbst gar keine hinreichende Plausibilitätsprüfung zur https-Absicherung vornehmen und bereitwillig auch sehr unsichere Algorithmen, Schlüssellängen und Parameter aus der Vorschlagsliste wählen würden. Inbesondere durch Fähigkeiten wie QUANTUM INSERT der NSA könnten Vorschlagslisten gezielt mit schwachen Parametern gefälscht oder in ihrer Vorschlagsreihenfolge manipuliert werden.
Subjektiv verbleibt jedoch ...
- Einsatz von Elliptic Curve Cryptography (ECC), Parameter "ECDHE-RSA-AES256-SHA" - ja oder nein? Nach derzeitiger Auffassung würde die Sicherheit von Diffie-Hellmann ohne ECC selbst auch mit fallen, sollte zahlentheoretisch ECC bedeutende Schwächen aufweisen. Aber: Unter ECC liegen Kurven mit Parametern. Verschiedene Kurven wurden von der NIST spezifiziert - im Standard "Dual EC PRNG" der NIST wurden Hintertüren der NSA nachgewiesen. Empfehlung: Einsatz von ECC nur vornehmen, wenn die ECC-Kurven aus vertrauenswürdigen Quellen stammen. Bei sensiblen Anwendungen und soweit grundsätzlich überhaupt möglich, meine Empfehlung als Alternative gegen die NIST-Kurven: D.J. Bernstein: Curve25519 - soweit von Server und Browser unterstützt dann besser/nur: "ECDHE-RSA-CHACHA20-POLY1305"
- Schlüssellänge von RSA: Gängig ist die Verwendung von 2048 Bit- Schlüsseln bzw X.509- Zertifikaten. Bedingt durch die enorme Steigerung der Rechenleistung erscheinen 4096 Bit Schlüssellänge nicht unpraktikabel und bieten exponentiell höheren Schutz als 2048 Bit. Wird kein PFS zum Schutz gegen die zukünftige Entschlüsselung heute abgespeicherten https-Verkehrs eingesetzt, sind 2048 Bit Schlüssel sogar fahrlässig. Selbst das BSI empfiehlt bei Sicherungszeiten nach 2015 mindestens 3000 Bit Schlüssellänge. In einigen Publikationen wird drastisch zum Schutz vor zukünftigen kryptoanalytischen Erfolgen der pauschale Einsatz von 15000 Bit empfohlen; bspw von ENISA, um eine zu 256 Bit symmetrischen Verschlüsselungen adäquate Sicherheit zu erreichen (Diese Vergleiche sind jedoch nicht ganz unproblematisch je nach eingesetztem Kryptosystem). Bezeichnend und sicherheitstechnisch fahrlässig ist die Begrenzung einiger kommerzieller VPN- Produkte auf maximal 2048 Bit Schlüssellänge und Ausschluß oder höchst schwieriger Nutzbarkeit von PFS, die höchstens unter den Industrial-Relationship-Programmen der NSA plausibel erscheint. Empfehlung: 4096 Bit Schlüssellänge für sämtliche Einsatzzwecke, unbedingt zusätzliche Absicherung durch PFS.
- Betriebsmodi wie GCM für AES stellen einen Kompromiß zwischen Sicherheit und Performance (CPU-Belastung) dar. Eine Umstellung wie Ende 2014 bei Amazon von unsicherem RC4 auf AES128-GCM ist zwar zu begrüßen, aber angesichts der verfügbaren IT-Kapazitäten für sichere SSL-Parameter unverständlich.
- Erzeugung von Zufallszahlen: Moderne Angriffe auf Verschlüsselungssysteme setzen auf die Vorhersage verwendeter Schlüssel über kompromittierte Generatoren für die benötigten Zufallszahlen. Die ausgefeilten Möglichkeiten selbst für nicht erkennbare Manipulationen an Hardware-Zufallsgeneratoren in Prozessoren u.a. führen zu einem nachhaltigen Abraten vor nicht letztendlich prüfbaren Generatoren. Dazu gehören sämtliche Implementierungen für Zufallsgeneratoren in kommerzieller/ Closed-Software, somit konsequent nahezu sämtlich verfügbarer kommerzieller Security-Produkte wie Firewalls und VPN-Gateways sowie in Hardware wie Prozessoren. Selbst die Bereitstellung von Quellcode zur Funktionsanalyse ist unzureichend, wenn aus diesem Quellcode nicht nachweisbar unverändert die Binärdateien erzeugt werden. Empfehlung: Einsatz quelloffener Software in sensiblen Sicherheitssystemen wie Linux. Wichtig: Es sollten unbedingt die Bezüge von Zufalls-Bits/ Entropie aus Hardwarequellen abgeschaltet werden und für die Sammlung von Entropie aus Systemaktivitäten diese ausreichend sichergestellt werden.
- Die Vertrauenswürdigkeit von X.509/ SSL- Zertifikaten auf Webseiten und für andere per SSL abgesicherte Dienste wie Mailserver im allgemeinen Internet ist generell nicht (mehr) sichergestellt. Die Trustchain in Webbrowsern muß als vollständig gebrochen betrachtet werden. Die Erfahrungen erfolgreicher Hacks und auch selbst durchführbarer Tests, ob man (selbst die namhaften) Aussteller von SSL- Zertifikaten nicht täuschen kann, zeigen, daß Vertrauen in offizielle und per Trust-Chain beglaubigte SSL-Zertifikate leider nicht gerechtfertigt ist. Auch Prüfprotokolle wie OCSP für die Gültigkeit von Zertifikaten lassen sich bspw. per Fail-Open in Denial-of-Service-Plots überlisten. Empfehlung: In besonders sensitiven Umfeldern wie VPN-Systemen oder für sensible Weseitenzugriffe müssen auch Zertifikate explizit auf einem sicheren Weg vorab ausgetauscht bzw beglaubigt werden. Der Einsatz einer getrennten und damit geschlossenen privaten CA ist essentiell für die erreichbare Sicherheit. (siehe auch (leider nur TLSv1.1) )