1. Verschlüsselung mit Niveau
Mit einer ordentlichen Portion Populismus berichten Massenmedien über den Untergang der Kryptographie – die NSA sei in der Lage selbst verschlüsselte Kommunikation mitzulesen. SSL– und VPN-Technik scheint nutzlos gegen den übermächtigen Gegner, der alles und jeden ausspionieren möchte.
Da findet zusammen, was zusammen gehört: Gefährliches Halbwissen, gepaart mit unnötiger Dramatik und Sensationslust. Entscheidende Tatsachen werden allerdings verschwiegen oder nur unzureichend erklärt.
Fakt ist: Die Technik für den Schutz gegen die Ausspähung ist vorhanden – allerdings nutzt sie kaum jemand. Mit Perfect Forward Secrecy und ausgewählten Cipher Suiten kann Apache und nginx in Form gebracht werden!
2. SSL und VPN geknackt?
Laut den jüngsten Enthüllungen soll der US-Geheimdienst NSA und der britische GCHQ in der Lage sein, verschlüsselte Verbindungen mitzulesen. Allerdings ist dabei völlig unklar, welche Art von verschlüsseltem Verkehr tatsächlich mitgelesen werden kann. Pauschal wird also davon ausgegangen, SSL und VPN sei geknackt und könne somit entschlüsselt werden. Ist das tatsächlich so? Ein Blick hinter die SSL-Kulissen sorgt für Aufklärung.
Unterstütze den Blog mit einem Dauerauftrag!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Secure Sockets Layer
Weitläufig unter dem Begriff Secure Sockets Layer (SSL) bekannt, dient das Protokoll als Verschlüsselungsmethode zwischen zwei Endpunkten zum sicheren Austausch von Daten. Hauptsächlich wird SSL für die Absicherung zwischen Webbrowser und Webserver eingesetzt – also immer dann, wenn sensible Informationen über das unsichere Internet ausgetauscht werden sollen. Mittlerweile wurde SSL vom Nachfolger Transport Layer Security (TLS) abgelöst – der Name SSL findet allerdings weiterhin Verwendung.
Für die Absicherung der Kommunikation nutzt TLS/SSL verschiedene Verschlüsselungsverfahren, die sich stark in ihrer kryptographischen Leistungsfähigkeit unterscheiden. Im Prinzip lässt sich jedes Kryptosystem mit genügend Rechenkraft knacken. Die Berechnungsdauer steht dabei in direkter abhängig von der verwendeten Schlüssellänge und dem Verschlüsselungsverfahren.
2.2 Verschlüsselungsverfahren
Bei der Benutzung von SSL existieren eine Vielzahl an Kombinationsmöglichkeiten, bei welchen es enorme Unterschiede in der Sicherheit zu verzeichnen gibt. Bevor eine verschlüsselte Kommunikation zwischen zwei Partnern erfolgt, wird zunächst eine Chiffriermethode (Cipher-Suite) zwischen den Teilnehmern ausgehandelt. Dazu schickt der Browser/Client eine Liste von möglichen Cipher-Suiten an den Server, die von seiner Seite aus eine verschlüsselte Kommunikation erlaubt. Der Server wiederum selektiert aus diesem Angebot eine Cipher-Suite, die er ebenfalls beherrscht. Vereinfacht ausgedrückt besteht solch eine Cipher-Suite aus folgenden Elementen:
- Eine asymmetrische Verschlüsselung, zum sicheren Austausch des Schlüssels zwischen Client und Server, Authentifikation oder beidem
- Ein symmetrisches Verfahren für die Verschlüsselung der eigentlichen Kommunikation
- Eine Hashfunktion, welche die Integrität der Daten sicherstellt
Je nach verwendeter Cipher-Suite ergeben sich schließlich starke Abweichungen bezüglich der Sicherheit. Beispielsweise besteht ein großer Unterschied zwischen der Cipher-Suite TLS_RSA_WITH_RC4_128_MD5 und ECDHE-RSA-AES256-GCM-SHA384.
Im Detail besteht TLS_RSA_WITH_RC4_128_MD5 aus folgenden Elementen:
- Zum sicheren Austausch des Schlüssels zwischen Client und Server und zur Authentifikation wird RSA verwendet
- Für die Verschlüsselung der Kommunikation wird RC4 eingesetzt
- Die Integrität der Daten wird mit MD5 sichergestellt
Im Gegensatz dazu verwendet die Cipher-Suite ECDHE-RSA-AES256-GCM-SHA384 folgende Elemente:
- Zum sicheren Austausch des Schlüssels zwischen Client und Server wird auf das Diffie-Hellman Schlüsselaustauschverfahren auf Basis elliptischer Kurven gesetzt
- Zur Authentifikation wird RSA verwendet
- Für die Verschlüsselung der Kommunikation wird AES mit GCM eingesetzt
- Die Integrität der Daten wird mit SHA-2 sichergestellt
Einzelne Elemente der ersten Cipher-Suite (TLS_RSA_WITH_RC4_128_MD5) gelten als unsicher bzw. bereits geknackt. Dazu zählt die RC4 Stromchiffre und das Hashverfahren MD5. Durch das Sammeln mehrere Gigabyte an Kommunikationsdaten soll es möglich sein, RC4 zu knacken. Dan Bernstein hat dies in einer Präsentation Anfang des Jahres deutlich gemacht. Da die NSA über mehr finanzielle Mittel und ebenfalls Manpower verfügt, kann RC4 daher als unsicher und geknackt angesehen werden.
Ob die NSA die SSL-Kommunikation mitlesen kann, hängt also ganz entscheidend von der ausgehandelten Cipher-Suite zwischen Client und Server ab. An vielen Stellen werden veraltete Algorithmen verwendet, die nicht mehr dem Stand der Technik entsprechen und als unsicher gelten. Dies gilt es zu ändern!
2.3 Welche Cipher-Suiten sind jetzt sicher?
Über die letzten Jahre gab es viele Angriffe auf TLS/SSL und häufig genutzte Cipher-Suiten, wie beispielsweise solche mit RC4. Angreifer fanden oftmals Schwachstellen in Algorithmen der Verschlüsselungsverfahren, was zu einer Reduktion der Berechnungszeit der Schlüssel führte.
Bekannte Angriffsverfahren sind BEAST, Lucky Thirteen, und die RC4-Weakness. Ebenfalls bedenkenswert ist die Möglichkeit TLS-Kommunikation auszuspähen, die mit Kompressionsverfahren in der Übertragungsgröße reduziert werden. Mit CRIME oder BREACH sind entsprechende Ansätze vorhanden.
In Anbetracht dieser Angriffsverfahren muss eine TLS-Cipher-Suite folgende Eigenschaften aufweisen:
- Die Cipher-Suite muss in weiten Teilen der gängigen Kryptobibliotheken bereits implementiert sein. (zb. OpenSSL Project)
- Es muss sich um Verschlüsselungsverfahren handeln, die bereits in einem ausreichenden Maß analysiert wurden.
- Weiterhin muss das Verfahren von unabhängigen, einschlägig bekannten Institutionen standardisiert sein.
- Das Schlüsselaustauschverfahren sollte auf Diffie-Hellman basieren. Mittels Perfect Forward Secrecy (PFS) kann verhindert werden, dass eine in der Vergangenheit verschlüsselt aufgezeichnete Kommunikation durch Bekanntwerden des geheimen Schlüssels wieder entschlüsselt werden kann.
Für TLS/SSL Verbindungen sollten also letztendlich Cipher-Suiten eingesetzt werden, die sich aus folgenden Elementen zusammensetzt:
- DHE oder ECDHE als Schlüsselaustauschverfahren.
- RSA oder ECDSA als Signaturverfahren zur Sicherstellung der Authentizität
- Die eigentliche Kommunikation wird mit AES-GCM 128-Bit oder besser symmetrisch verschlüsselt. GCM Block-Verschlüsselung als Antwort auf den Lucky Thirteen Angriff.
- SHA-2 (Empfehlung: 384 Bit oder besser) als Hashfunktion, für die Sicherstellung der Datenintegrität.
Übrig bleiben also eine Handvoll Cipher-Suites, die mittlerweile alle in der OpenSSL Bibliothek (1.0.1+) implementiert sind:
- ECDHE-ECDSA-AES256-GCM-SHA384
- ECDHE-ECDSA-AES128-GCM-SHA256
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
- DHE-RSA-AES256-GCM-SHA384
- DHE-RSA-AES128-GCM-SHA256
- …
AES128 Bit wackelt derzeit ganz leicht, aber noch sind wir weit von einem praktikablen Angriff entfernt. Mit ausreichend finanziellen Mitteln (ca. 80 Milliarden) und dem Strombedarf der gesamten USA, inklusive Kanada und Lateinamerika soll sich AES berechnen lassen – jedenfalls die 128-Bit Variante. Noch ist das mehr als utopisch, wer auf Nummer sicher gehen möchte, nimmt die AES192 Bit Variante.
Update
14.09.2013: In einem Entwurf hat das Internet Engineering Task Force (IETF) die Nutzung von TLS 1.2 bekräftigt und empfiehlt unter anderem folgende SSL-Cipher-Suiten:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
2.4 Und die NSA?
Die NSA verfügt über ausreichend finanzielle Mittel und mit hoher Wahrscheinlichkeit auch über die notwendige Manpower, allerdings ist die Wahrscheinlichkeit verschwindend gering, dass die oben dargestellten TLS/SSL Cipher-Suiten derzeit geknackt werden können.
Wenn wir also von geknackten SSL-Verbindungen sprechen, dann sollten wir dies auf Cipher-Suiten beschränken, die aufgrund ihrer Schwachstellen als unsicher gelten. Neben unsicheren Cipher-Suiten sind allerdings weitere Aspekte bedenkenswert, da die NSA mit Sicherheit weitere Möglichkeiten nutzt, um verschlüsselte Verbindungen mitzulesen:
- Amerikanische Firmen verfügen per Gesetz über Hintertüren in Anwendungen und Diensten. Da macht selbst die beste Verschlüsselung wenig Sinn. Bis auf weiteres ist US-amerikanischen Unternehmen nicht zu trauen.
- Die NSA nimmt seit Jahrzehnten Einfluss auf Verschlüsselungsverfahren. Sie wirken bewusst auf Designschwächen hin, um Algorithmen gezielt zu entkräften. Unter anderem wurde das National Institute of Standards and Technology (NIST) unterwandert.
- Zertifizierungsstellen (certificate authority, CA) gibt es wie Sand am Meer. Die CAs verteilen sich auf verschiedene Länder und oftmals ist nicht nachvollziehen, wer eigentlich dahinter steckt. Vertrauenswürdigkeit sieht leider anders aus. Des Weiteren bleibt weiterhin unklar inwieweit die Zertifizierungsstellen von der NSA kontrolliert werden.
- Leider nutzt auch die beste Verschlüsselung nichts, wenn sich die NSA gezielt Zugriff auf Systeme verschafft. Sicherheitslücken und nicht gepachte Systeme begünstigen dieses Vorhaben.
Dennoch ist festzuhalten: Die reine TLS/SSL Technik ist als »sicher« einzustufen, falls Client- wie auch serverseitig starke Cipher-Suiten eingesetzt werden.
3. Apache und nginx Konfiguration
Mittels Perfect Forward Secrecy (PFS) soll verhindert werden, dass eine in der Vergangenheit verschlüsselt aufgezeichnete Kommunikation durch Bekanntwerden des geheimen Schlüssels wieder entschlüsselt werden kann. PFS wird erst ab einer bestimmten Version von den beiden Webservern unterstützt. Entscheidend ist ebenfalls die zugrundeliegende SSL/TLS Bibliothek. Folgende Voraussetzungen müssen demnach auf einem Linux-System erfüllt sein:
- OpenSSL 1.0.1c+++
- Apache 2.4.x+++
- nginx 1.0.6+++
Nach Installation der neuen Programmversionen sind lediglich zwei weitere Konfigurationsschritte notwendig:
- Konfiguration der PFS-Funktion.
- Korrekte Anwendung der Cipher-Suiten.
3.1 Konfiguration Apache
Update
04.05.2018: Aktualisierung der Apache- und nginx-Konfiguration.SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH SSLHonorCipherOrder on # Apache >= 2.4 SSLCompression off SSLUseStapling on
3.2 Konfiguration nginx
ssl_protocols TLSv1.2; ssl_prefer_server_ciphers on; 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';
Hinweis: TLS/SSL Kompression ist bei nginx standardmäßig deaktiviert und muss über einen Compile-Paramter integriert werden. Das ist aufgrund von CRIME oder BREACH allerdings nicht empfehlenswert.
3.3 Client-Probleme / Abwärtskompatibilität
Um herauszufinden, welche Cipher-Suiten mit der oben dargestellten Auswahl unterstützt werden, genügt ein Terminal-Befehl:
openssl ciphers -v 'EECDH+AESGCM EDH+AESGCM !aNULL !eNULL !EXPORT !LOW !MEDIUM !DES !3DES !RC4 !SEED !CAMELLIA !MD5 !PSK !DSS
Leider unterstützen viele Browser bzw. Clients diese neuen Cipher-Suiten (noch) nicht. Wir erinnern uns: Zu Beginn schickt der Client eine Liste von möglichen Cipher-Suiten an den Server. Der Server wiederum selektiert aus diesem Angebot eine Cipher-Suite, die er ebenfalls beherrscht. Falls der Client dem Server also eine Liste mit veralteten Cipher-Suiten schickt und der Server diese seinerseits NICHT unterstützt, wird keine SSL-verschlüsselte Kommunikation initiiert. Ein typisches Problem der Abwärtskompatibilität.
Welche Cipher-Suiten von einem Browser unterstützt werden kann auf der Webseite SSL/TLS Client Test geprüft werden. Firefox in der Version 23.0.1 unterstützt demnach Folgende:
Firefox unterstützt in der aktuellen Version noch kein Galois/Counter-Modus (GCM). Demnach werden sich Client und Server auf keine Cipher-Suite einigen können. Als Folge wird der Client eine Fehlermeldung folgender Art erhalten:
Aus Gründen der Abwärtskompatibilität kann es also tatsächlich notwendig sein, außer den TLS 1.2 Cipher-Suiten noch weitere zuzulassen.
3.4 Das geringere Übel: CBC oder RC4?
In der Vergangenheit wurde RC4 oftmals empfohlen, um BEAST und Lucky Thirteen in CBC-Blockchiffren zu vermeiden. Allerdings gilt diese Empfehlung heute nicht mehr, da die Schwächen von CBC in allen gängigen SSL-Implementierungen behoben sind. Somit gelten BEAST, als auch Lucky Thirteen derzeit als behoben bzw. abgeschwächt – vorausgesetzt es werden neue SSL-Bibliotheken (OpenSSL 1.0.1+) verwendet. RC4 gilt demnach als schlechtere Wahl für die Gewährleistung der Abwärtskompatibilität.
Folglich sind folgende Cipher-Suiten empfehlenswert:
openssl ciphers -v 'EECDH+AESGCM EDH+AESGCM EECDH EDH !aNULL !eNULL !EXPORT !LOW !MEDIUM !DES !3DES !RC4 !SEED !CAMELLIA !MD5 !PSK !DSS'
Somit ergibt sich für Apache:
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH SSLHonorCipherOrder on # Apache >= 2.4 SSLCompression off SSLUseStapling on
nginx:
ssl_protocols TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers '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';
3.5 Abschlusstest
Auf Qualys SSL Labs lassen sich TLS/SSL Serverkonfigurationen auf verschiedene Kriterien prüfen. Mit der erweiterten Cipher-Liste (+Abwärtskompatibilität) wird folgendes Ergebnis erzielt:
Die Handshake-Simulation ergibt:
In der Zusammenfassung bedeutet das:
- Perfect Forward Secrecy wird unterstützt. Es werden lediglich Cipher-Suiten eingesetzt, die auf Basis des Diffie-Hellman Verfahrens einen Schlüsselaustausch vornehmen.
- RC4 wird nicht verwendet. Somit ist es auf Windows XP in Verbindung mit dem Internet Explorer (IE6, IE8) nicht möglich, eine SSL-verschlüsselte Verbindung zum Server aufzubauen.
- Die DHE-Cipher-Suiten garantieren ebenfalls Abwärtskompatibilität, da beispielsweise ältere Versionen von Opera noch keine elliptischen Kurven bzw. ECDHE-Cipher unterstützen.
- CBC wird aus Gründen der Abwärtskompatibilität RC4 vorgezogen.
4. Fazit
TLS/SSL ist nicht geknackt! Ob die NSA die SSL-Kommunikation mitlesen kann, hängt ganz entscheidend von der ausgehandelten Cipher-Suite zwischen Client und Server ab. Aktuelle Versionen von Apache, nginx und den SSL-Bibliotheken vorausgesetzt, kann serverseitig das notwendige Maß an Sicherheit erzwungen werden – auch wenn dabei manch alter Client auf der Strecke bleibt. Sicherheit mag in vielen Fällen wichtiger sein, als eine Abwärtskompatibilität bis in das letzte Jahrhundert zu gewährleisten. Dennoch sollte eines nicht vergessen werden: Vor einer generellen Ausspähung hilft die simple Umstellung auf sichere Cipher-Suiten nicht. Es ist lediglich ein kleines Puzzelteil im Kampf gegen den schier übermächtigen Gegner.
Die NSA-Affäre hat mittlerweile groteske Züge angenommen. Demnach will die NSA den Internetverkehr nicht nur dekodieren können, sondern wirkt gezielt auf die Abschwächung von Verschlüsselungsstandards ein. Doch die deutsche Politik hält weiterhin an der Vogel-Strauß-Taktik fest. Weiterhin gelten Überwachungs- und Abhörtechnik auf deutschem Boden als exterritoriale Gebiete – also im Falle der NSA als amerikanischer Boden auf deutschem Grund. Infolgedessen ist es also egal, was die Geheimdienste in ihren Gebäuden tun, denn sie tun dies per Definition nicht auf deutschem Boden.
Bildquellen:
Sicheres Schloss: „#54117762“, https://de.fotolia.com/id/54117762
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Postfix: TLS-Konfiguration mit ECDSA- / RSA-Zertifikaten
Postfix: ECDSA / RSA-Keys und TLS-Konfiguration
ejabberd: Installation und Betrieb eines XMPP-Servers
Perfect Forward Secrecy mit Apple Mail?
Unsichere SSL-Verschlüsselung im Browser abschalten
14 Ergänzungen zu “NSA abhörsichere SSL-Verschlüsselung für Apache und nginx”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit.
Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
HTTPS/SSL hat die NSA an sich nicht geknackt. Das Problem liegt eher in der Windows-Zertifikatmanager.
Wenn ich eine Webseite mit einem SSL-Zertifikat benutze, dann speichert Windows genau dieses Zertifikat auf meinem Rechner, um für die Zukunft einen schnelleren Zugriff zu benötigen. Allerdings kann Windows die Zertifikate auch jederzeit durch andere Zertifikate ersetzen. Der Hintergrund dabei war, dass Zertifikate ablaufen können und der Benutzer dann einen Zugriffsfehler aufgrund des abgelaufenen Zertifikates bekommt. In diesem Fall soll das Zertifikat von Windows einfach durch das neue ersetzt werden können.
Hier allerdings ist auch die Sicherheitslücke, die der NSA den Zugriff auf SSL-verschlüsselte Daten gewährt, denn die NSA ist in der Lage (oder sogar berechtigt, man weiß es nicht), auf fremden Rechnern diese Zertifikate auch auszutauschen. Der User bekommt von der Zertifikatverwaltung bei einer Aktualisierung allerdings kein Feedback.
Stelle ich nun eine Verbindung zu einer verschlüsselten Webseite, beispielsweise meiner Bank her, fragt mein Browser nun das Sicherheitszertifikat einmal ab und speichert es.
Tauscht die NSA nun dieses Zertifikat aus, kann sie damit eine Man-in-the-Middle Attacke ausführen, indem sie den Traffic mit einem ausgetauschten Zertifikat zwischen sich und meinem Rechner verschlüsselt – dieser Traffic lässt sich für die NSA logischerweise im Klartext lesen – und den Traffic dann mit dem echten Bankzertifikat an meine Bank weiterleitet.
Das Problem liegt also eher an der Windows-Zertifikatsverwaltung. Der Internet Explorer und meines Wissens nach auch Chrome greifen auf diese zurück. Lediglich Firefox ignoriert diese Sammlung von Windows komplett und greift auf eine Zertifikatprüfmethoden zurück.
SSL ist also nicht genackt. Eher wurden Lücken in der Windows-Zertifikatsverwaltung ausgenutzt.
Hallo,
vielen dank erstmal für den artikel.Aus meiner sicht eine gute zusammenfassung der aktuellen lage.
Eine Sache möchte ich jedoch zur diskussion stellen: aus kryptografischer sicht ist es fragwürdig,ob der Schlüsselaustausch über ECDHE geschehen soll.Laut bruce schneier scheint es besser zu sein den einfachen DH zu benutzen. Das macht aus meiner sicht auch sinn,denn es ist nicht klar,welche rolle die NSA bei der festlegung von kurvenparametern hat. Beim einfachen DH,dessen Sicherheit auf dem DLP beruht, gibt es diesbezüglich keine probleme.
Grüße
Marcel
Im Prinzip kann Camellia verwendet werden. AES und Camellia haben einige Ähnlichkeiten.
Sehr guter Artikel, danke hierfür.
Mich Interessiert die Thematik aber aus einer anderen Perspektive.
Wie kann ich als Client nur bestimmte Methoden dem Server anbieten um möglichst nur die sicheren (unterstützten) zu verwenden?
Als Client hat man leider wenig Chancen. Im Grunde muss man sich auf die Vorgabe / Implementierung der Programmierer verlassen.
theoretisch könnte man einen lokalen proxy laufen lassen, der nur die sicheren cipher, pfs und tls1.2 kann. dann musst du in jeder anwendung oder os-environment diesen lokalen proxy setzen.
der artikel gefällt mir auch. gute zusammenfassung.
Hi,
super Artikel, vielen Dank dafür, spart viel eigene Recherche.
Haben sie zufällig auch die Config für einen Tomcat auch parat ?
Der ist nämlich noch ein Stück ätzender zu konfigurieren.
Beste Grüße
S Juerges
Leider nein.
Hi, nach extensivem rumtesten folgende Erkenntniss bzgl. Tomcat:
Tomcat 6 / Java 6 kann max. bis TLSv1.1, und PFS schlägt grösstenteil fehlt.
Kommt also nicht in Frage.
Die (aktuelle) Kombination
Tomcat 7 + Java 7 + APR 1.4.8 + libtcnative 1.1.27
mit der folgenden Kofiguration ist ein Kompromiss aus grösstmöglicher Kompatibilität (niemand wird ausgeperrt) und Sicherheit (PFS wo möglich):
Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" sslProtocol="TLSv1.1" sslEnabledProtocols="TLSv1.1" SSLCipherSuite="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA +AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS:@STRENGTH" SSLCertificateFile="/etc/ssl/private/cert.crt" SSLCertificateKeyFile="/etc/ssl/private/cert.key"Habe die im Artikel empfohlene „erweiterte Cipher (+Abwaertskompatibilitaet)“
auf Apache eingerichtet.
Geht einwandfrei mit Firefox 27.0.1 auf Win7 64-Bit, der verwendet „TLS_DHE_RSA_WITH_AES_256_CBC_SHA, 256-Bit Schluessel“.
Geht auch einwandfrei mit dem neuesten Firefox Mobile auf dem neuesten Android tablet.
Bloss der IE 11 auf Win7 64-Bit, der meint jetzt nur noch „Die Seite kann nicht angezeigt werden“. Ging aber vor der Ciphre-Anpassung noch.
Kann es sein dass der IE das nicht kann? Wie kann ich den unterstützen?
Ich habe den IE11 auf Windows 7 (32bit) nur durch zulassen von 3DES auf grün bekommen, obwohl er eigentlich auch andere kann. Dann aber meckert der Test an, dass meine Config unsichere Verschlüsselungen zulässt.
Hi Mike,
ich habe hier auch das Problem, das Win7 mit IE11 mit der SSLCipherSuite „EECDH+AESGCM EDH+AESGCM EECDH -RC4 EDH -CAMELLIA -SEED !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4“ nicht die Website anzeigt, er scheint gar keine Session zustande zu bringen. Habe auch mal die 3DES cipher zugelassen dann geht es. Hättest du da noch einen Tip für uns? Vielen Dank.
PS: Top Seite, wirklich klasse, weiter so!
Hi,
für Apache kann ich folgende Konfiguration sehr empfehlen:
Damit ist man ebenfalls auf der sichereren Seite und auch „ältere“ Systeme kommen noch mit.
Gruß
Ihon
Danke für die Schnippsel :)
Was hat es mit „Incorrect SNI alerts“ auf sich?
Hier eine minimale Erweiterung die ebenfalls in der Apache2-Konfiguration landen darf ;)
Header always set Strict-Transport-Security „max-age=63072000; includeSubdomains; preload“