Weil mich die Frage einerseits selber sehr interessiert und andererseits auch vor dem Hintergrund, dass ich mein OpenVPN-Setup auf meiner Web-Seite veröffentlicht habe (man sollte dabei ja tunlichst versuchen zu vermeiden, totalen Mist zu erzählen) habe ich mich noch weiter mit dem Thema befasst... und bin für mich und meine Bedürfnisse zu folgenden Schlüssen gekommen.sergej2018 hat geschrieben:03.11.2019 15:05:18Habe vorhin mal ausprobiert und festgestellt, dass 8192 bit mit openVPN mittlerweile gut funktionieren
Vorab bemerkt konnte ich allerdings feststellen, dass es ab einem gewissen Level wirklich schwieriger wird, Antworten zu bekommen oder zu finden. Egal, ich glaube, ich konnte trotzdem genügend Informationen sammeln, um jetzt belastbare Entscheidungen treffen zu können. Für mich ist hier an dieser Stelle dieses Postings deshalb nur eins wichtig: Widerspruch! Und zwar gerne hier von den Fachleuten. Es ist ja schließlich nicht wirklich zielführend, sich da selber irgendwas zusammenzureimen, besser ist es, wenn andere Leute bei solche Aussagen auf Schwächen hinweisen (können).
Ja, der Verbindungsaufbau dauert defintiv länger, und ums kurz zu sagen, ich halte bereits 8192 Bit für völlig daneben.sergej2018 hat geschrieben:03.11.2019 15:05:18Wie viel ist da eigentlich möglich und sinnvoll? Da der Verbindungsaufbau vmtl. nicht länger dauert, würde ich sonst auch auf 16384 bit gehen, falls das möglich ist...
Der wichtigste Aspekt bei der Entscheidung ist: Bis wie weit in die Zukunft sollen die von mir verschlüsselten Daten sicher sein? Die zweite relevante Frage ist: Speichere ich selber langfristig schutzwürdige und deshalb verschlüsselte Daten oder erzeuge ich nur dialogartige Kommunikationsdaten mit einer für mich nur kurzlebigen Bedeutung, wo ich aber verhindern will, dass jemand diese Daten unerlaubt speichert und sie irgendwann in der Zunkunft unautorisiert entschlüsselt?
Bezogen auf die erste Frage ist die Antwort eigentlich einfach. Weil man davon ausgehen kann, das RSA-2048 in naher Zukunft gebrochen werden kann, ist das für langfristig zu speichernde Daten vermutlich eine schlechte Wahl. Besser wäre es in diesem Fall RSA-3072 oder sogar RSA-4096 zu verwenden. Die Steigerung von 2048 auf 3072 ist aber keine einfache Steigerung um 50% Der Sicherheit, auf 4096 ist auch keine Steigerung um 100%, die Steigerung ist immer exponentiell. Dazu ein Vergleich:
Code: Alles auswählen
RSA <--> Symmetrischer Schlüssel
1024 Bit <--> 80 Bit
2048 Bit <--> 112 Bit
3072 Bit <--> 128 Bit
15360 Bit <--> 256 BitCode: Alles auswählen
= 2 ^112 5.192.296.858.534.830.000.000.000.000.000.000
= 2 ^128 340.282.366.920.938.000.000.000.000.000.000.000.000Völlig anders sieht es aber m.M.n. bei OpenVPN-Verbindungen aus, die in meiner Intention ja kein Longterm-Storage beinhalten, das sind immer alles total kurzlebige Ad-Hoc-Daten in einer Quasi-Dialog-Kommunikation. Hier kann es schlimmstenfalls passieren, dass irgendeine fremde Instanz diesen Datenverkehr mitschneidet und auf einen Zeitpunkt in der Zukunft wartet, um diesen (für mich belanglosen) Traffic aus dem Jahr 2019 rückwirkend entschlüsseln zu können. Denn auch hier gilt die Feststellung, RSA-2048 kann jetzt im Jahr 2019 nicht gebrochen werden.
Aber an diesem Punkt besteht ein weiterer entscheidender Umstand beim Vergleich zum o.g. Longterm-Storage. Bei OpenVPN sind die eigentlich wichtigen Daten ja heute schon gar nicht mehr mit RSA-2048 verschlüsselt.... die sind ja (bei richtiger Konfiguration des Programms) heute bereits mit AES256 verschlüsselt, und damit sind sie jetzt schon genau so sicher, wie beim oben erwähnten Procedere mit GNUPG plus AES256.
Und wieso macht es dann überhaupt Sinn, über eine verbesserte Verschlüsselung mi RSA-3072 (oder RSA-4096) anstatt mit RSA-2048 nachzudenken? Dazu muss man sich der eigentlichen Aufgabe dieser Kommunikations-Verschlüsselung erst mal bewusst sein, denn es ist nämlich NICHT die Aufgabe von RSA, die eigentlichen und schützenswerten Daten in der Übertragung zu verschlüsseln, damit hat RSA überhaupt nichts zu tun.
Um das zu verstehen, muss man sich mit der Funktionsweise des OpenVPN-Protokolls auseinandersetzen. Üblicherweise verwendet OpenVPN aus Performance-Gründen nicht TCP/IP, sondern UDP/IP. Der Unterschied zwischen diesen beiden Protokollen ist, dass UPD keine Zuverlässigkeit beinhaltet, keine Fehlerprüfung, keine Bestätigung über Empfang oder Neuanforderung eines Datenpaketes... UDP ist schlichtweg stateless. Um diese Mängel in einer bidirektionalen Kommunikation (!) mit dem Anspruch auf Zuverlässigkeit zu beheben, verwendet OpenVPN eine Technik analog DTLS (bei OpenVPN ist diese Technik allerdings um einige Jahre älter). Diese Technik basiert auf einen Multiplexing-Trick, in dem nämlich auf dem verwendeten Port (z.B. 1194) zwei Kanäle betrieben werden. Der Control-Channel emuliert das, wofür TLS bei TCP/IP zuständig ist, also authentifizierung, auf dem weiterhin z.B. Server-Options 'gepusht' werden können, worüber Peer-Infos ausgestauscht werden. Der Daten-Channel transportiert letztlich unsere schützenswerte persönliche 'Daten-Nutzlast'.
Die Aufgabe des Control-Channels ist es allein, die beiden Teilnehmer zu authentifizieren, die Integrität der Übertragung sichzustellen, die Zuverlässigkeit hinsichtlich Fehlerfreiheit bei der Übertragung durchs WWW zu garantieren. Also wirklich wichtige schützenswerte persönliche Daten werden hier gar nicht transportiert. Allein das gibt also schon einen deutlichen Hinweis auf die Sinnhaftigkeit der Überlegung von RSA-2048 auf RSA-8192 zu wechseln.
Um das nochmal zu wiederholen, die AES-Verschlüsselung auf dem Daten-Channel ist völlig unabhängig von der TLS-RSA-Verschlüsselung auf dem Control-Channel. Ein derzeit theoretischer Schwachpunkt besteht also allenfalls an dem Punkt, wenn sich die beiden Peers auf dem Control-Channel auf einen gemeinsamen symmetrischen Schlüssel für den Daten-Channel einigen wollen. Dabei besteht aber der Umstand, dass der 'gleich' verwendete symmetrische Schlüssel gar nicht durch das Netz übertragen wird. Die beiden Peers ermitteln den symmetrischen Schlüssel gemäß des DH-Protokolls jeder für sich selber. Also, zum einen muss also zuallerst die RSA-Verschlüsselung gebrochen werden, um zumindest die öffentlichen Schlüssel für den symmetischen Schlüssel abzugreifen, aber für die weitere Beurteilung fehlt dann immer noch der auf jeder Seite verwendete geheime Schlüsselanteil. Möglicherweise ist es irgendwann in der Zukunft möglich, den geheimen Schlüssel aus einer mitgeschnittenen OpenVPN-Sitzung zu rekonstruieren, weil zuvor der Control-Channel gebrochen wurde. Das würde möglicherweise dadurch begünstigt sein, wenn die beiden Peers in der Schlüsselverhandlung (symmetrisch) mehr oder wenig einen Static-Key verwenden. Aus wiederholten mitgeschnittenen Sitzungen sind dann wegen mehr Materials bessere Möglichkeiten für mathematische Rückschlüsse gegeben.
Aber das führt einen dann zwangläufig zu der Erkenntnis, dass man eben Wiederholungen des zuletzt verwendeten symmetrischen Schlüssels auf dem Datenchannel besser kategorisch ausschließt. Also, nicht die sinnlos übertriebene Steigerung von RSA auf dem Control-Channel ist die Lösung, sondern die Wahl der richtigen Cipher auf dem Datenchannel, die dafür sorgt, dass ein einmalig generierter symmetrischer Schlüssel keinesfalls wiederholt wird und auch nicht aus dem vorliegenden Datenmaterial rekonstruiert werden kann. Das Diffie-Hellmann-Proktoll zur Schlüsselverhandlung selber ist nicht verschlüsselt, es verwendet den verschlüsselten Control-Channel, und DH ist auch weiterhin die richtige Wahl für diesen Zweck. Man muss hierbei lediglich entscheiden, ob man ein Pem-File verwendet oder eine elliptische Kurve.... bei beidem muss einem aber klar sein, dass das nicht geheim ist, sondern nur 'ne fette Primzahl ist, die als öffentlicher Schlüssel im Netz übertragen wird....was auch unkritisch ist.... denn der geheime Schlüsselanteil verbleibt ja lokal auf dem Host. Aber der wichtigste Aspekt an diesem Punkt ist es, nicht DH, sondern DHE zu verwenden. Das 'E' steht für ephemeral, was soviel wie kurzlebig bedeutet. Ein solcher mit DHE verhandelter Schlüssel hat nur für die aktuelle Sitzung Gültigkeit und kann selbst bei Vorliegen allen vergangenen Datenmaterials nicht rekonstruiert werden... ganz egal und völlig unberücksichtig davon, ob zuvor RSA-2048 oder RSA-8192 den Control-Channel verschlüsselt hat. Und wenn dieser ephemere Schlüssel nicht rekonstruiert werden kann, können auch die mit AES256 verschlüsselten Daten auf dem Daten-Channel nicht rückwirkend entschlüsselt werden. So einfach ist das....
Das eigentliche Problem ist also, wie kann ich sicherstellen, dass der Host auf der anderen Seite wirklich der ist, der er zu sein vorgibt, damit ich sicher sein kann, dass RSA-2048 auch wirklich unseren privaten Control-Channel sicher verschlüsselt. Kommuniziere ich nämlich unbemerkt mit einem MITM, ist es faktisch völlig egal, ob ich mit dem oder dem Mann im Mond über RSA256 oder RSA15360 kommuniziere.... dann verhandele ich nämlich mit einem unautorisierten Dritten über den symmetrischen Schlüssel und nicht mit dem gewollten Partner. Andersrum ist es heute ebenfalls egal, wenn die Integrität beider Peers und der Verbindung unzweifelhaft ist, ob ich RSA2048 oder größer verwende... in dem Fall ist RSA2048 heute genauso sicher, wie ein höherer Wert, weil darüber auf zweifelsfrei sichere Weise ein nur einmalig gültiger symmetrischer Schlüssel für den Datenchanel verhandelt werden kann. Wenn ich allerdings wirklich ein wenig paranoid bin, kann ich natürlich mit RSA3072 nach heutigen Maßstäben eine noch bessere Sicherheit dafür herstellen, dass nicht irgendwann in ferner Zukunft rückwirkend der Kommunikations-Anteil auf dem Control-Channel dieser 'heutigen' Sitzung rückwirkend gebrochen werden kann. Und selbst wenn, damit ist immer noch nicht der Daten-Channel gebrochen. Das primäre Ziel muss deswegen aber immer sein sicherzustellen, dass der andere Peer auch wirklich der ist, der er vorgibt zu sein... und deshalb muss ich meine Zertifikate durchaus sicher aufbewahren, eben damit nicht jemand anderes mit der Verwendung eines gestohlenen Zertifikats vorgeben kann, jemand zu sein, der er gar nicht ist. An diesem Punkt halte ich es beispielsweise für ein möglicherweise unkalkulierbares Risiko, solche Zertifikate auf einem Smartphone aufzubewahren... weil man faktisch keine oder nur eine unzureichende Kontrolle über die Leseberechtigungen der Apps hat... keine Ahnung, ob das wirklich so ist... ich verwende aber bereits seit 2 Jahren kein VPN mehr auf dem Handy, sondern nutze es nur noch als Router/Gateway.
Ums nun zum Ende zu bringen... mein Fazit für sichere OpenVPN-Verbindungen:
- Sicher aufbewahrte Zertifikate, um eine sichere Identifizierung/Authentifizierung der Peers zu ermöglichen
- Eine auf den aktuellen Moment angemessene Verschlüsselung auf dem Control-Channel verwenden, also heute RSA2048 oder RSA3072
- Sofern die eigene Hardware das unterstützt, nur ab TLS 1.2 zulassen
- Zwischen pem-File oder elliptischer Kurve wählen (EC scheint Vorteile zu haben)
- Zwingend DHE verwenden
- Nur Cipher-Suiten mit ephemeren symmetrischen Schlüssel zulassen.
- Message-Authentifizierung auf beiden Kanälen mit HMAC/SHA256 herstellen (SHA512 verbessert nicht die Sicherheit, sondern verschlechtert nur die Performance)
