beim Experimentieren mit der Einrichtung von OpenVPN stieß ich aufdieser Tipp auf einer Website. dort steht, dass man die Liste der Chiffren begrenzen kann, um Downgrade-Angriffe zu verhindern. Ich habe es in einem LAN mit 2 Computern getestet, auf beiden lief ein Kubuntu 14.04 mit OpenVPN 2.3.2.
in der server.conf auf dem OpenVPN-Server habe ich diese Zeile eingefügt
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
Durch Ausführen openvpn --show-tlsund Vergleichen der Ausgabe habe ich sichergestellt, dass jede der Chiffren in der obigen Zeile meiner Version von OpenVPN (sowohl auf dem Server als auch auf dem Client) bekannt ist.
aber wenn ich den OpenVPN-Server und anschließend den Client starte, gibt mir der Server folgende Ausgabe
Fri Sep 25 12:31:59 2015 "THECLIENTSIP":38749 TLS: Initial packet from [AF_INET]"THECLIENTSIP":38749, sid=d9c33d37 653b2f0e Fri Sep 25 12:32:00 2015 "THECLIENTSIP":38749 TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher Fri Sep 25 12:32:00 2015 "THECLIENTSIP":38749 TLS Error: TLS object -> incoming plaintext read error Fri Sep 25 12:32:00 2015 "THECLIENTSIP":38749 TLS Error: TLS handshake failed Fri Sep 25 12:32:00 2015 "THECLIENTSIP":38749 SIGUSR1[soft,tls-error] received, client-instance restarting
ohne diese TLS-Verschlüsselungsoption funktioniert es einwandfrei.
ich verstehe nicht, warum da steht „keine gemeinsame Chiffre“. Ist es falsch, die Chiffren durch Doppelpunkte getrennt aufzulisten? Oder wo liegt hier das Problem?
Danke fürs Lesen. Ich hoffe, dass mir jemand helfen kann.
bearbeiten
ich habe die Zeile in server.conf durch ersetzt,
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
um zu sehen, was passiert. und die Ausgabe des OpenVPN-Servers ist dieselbe.
bearbeiten 2
ich habe weiter gesucht und diese Seite gefundenhttps://community.openvpn.net/openvpn/wiki/Hardening
und jetzt habe ich verstanden, dass OpenVPN 2.3.2 nur SSLv3/TLSv1.0-Chiffresuites unterstützt. openvpn --show-tlszeigt aber auch TLSv1.2-Chiffresuites an
Die Beschränkung auf TLSv1.0 DHE + RSA-Auswahlmöglichkeiten ergibt die folgende Liste, die für <=2.3.2-Peers geeignet ist. DES-Auswahlmöglichkeiten sollten am besten vermieden werden, insbesondere Single-DES (bekannt als sehr schwach).
TLS-DHE-RSA-MIT-AES-256-CBC-SHA
TLS-DHE-RSA-MIT-CAMELLIA-256-CBC-SHA
TLS-DHE-RSA-MIT-3DES-EDE-CBC-SHA
TLS-DHE-RSA-MIT-AES-128-CBC-SHA
TLS-DHE-RSA-MIT-SEED-CBC-SHA
TLS-DHE-RSA-MIT-CAMELLIA-128-CBC-SHA
TLS-DHE-RSA-MIT-DES-CBC-SHA
Vermeiden Sie alle DES-Chiffre-Suiten: DES ist bekanntermaßen sehr schwach (3DES-EDE ist immer noch in Ordnung). Vermeiden Sie alle RC4-Chiffre-Suiten: RC4 ist bekanntermaßen schwach. Vermeiden Sie alle EXPORT-Chiffre-Suiten: EXPORT wurde schon vor vielen Jahren als schwach spezifiziert.
und es funktioniert, wenn ich eine dieser Chiffren in der server.conf verwende, zB
tls-cipher TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
leider steht auf der Seite nicht, wie ich das genau selbst erreichen kann ... weiß das jemand?
da TLSv1.0 SSLv3 ist und OpenVPN angibt, dass es OpenSSL verwendet, habe ich versucht, diese Informationen über OpenSSL abzurufen und mit grep zu filtern,
openssl ciphers -v | grep SSLv3 | grep Kx=DH
aber die Ausgabe ist anders (zum Beispiel erscheint das Wort WITH nicht in dieser Liste)
In der Annahme, dass es vielleicht nur einen Unterschied in der Notation gibt, habe ich versucht, einen Teil des Textes durch Sed
openssl ciphers -v | grep SSLv3 | grep Kx=DH | grep DHE-RSA | sed 's/DHE-RSA/TLS-DHE-RSA-WITH/g' | awk '{print $1}'
-Ausdrucke zu ersetzen:
TLS-DHE-RSA-WITH-AES256-SHA TLS-DHE-RSA-WITH-CAMELLIA256-SHA TLS-DHE-RSA-WITH-AES128-SHA TLS-DHE-RSA-WITH-SEED-SHA TLS-DHE-RSA-WITH-CAMELLIA128-SHA
aber das ist immer noch nicht dasselbe wie die Liste im Artikel „Hardening openvpn“ und ich bin mir nicht sicher, ob das überhaupt der richtige Weg ist …
auf dieser SeiteDie Verwendung von DHE-RSA-AES256-SHA wird empfohlen. Ich gehe also davon aus, dass die sicherste TLS-Verschlüsselung, die ich mit OpenVPN 2.3.2 verwenden kann, TLS-DHE-RSA-WITH-AES-256-CBC-SHA ist. Aber diese Antwort ist von November 2013. Ist das immer noch die beste Wahl? Aus irgendeinem Grund ist das jetzt eine andere Frage. Aber hier geht es darum, die sicherste TLS-Verschlüsselungsoption zu finden.
bearbeiten 3 ok, ich könnte diesen openssl-grep-sed-Befehl erweitern
openssl ciphers -v | grep SSLv3 | grep Kx=DH | grep DHE-RSA | sed 's/DHE-RSA/TLS-DHE-RSA-WITH/g' | sed 's/SHA/CBC-SHA/g'| awk '{print $1}'
Drucke:
TLS-DHE-RSA-WITH-AES256-CBC-SHA TLS-DHE-RSA-WITH-CAMELLIA256-CBC-SHA TLS-DHE-RSA-WITH-AES128-CBC-SHA TLS-DHE-RSA-WITH-SEED-CBC-SHA TLS-DHE-RSA-WITH-CAMELLIA128-CBC-SHA
Jetzt ist es dieselbe Liste wie in diesem Artikel ohne den DES- und 3DES-Eintrag.
ist das jetzt also das richtige Ergebnis? Denn diese Lösung basiert nur auf der Annahme, dass es nur einen Unterschied in der Notation zwischen der Ausgabe des Befehls openssl -v und dem Befehl openvpn --show-tls gibt.
bearbeiten 4 Nein, tut mir leid, es war nicht die gleiche Liste wie in dem Artikel ohne den DES- und 3DES-Eintrag. Jetzt ist es so:
openssl ciphers -v | grep SSLv3 | grep Kx=DH | grep DHE-RSA | sed 's/DHE-RSA/TLS-DHE-RSA-WITH/g' | sed 's/SHA/CBC-SHA/g'| sed 's/AES/AES-/g' | sed 's/CAMELLIA/CAMELLIA-/g' | awk '{print $1}'
Drucke:
TLS-DHE-RSA-WITH-AES-256-CBC-SHA TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA TLS-DHE-RSA-WITH-AES-128-CBC-SHA TLS-DHE-RSA-WITH-SEED-CBC-SHA TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
aber das ist ein ziemlicher Irrweg, oder? Und es funktioniert nur so, wenn die Liste der Chiffrennamen nicht wächst.
Entschuldigen Sie, wenn die „Frage“ verwirrend sein könnte … bitte kommentieren Sie, vielen Dank, wenn Sie sich zumindest die Zeit genommen haben, dies zu lesen!
Antwort1
Ich glaube nicht, dass OpenVPN ECDHE bereits unterstützt. Ich habe OpenVPN 2.3.4 auf Debian 8.3 (stabil) und 2.3.10 auf Debian als Testserver ausprobiert, und keines von beiden funktioniert, wenn TLS-Cipher mit einer ECDHE-Ciphersuite angegeben ist und eine Verbindung von einem Windows-Client mit 2.3.10 hergestellt wird. Bisher funktionieren nur DHE-Ciphers.