easyrsa: wie viel bit sinnvoll?

[sergej2018]

Hallo,

ich generiere ab und an Zertifikate mit easyRSA. Z.B. für openVPN oder ähnliches.
In der vars-Datei kann ich ja uA festlegen, wie viele Bits verwendet werden sollen.
Habe vorhin mal ausprobiert und festgestellt, dass 8192 bit mit openVPN mittlerweile gut funktionieren (vmtl. nicht auf iOS- oder Android-Geräten, aber das ist für mich egal).
Wie 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...

[bluestar]

Mehr Bits != Mehr Sicherheit....

Passt du deine physikalischen Sicherungsmaßnahmen auch der Länge deiner SSL-Schlüssel an?

Falls ja so würde mich doch mal interessieren, wie dein allgemeines Sicherheitskonzept aussieht, welches mit den vorgeschlagenen Schlüssellängen d'accord geht.

[sergej2018]

Sagen wir mal so: Das Erzeugen "größerer" Zertifikate ist ja kein Problem. Klar: Das Erstellen des DH-Param dauert einmal deutlich länger, aber da man das ja nicht täglich macht...
Von daher: Warum nicht? Wenn's die Verbindung sicherer machen würde, würde ich Zertifikate mit größeren Schlüsseln verwenden.

[TomL]

Sagen wir mal so: Das Erzeugen "größerer" Zertifikate ist ja kein Problem. Klar: Das Erstellen des DH-Param dauert einmal deutlich länger, aber da man das ja nicht täglich macht...
Von daher: Warum nicht? Wenn's die Verbindung sicherer machen würde, würde ich Zertifikate mit größeren Schlüsseln verwenden.

Ich denke, wenns seitens der Performance keine Einbrüche bedeutet, warum nicht 4096 Bit. Ansonsten... leidet die Performance, dann 2048 Bit, das soll wohl noch bis 2030 sicher sein.

[sergej2018]

Habe jetzt nicht viel getestet, aber zumindest der Verbindungsaufbau funktionierte mit einem echt schwachen alten Prozessor genauso schnell oder langsam wie vorher...
Und der Rest der Verschlüsselung wird ja nicht verändert, es geht ja nur um den kurzen Moment des Auth.

[TomL]

Das habe ich anders verstanden. Das eine ist der Verbindungsaufbau, das andere ist die Schlüssellänge der normalen Nutzdaten-Paketverschlüsselung. Und soweit ich das verstanden habe, wird für diffie-hellman z.B. ein 2048 Bit-Key erzeugt, der nur zur Aushandlung der Verbindung verwendet wird, aber der eigentliche Traffice ist dann via RSA verschlüsselt. Und rsa2048 oder rsa4096 hat insofern sehr wohl Einfluss auf die Performance. Ich würde das einfach mal hinsichtlich Performance testen. Mich würde das Resultat eines solchen Tests nämlich auch interessieren.

[sergej2018]

Nene moment:
RSA (also mit DH) wird verwendet um einen symmetrischen Schlüssel für die Verschlüsselung auszuhandeln.
Im Endeffekt benutzt wird dann - in meinem Falle - aber z.B. AES.

[TomL]

Nene moment:

Oh, sorry.... da war ich unaufmerksam....

[TomL]

Passt du deine physikalischen Sicherungsmaßnahmen auch der Länge deiner SSL-Schlüssel an?

Was sind physikalische Sicherungsmaßnahmen, die man auch anpassen muss?

[bluestar]

Was sind physikalische Sicherungsmaßnahmen, die man auch anpassen muss?

Na der Schutz des Rechners vor Diebstahl, unbefugter Veränderung, Nutzung eines HSM.

[sergej2018]

Ist erstmal nur eine theoretische Diskussion
Aber sollte es so weit kommen, steht der betreffende Server in einem Extra-Rack in einem Extra-Raum eines Rechenzentrums, das mit den üblichen Methoden geschützt ist.

[TomL]

Na der Schutz des Rechners vor Diebstahl, unbefugter Veränderung, Nutzung eines HSM.

Nuja, der Diebstahl-Schutz von zwei an unterschiedlichen Standorten befindlichen Rechnern hat ja nicht zwingend was mit der Verschlüsselung von Übertragungen zwischen diesen beiden Rechnern zu tun ... oder anders gesagt, für die Klauerei isses egal, ob die Leitung dazwischen verschlüsselt ist oder nicht. Ich würde den Hinweis deswegen eher etwas ironisch verstehen... als wenn Du glaubst, dass 4096 Bit oder gar 8192 hierfür wirklich nicht notwendig sind. Ehrlich gesagt, ich persönlich weiss das nicht... deswegen vertraue ich auf die Aussagen, dass 2048 Bit noch 10 Jahre sicher sind und bleibe noch bei 2048 Bit.

[sergej2018]

Meine Überlegung kommt auch daher, dass heute jedermann über die Cloud kurz mal ganz massive Rechenpower mieten kann.
Es wird sich ja niemand mit seinem i3-Desktop-PC hinsetzen und versuchen, einen Key zu bruteforcen...

[schorsch_76]

Ich empfehle dir, das folgende durchzulesen

https://bettercrypto.org/

Meines Wissens nach, bricht praktisch nie der Algorithmus (AES etc.) sondern meistens die Implementierung. Es ist natürlich wichtig eine passende Schlüssellänge und den passenden Algorithmus zu nutzen. Auch ein häufiges (tm) Problem ist, das es Probleme und Schwächen im Protokoll gibt/gab.

Siehe https://en.wikipedia.org/wiki/OpenSSL#N ... rabilities

Wichtig ist: Nutze kein RC4 oder deren Derivate! Setze auf "gute" Algorithmen und sichere Bibliotheken. https://bettercrypto.org/ deckt praktisch alles ab: Von HTTPS, IPSec etc.

Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.

— Edward Snowden

answering questions live on the Guardian’s Website

[MSfree]

Meine Überlegung kommt auch daher, dass heute jedermann über die Cloud kurz mal ganz massive Rechenpower mieten kann.

Nein, "jedermann" könnte das gar nicht bezahlen.

Es wird sich ja niemand mit seinem i3-Desktop-PC hinsetzen und versuchen, einen Key zu bruteforcen...

Seit 17 Jahre versucht man bei http://www.distributed.net/RC5 einen 72-Bit RC5-Schlüssel zu knacken und hat bisher erst 6.1% des Suchraums abgearbeitet. Dort sind rund 139000 Rechner an der Suche beteiligt. Bei AWS würde das rund 1000 US$ pro Minute kosten.

[sergej2018]

Moin,

total gute Website, hab vielen Dank!
Muss ich mal in Ruhe durcharbeiten.

[TomL]

Ich empfehle dir, das folgende durchzulesen
https://bettercrypto.org/

Ich habe das versucht.... bis an den Punkt, an dem ich mich überfordert gefühlt habe. Mitgenommen habe ich jedoch die Erkenntnis, dass der DH-Prameter 2048 als derzeit ausreichend angesehen wird ... und weiterhin eine prägnante Aussage... "Sicherheit ist ein Prozess, kein Produkt" .... eine Intention, der ich selber mehr oder weniger unbewusst aber trotzdem konsequent folge. Ich wäre jedoch nie auf die Idee gekommen, das was ich hier bei mir tue, so prägnant zusammenzufassen.

Von allen möglichen Seiten wird im Gespräch immmer sowas wie "AES" als Verschlüsselung hingeworfen, oder Zertfikate, Keyfiles.... aber ich glaube, dass die wenigsten wirklich erklären können, worüber sie da überhaupt reden. Ich habe zwar mein eigenes Openvpn-Setup umfassend beschrieben, aber letztlich dann doch mit dem schleichenden Gefühl, als Blinder nur Farben beschrieben zu haben. Es funktioniert zwar... aber darüber hinaus....

Das Problem ist es, nicht nur einen Schlüssel und einen Algorithmus zu sehen und dann zu glauben, beides zusammen heisst AES und das ist Hackingsicher und das ist die ganze Kiste... aber das ist in Wirklichkeit gar nicht die ganze Kiste. Das Problem ist es, den Ablauf zu verstehen, der letztlich erst diesen Schlusspunkt der Paket-Verschlüsselung ermöglicht. Ich weiss nicht, ob ich den Ablauf verstanden habe und versuche mal, das hier aufzumetern.... vielleicht kann das jemand verbessern oder korrigieren.

• Alles fängt mit der 'Kontaktaufnahme' via IP an, vom Internet kommend über den Router zum NIC des Zielhost, was imho L3 (Netzwerk) entspricht.
• Als nächtes folgt der TCP-Syn-Ack-Handshake zur Etablierung der Verbindung, was L4 (Transport) entspricht
• Dann beginnt die Verschlüsselung des Paketetransports über TLS auf L5 (Protokoll). TLS ist durch die Kombination aus asymmetrischer und symmetrischer Verschlüsselung ein hybrides Protokoll. Auf diesem TLS-Channel kann zusätzlich via Static-Keyfile eine Message-Authentifizierung durchgeführt werden, mit der die Authentizität der Pakete geprüft werden kann... die HMAC-Firewall.

Bis hierhin ist das also nur der grundsätzliche Verbindungsaufbau zwischen 2 Hosts über das Internet. Und erst hiernach kommt der eigentliche Prozess des Zielhosts ins Spiel... an dieser Stelle der OpenVPN-Daemon des Servers.

• Mithilfe der CA (Certificate Authority) wird durch den Daemon die Legitimität des Verbindungsaufbaus geprüft. Ist das Zertfikat ungültig, wird die Verbindung unterbrochen. Ist das Zertifikat gültig, wird der derzeit noch nur auf dem TLS-Channel ablaufende Prozess fortgeführt.
• Auf der Protokoll-Ebene wird nun mit den zur CA gehörenden Keyfiles (es gibt 2 Keyfiles (Public Key ((CLT) + Private Key (SRV)) eine asymmetrische Verschlüsselung als Kurzzeit-Kommunikation etabliert, die allein dazu dient, mithilfe des dh-Algorithmus den eigentlichen Sitzungsschlüssel zwischen beiden Hosts zu ermitteln. DH ist dabei ein eigenes Protokoll zur Schlüsselvereinbarung.
• Der mithilfe DH ermittelte Sitzungschlüssel ist ab jetzt die Grundlage einer nun symmetrischen Verschlüsselung bei Verwendung eines vorgegebenen Crypt-Algorithmus, z.B. AES, womit ab jetzt die gesamte Kommunikation verschlüsselt wird.
• Ist die Verbindung also via Cert legitimiert und der Sitzungsschlüssel ermittelt, sind Cert und Keyfile der CA jetzt nicht mehr notwendig, allerdings prüft auf dem TLS-Channel weiterhin die HMAC-FW die Authentizität der Pakete.

Ok, soweit reicht also mein Verständnis der Zusammenhänge.... ich würde mich sehr freuen, wenn jemand das mal ergänzen oder korrigieren könnte... denn ich vertrete immer noch die Überzeugung, dass man keine akzeptable Sicherheit etablieren kann, wenn man sich nur irgendwelche Statements aus dem Netz zusammenkopiert.... was m.M.n. die Sicherheit wirklich nur zu einem Zufallsprodukt macht. Aber bei der Schwere dieses Themas und sich allein auf seine eigenen Interpretationen zu verlassen, bedeutet am Ende vielleicht nix anderes, als man ist verlassen.

[schorsch_76]

Bei meinen Setups (Apache 2.4, Mail, OpenVPN) hab ich mich an die "BestPractices" aus diesem Guide gehalten. Den Apachen kann man gut mit https://ssllabs.com testen. Bei OpenVPN, da ich alle Endpunkte kontrolliere, nutze ich AES-256-GCM und SHA-512.
(tls-cipher + auth in der config). Da ich nur diese Algorithmen zulasse, kann es auch keinen Down Grade im Protokoll geben.

Bei OpenVPN kommt es auch auf den Transport an. Früher nutzte ich TCP aber nach einem Besuch in China nutze ich UDP. Hier nehmen die Pakete nicht alle dieselbe Route im Internet und können nicht ganz so einfach der Verbindung zugeordnet werden und es kommen wenigstens einige Pakete durch. Dadurch ist die Verbindung zwar nicht so stabil wie in Deutschland aber auch nicht komplett geblockt.

Der Client prüft das Zertifikat des Servers mit dem Zertifikat der CA, ob es hier auch mit rechten Dingen zugeht. Das selbe macht auch der Server. Jede Seite hat den Öffentlichen Schlüssel der CA und kann damit die Unterschrift des präsentierten Zertifikates sicherstellen. Wenn der gesamte Verbindungsaufbau von beiden Seiten ok ist, wird das tap Device eingerichtet. (verify-client-cert und verify-x509-name in den configs).

Mit Wireshark kann ich sehen, das auch ein netcat einer reinen Textdatei über den VPN Tunnel nicht als Klartext zu erkennen ist. Im Log es Servers und des Clients kann man erkennen, das sie eben den gewählten Algorithmus und Auth Algorithmus nutzen.

Wie der Verbindungsaufbau auf IP Ebene abläuft, weis ich grundsätzlich aber nicht jedes Detail. Deshalb gibt es die BestPractices damit wir (die Leute die das nur anwenden und nicht entwickeln) recht sicher anwenden können.

Das ganze Heartbleed Debakel hat ja zur Entstehung von LibreSSL geführt. Unter FreeBSD habe ich ein Poudriere Setup das mir hier Packete mit OpenSSL und LibreSSL baut. Um es kurz zu machen: Es ist leider noch nicht so einfach alles mit LibreSSL zubauen obwohl es als DropIn Replacement beschrieben wird. Das Problem ist:

• Manche Python und Qt Packete haben hier ein paar fest einkompilierte Konstrukte welche es verhindern das LibreSSL einfach OpenSSL ersetzen. Das Problem: Obwohl es Patches gibt, damit das kompiliert, verweigern einige Upstreams diese Patches.
• LibreSSL und OpenSSL können wohl nicht nebeneinander existieren auf dem selben Host/System. (finde die Quelle gerade nicht)

[1] https://bugs.freebsd.org/bugzilla/show_ ... ?id=226906
[2] https://bugreports.qt.io/browse/QTBUG-68374

[TomL]

Bei OpenVPN kommt es auch auf den Transport an. Früher nutzte ich TCP aber nach einem Besuch in China nutze ich UDP.

Das ist auch so ein Unterpunkt, der mir nicht wirklich klar ist. OpenVPN sagt ja, es verschlüsselt über TLS und kann TCP oder UDP ...prima... klingt doch wirklich gut ... hat leider nur eine Falle: TLS kann gar kein UDP. Für UDP wäre DTLS notwendig, was man zwar als Paket installieren kann, was aber auf keinem meiner Systeme installiert ist. Und darüber hinaus weiss ich auch gar nicht, ob OpenVPN DTLS überhaupt kennt oder berücksichtigen würde. Also 'interpretiere' ich die Situation so, dass grunsätzlich IMMER TCP-Pakete zwischen den beiden Hosts TLS-Verschlüsselt versendet werden. Nur transportieren diese völlig normalen TCP-Pakete dann als Payload zusätzlich die eigentlichen UDP-Pakete, die damit dann den Tunnel darstellen. Diese Vorgehensweise macht imho Sinn, weil das TCP-Protokoll sowieso schon für die Verbindungssicherheit resp. -stabilität sorgt, insofern kann der Tunnel dann auch auf dem zustandslosen UDP ohne Verbindungssicherheit basieren.

Würde man für OpenVPN ebenfalls TCP verwenden, würde das primäre via TLS verschlüsselte TCP-Protokoll ein weiteres Stateful-TCP-Protokoll als Payload transportieren, dessen eigener Overhead niemals einen Nutzen hätte, weil das 'vordere' TCP ja schon erfolgreich für die Fehlerfreiheit des Transports sorgt.

Aber auch hier wieder der Punkt... das sind jetzt nur meine Interpretationen aus der Menge der teilweise vagen Informationen im Web. Alle reden immer nur über die Unterschiede von TCP und UDP und wann man was nehmen soll. Nur auf diesen mickrigen Umstand, dass TLS gar kein UDP kann, geht keiner ein.

[MSfree]

Also 'interpretiere' ich die Situation so, dass grunsätzlich IMMER TCP-Pakete zwischen den beiden Hosts TLS-Verschlüsselt versendet werden.

Bei einer OpenVPN-Brücke, die ich zwischen zwei Bürostandorten eingerichtet habe, läßt die Firewall (iptables) nur Port 1194/UDP durch. Da kann also nichts über TCP übertragen werden.

[sergej2018]

Jap, genau dasselbe, verwende auch noch ein paar andere Firewall-Produkte, selbes Verhalten.
Die "Grundverbindung" muss demnach schon über UDP laufen.

[TomL]

Bei einer OpenVPN-Brücke, die ich zwischen zwei Bürostandorten eingerichtet habe, läßt die Firewall (iptables) nur Port 1194/UDP durch. Da kann also nichts über TCP übertragen werden.

Oh mann... ... Du hast natürlich Recht ... ist doch bei mir genauso. Das ist aber auch genau das, was ich meinte... bei dem Versuch die Zusammenhänge ein wenig besser zu begreifen, kapituliert man irgendwann vor der unglaublichen Menge an Aspekten oder verrennt sich gar in Interpretationen weitab des wirklichen. Ich werde jetzt mal versuchen herauszufinden, wie sich der Widerspruch UDP und TLS mit OpenVPN auflösen lässt.

[schorsch_76]

Aber auch hier wieder der Punkt... das sind jetzt nur meine Interpretationen aus der Menge der teilweise vagen Informationen im Web. Alle reden immer nur über die Unterschiede von TCP und UDP und wann man was nehmen soll. Nur auf diesen mickrigen Umstand, dass TLS gar kein UDP kann, geht keiner ein.

man openvpn

Code: Alles auswählen

   TLS Mode Options:
       TLS  mode  is  the  most powerful crypto mode of OpenVPN in both security and flexibility.  TLS mode works by establishing
       control and data channels which are multiplexed over a single TCP/UDP port.  OpenVPN initiates a TLS session over the con‐
       trol channel and uses it to exchange cipher and HMAC keys to protect the data channel.  TLS mode uses a robust reliability
       layer over the UDP connection for all control channel communication, while the data channel, over which  encrypted  tunnel
       data passes, is forwarded without any mediation.  The result is the best of both worlds: a fast data channel that forwards
       over UDP with only the overhead of encrypt, decrypt, and HMAC functions, and a control channel that provides  all  of  the
       security features of TLS, including certificate-based authentication and Diffie Hellman forward secrecy.

       To  use  TLS mode, each peer that runs OpenVPN should have its own local certificate/key pair ( --cert and --key ), signed
       by the root certificate which is specified in --ca.

       When two OpenVPN peers connect, each presents its local certificate to the other.  Each peer  will  then  check  that  its
       partner peer presented a certificate which was signed by the master root certificate as specified in --ca.

       If  that  check  on both peers succeeds, then the TLS negotiation will succeed, both OpenVPN peers will exchange temporary
       session keys, and the tunnel will begin passing data.

       The OpenVPN project provides a set of scripts for managing RSA certificates & keys: https://github.com/OpenVPN/easy-rsa

Das bedeutet, das OpenVPN über beide Transport Arten eigene Packete versendet.

[schorsch_76]

Das Buch "Network Security with OpenSSL: Cryptography for secure communications" beschreibt wie das auch mit UDP geht. Kapitel: "6.2.6 Handling UDP Traffic with Counter"
Mit den BIO Funktionen für Memory oder Pipes kann man das alles auf Pipes oder anderen Speicher umlegen. Ich möchte nur nicht einen Auszug kopieren, da ich nicht weis ob ich das darf.

[1] https://www.amazon.de/Network-Security- ... 745&sr=8-2

[TomL]

Ich glaube, so langsam lichtet sich das Chaos.

Ein primärer Unterschied zwischen TCP und UDP ist anscheinend, dass TCP aufgrund der Protokollspezifikation zuverlässig ist und UDP als Stateless-Protokoll eben nicht. TLS unterstützt aber nur diese zuverlässigen TCP-Verbindungen, aber eben nicht UDP. Für UDP gibt es allerdings als Variante DTLS, was sich eines Tricks bedient, um die notwendige Zuverlässigkeit herzustellen, was aber anscheinend später als OpenVPN entwickelt wurde. Und anscheinend hat OpenVPN bereits zuvor eine eigene DTLS-Variante implementiert, die auch wohl ähnlich dem 'normalen' DTLS arbeitet.

Der Trick mit dem OpenVPN-TLS für UDP ist anscheinend, dass in der UDP-Verbindung quasi 2 Channels etabliert werden, wo über den Control-Channel die notwendige Zuverlässigkeit (Handshake, AUTH, TLS, HMAC) hergestellt wird und der Daten-Channel den Payload enthält. Das heisst, auf einem UDP-Port werden also 2 Channels etabliert oder multiplexed oder wie auch immer....



http://ipseclab.eit.lth.se/tiki-index.p ... %20OpenVPN
https://www.ru.nl/publish/pages/769526/ ... vickis.pdf (Seite 20)