easyrsa: wie viel bit sinnvoll?

Alles rund um sicherheitsrelevante Fragen und Probleme.
sergej2018

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von sergej2018 » 04.11.2019 10:29:56

Moin,

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

TomL

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 04.11.2019 11:27:40

schorsch_76 hat geschrieben: ↑ zum Beitrag ↑
04.11.2019 08:47:31
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. :roll:

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von schorsch_76 » 04.11.2019 13:31:44

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

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 04.11.2019 14:59:30

schorsch_76 hat geschrieben: ↑ zum Beitrag ↑
04.11.2019 13:31:44
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. :roll:

Benutzeravatar
MSfree
Beiträge: 10683
Registriert: 25.09.2007 19:59:30

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von MSfree » 04.11.2019 16:28:26

TomL hat geschrieben: ↑ zum Beitrag ↑
04.11.2019 14:59:30
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

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von sergej2018 » 04.11.2019 16:35:27

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

TomL

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 04.11.2019 18:08:36

MSfree hat geschrieben: ↑ zum Beitrag ↑
04.11.2019 16:28:26
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... :facepalm: ... 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.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von schorsch_76 » 04.11.2019 18:11:02

TomL hat geschrieben: ↑ zum Beitrag ↑
04.11.2019 14:59:30
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. :roll:
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.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von schorsch_76 » 04.11.2019 18:35:03

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

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 04.11.2019 19:07:59

Ich glaube, so langsam lichtet sich das Chaos. :roll:

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)
Zuletzt geändert von TomL am 04.11.2019 19:20:03, insgesamt 2-mal geändert.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von bluestar » 04.11.2019 19:14:07

TomL hat geschrieben: ↑ zum Beitrag ↑
03.11.2019 23:21:21
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 möchte anmerken, das längere Schlüssel eben kein Garant für „höhere Sicherheit“ sind. Das gesamte Sicherheitskonzept sollte in sich stimmig sein.

Wenn man „nur weil‘s eben geht“ mit 8192 oder 16384 Bits an Schlüssellängen hantieren möchte, dann ist das entweder eine nette Spielerei oder ein sehr sehr aufwendiges Sicherheitskonzept, wo die Schlüssellängen dazu gehören.

Wie schützt ihr die privaten Schlüssel der CA? Durch ein Passwort? Welche Passwortlänge habt ihr bei derartigen Schlüssellängen im Einsatz? Nutzt ihr ein HSM, wenn ja welches?

TomL

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 04.11.2019 19:16:06

bluestar hat geschrieben: ↑ zum Beitrag ↑
04.11.2019 19:14:07
Wie schützt ihr die privaten Schlüssel der CA?
Durch löschen, nachdem einmal alle Clients bedient sind und eingerichtet sind... :D ... ich bewahre die PKI-Struktur nicht auf.

sergej2018

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von sergej2018 » 04.11.2019 19:18:26

Kann in einem Forum jetzt natürlich nicht mein ganzes Konzept offenlegen ;-)
Ist aber natürlich richtig von dir, darauf hinzuweisen, dass auch der Rest stimmen muss!

TomL

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 04.11.2019 19:25:21

sergej2018 hat geschrieben: ↑ zum Beitrag ↑
04.11.2019 19:18:26
Kann in einem Forum jetzt natürlich nicht mein ganzes Konzept offenlegen ;-)
Warum nicht? Security by obscurity? Ist doch genau so überflüssig, wie lokale 192'er IPs in Postings zu anonymisieren. Ich habe damit jedenfalls kein Problem, weil ich mit dem Offenlegen genau auf den Effekt hoffe, dass mich jemand auf Fehler hinweist, die mir vielleicht entgehen würden, wenn ich völlig sinnlos alles geheim halten würde. Ganz nebenbei bemerkt, gibts eh keine Geheimnisse dergestalt, dass Dein Konzept so grundsätzlich von der Normalität abweicht, dass man die Technik quasi im Sinne eines Patents schützen muss. Es gibt allenfalls blamable Fehler... aber da wäre ich jedenfalls total froh drüber, wenn jemand drüber lacht... zeigt es mir doch, wo ich nachbessern muss.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von schorsch_76 » 04.11.2019 21:11:10

Es kommt auch darauf an, welcher Algorithmus benutzt wird. 256 Bit bei AES sind was anderes als 256 Bit bei RSA.

https://de.m.wikipedia.org/wiki/Schl%C3 ... l%C3%A4nge

Als verlässliche Quelle kann man das Buch von Bruce Schneier nennen: "Applied Cryptography" Kapitel 7 Keylength. Auch 7.5 zeigt auf, wie der OP das lösen kann.
Das ist wirklich ein Experte auf diesem Gebiet und er hat sein Wissen veröffentlicht.

Bei symmetrischen Schlüsseln würde ich heute auf 256 bit setzen. RSA würde ich mit 4096 bit nutzen.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von schorsch_76 » 04.11.2019 21:17:53

https://www.bsi.bund.de/DE/Publikatione ... x_htm.html

Das ist vom BSI. Ganz oben das erste PDF. Das stößt in exakt die selbe Richtung.

TomL

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 05.11.2019 10:43:06

schorsch_76 hat geschrieben: ↑ zum Beitrag ↑
04.11.2019 21:11:10
Bei symmetrischen Schlüsseln würde ich heute auf 256 bit setzen. RSA würde ich mit 4096 bit nutzen.
Ich tue mich noch so ein bisschen schwer damit, die Vorteile von RSA4096 oder gar RSA8192 zu erkennen. Ja, sicher, die Verschlüsselung wird 'härter', aber die eigentliche Frage ist dabei, welchen Unterschied macht es für die Mäuse, wenn das Schloss an der Kornkammer aus Alu ist oder aus gehärtetem Stahl?

So wie ich das verstanden habe, sichert RSA mit einem asymmetrischen Schlüssel lediglich die Findung eines symmetrischen Schlüssels ab. Welchen Einfluss hat dabei die Länge des asymmetrischen Schlüssels für RSA auf die Länge des neuen symmetrischen mit AES2546/SHA512? Die IP-Pakete selber sind ja hinterher AES verschlüsselt ... und selbst wenn die jemand mitgeschnitten hat, welche Relevanz hat an diesem Punkt des Mitschnitts die Frage, ob zuvor RSA2048 oder RSA8912 bei der Findung des Sitzungsschlüssels beteiligt war? Und darüber hinaus hat ja ein symmetrischer Sitzungssschlüssel auch nur eine sehr kurze Lebensdauer, entweder nur für die Sitzung oder via --reneg-sec n mit vorgegebener Zeitdauer.

Und weiterhin tue ich mich schwer zu verstehen, was die Aussage "RSA2048 ist nur bis 2030 sicher" bedeutet. Ja, natürlich, auch hier verstehe ich den faktischen Inhalt, kann ihn aber ebensowenig auf die Realität projizieren, wie oben. Bedeutet das, dass eine via RSA2048 verschlüsselte und mitgeschnittene Sitzung im RZ-Labor mit hohem Aufwand gebrochen werden kann? Äh, meine Sitzungen sind doch aber via AES verschlüsselt. Bedeutet das, dass man aus milliarden von IP-Paketen mal eben on-the-fly meine nur 1/10-Sekunden dauernde via RSA durchgeführte Schlüsselvereinbarung bricht und dann aus weiteren milliarden IP-Paketen meine eigenen mit einem temporären AES-Schlüssel versehenen IP-Pakete rausfischt und ebenfalls bricht?

Was ich nicht verstehe ist der Umstand, ob aus dem AES-Sitzungsschlüssel abzuleiten ist, ob die vorherige Sitzungs-Schlüsselfindung mit RSA2048 oder RSA8192 passiert ist. Wenn das nicht so wäre, sind auch meine AES-Pakete nicht zu hacken. Dann wäre es imho für einen Angreifer nur möglich, genau im Moment des Prozesses der Schlüsselfindung einzugreifen, um eben an den eigentlichen Sitzungsschlüssel zu kommen. Sobald dieser Prozess jedoch abgeschlossen ist, isses doch vorbei, dann gilt AES/SHA, und das ist sicher.

Mein Fazit ist, solche Attacken auf unsere privaten On-The-Fly-Verbindungen funktionieren möglicherweise nur dann, wenn das System bereits kompromittiert ist. Und deshalb glaube ich, es ist viel einfacher eine schlecht aufbewahrte PKI-Struktur zu kapern, als immense Rechenpower in fast immer belanglose Ergebnisse reinzustecken. Ich halte es sowieso für totalen Quatsch, den Aufwand fürs Hacking im Netz zu betreiben, Quellen-TKÜ ist viel doch effektiver und deutlich kostengünstiger. Und unsere Regierung holt sich doch jetzt mit Huawei den Dienstleister rein, der genau dafür die größte Erfahrung hat..... ein Schelm wer böses dabei denkt.

Ich glaube, das Problem ist bei mir das gleiche, wie bei allen anderen Anwendern... man trifft Entscheidungen, ohne den tatsächlichen Wert der Entscheidung auch nur ansatzweise erklären zu können... meistens nach der für mich eher nicht belastbaren Sichtweise "viel hilft viel"... das tut es aber meiner Meinung nach überhaupt nicht. Ich bleibe für meinen Kleinkram erst mal bei RSA2048.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von schorsch_76 » 05.11.2019 12:26:21

Naja, du sagst ja, dass du es nicht 100% verstehst. Deshalb der Hinweis auf verschiedene Quellen, die es Wissen. BSI und Bruce Schneier. Wenn diese Personen sagen, dass das nur etwa so lange hält glaube ich das.

Wenn mein Arzt sagt: "Dein Blutwert xyz ist zu hoch." Dann glaube ich das auch. Ich muss nicht jede biochemische Reaktion verstehen um mein Leben anzupassen.

TomL

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 05.11.2019 12:32:34

schorsch_76 hat geschrieben: ↑ zum Beitrag ↑
05.11.2019 12:26:21
Wenn mein Arzt sagt: "Dein Blutwert xyz ist zu hoch." Dann glaube ich das auch. Ich muss nicht jede biochemische Reaktion verstehen um mein Leben anzupassen.
Dann hast Du offensichtlich die Intention meines Postings missverstanden. Wenn mir mein Arzt oder 100 andere Ärzte oder auch Bruce Schneier sagen, dass Rauchen den Blutdruck erhöht und für Krebs verantwortlich ist, und ich müsse deshalb unbedingt mit dem Rauchen aufhören, dann käme ich nie auf die Idee, dass auch nur im leisesten anzuweifeln. Ich stelle nur meine persönliche Betroffenheit vor dem mickrigen Umstand infrage, dass ich noch nie geraucht habe. :wink:

Ich sprach jedenfalls nicht von mit RSA2048 verschlüsselten Sitzungen oder Datei-Archiven... weil ich denke, dass die in absehbarer Zeit unsicher sind. Beides würde ich heute schon nicht mehr verwenden.

TomL

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 05.11.2019 18:43:19

schorsch_76 hat geschrieben: ↑ zum Beitrag ↑
05.11.2019 12:26:21
Deshalb der Hinweis auf verschiedene Quellen, die es Wissen. BSI und Bruce Schneier. Wenn diese Personen sagen, dass das nur etwa so lange hält glaube ich das.
Weil mich das wirklich interessiert und vor dem Hintergrund von sergej2018's Idee mit rsa8192, habe ich mir die Quellen noch mal angesehen. Bei allem was ich lese, passend auch zu den anderen Quellen, geht es immer um die langfristige Aufbewahrung von Daten, wenn sie mit RSA2048 verschlüsselt wurden.

Dazu sagt das BSI:
"Für einen Einsatzzeitraum über das Jahr 2022 hinaus wird empfohlen, RSA/DLIES-Schlüssel von
3000 Bits Länge zu verwenden, um ein gleichmäßiges Sicherheitsniveau in allen empfohlenen
asymmetrischen Verschlüsselungsverfahren zu erzielen."


Das heisst nix anderes, als das ich die heute von mir erstellten Dateien besser mit RSA-3072 Bit verschlüsseln sollte, wenn ich eine Entschlüsselungssicherheit über 2022 hinaus garantieren will und wenn ich dazu überhaupt RSA verwenden will. Habe ich die Idee, die Daten auch noch über 2030 zu sichern, wird vermutlich sogar eine Schlüssellänge von 4096 Bit sinnvoll sein. Alternativ könnte ich für solche Dateien aber auch einfach AES256 nehmen... dann muss ich mir darüber keine Gedanken mehr machen.

Und weiterhin:
"Bei Zugrundelegung der heute bekannten Faktorisierungsverfahren und unter der Annahme,
dass es nicht zu einer Nutzung von Quantencomputern für solche Angriffe kommt, ist nicht
damit zu rechnen, dass RSA-Moduln einer Länge von 2000 Bit in näherer Zukunft faktorisiert
werden können.
:::::
Die Verwendung von 3000-Bit-Schlüsseln wird daher für RSA sowie für kryptographische
Verfahren basierend auf dem Diffie-Hellman-Problem in endlichen Körpern (DSA,
DH-Schlüsseltausch) als grundsätzliche Sicherungsmaßnahme ab Anfang 2023 empfohlen
und ist für Systeme mit einer entsprechenden projektierten Lebensdauer als Voraussetzung
für die Konformität zu der vorliegenden Technischen Richtlinie bindend."


Bei OpenVPN-Verbindungen reden wir aber nicht über die langfristige Speicherung von Daten, sondern nur über eine extrem kurzfristige Ad-Hoc-Gültigkeit eines asymmetrischen Schlüssels, wobei die eigentlichen schützenswerten Daten ja anschließend sowieso via AES256 verschlüsselt werden. Daraus schließe ich, selbst wenn irgendeine Institution heute meinen VPN-Traffic mitschneiden würde, könnten sie wahrscheinlich irgendwann in den nächsten Jahren diese RSA2048-Verschlüsselung knacken. Aber sie müssten dann aus dieser sehr kurzen Anfangssequenz beim Verbindungsaufbau auch noch den eigentlichen symmetrischen Schlüssel für den anschließenden Transport der wichtigen Daten rekonstruieren... aber genau dieser wurde ja gar nicht übertragen, sondern ebenfalls dynamisch und nur einmalig geltend ermittelt.

Wie soll das alles funktionieren mit der angeblich fehlenden Sicherheit bei RSA2048 bei kurzzeitigen Anwähl-OpenVPN-Verbindungen? Ich weiss nicht, ob ich da jetzt falsche Rückschlüsse ziehe, aber in RSA8192 sehe ich jedenfalls überhaupt keinen Sinn. Wenn ich das nächste Mal meine CA neu erstelle, werde ich wohl 3072 Bit vorgeben.... aber höher...?... sicher nicht.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von schorsch_76 » 05.11.2019 20:45:05

TomL hat geschrieben: ↑ zum Beitrag ↑
05.11.2019 18:43:19
Bei OpenVPN-Verbindungen reden wir aber nicht über die langfristige Speicherung von Daten, sondern nur über eine extrem kurzfristige Ad-Hoc-Gültigkeit eines asymmetrischen Schlüssels, wobei die eigentlichen schützenswerten Daten ja anschließend sowieso via AES256 verschlüsselt werden. Daraus schließe ich, selbst wenn irgendeine Institution heute meinen VPN-Traffic mitschneiden würde, könnten sie wahrscheinlich irgendwann in den nächsten Jahren diese RSA2048-Verschlüsselung knacken. Aber sie müssten dann aus dieser sehr kurzen Anfangssequenz beim Verbindungsaufbau auch noch den eigentlichen symmetrischen Schlüssel für den anschließenden Transport der wichtigen Daten rekonstruieren... aber genau dieser wurde ja gar nicht übertragen, sondern ebenfalls dynamisch und nur einmalig geltend ermittelt.

Wie soll das alles funktionieren mit der angeblich fehlenden Sicherheit bei RSA2048 bei kurzzeitigen Anwähl-OpenVPN-Verbindungen? Ich weiss nicht, ob ich da jetzt falsche Rückschlüsse ziehe, aber in RSA8192 sehe ich jedenfalls überhaupt keinen Sinn. Wenn ich das nächste Mal meine CA neu erstelle, werde ich wohl 3072 Bit vorgeben.... aber höher...?... sicher nicht.
Es hängt vom Verfahren ab das angewendet wird, wie und ob der Schlüssel zurück gerechnet werden kann. Wenn PFS nicht an ist, wird der Server Key verwendet. Per PSA wird der dann ausgetauscht. Wenn dieser Key dann bekannt ist (wie auch immer, Diebstahl, entschlüsselt, gebrochen durch Heartbleed oder was auch immer), kann der restliche Verkehr der bisher aufgezeichnet wurde und in Zukunft passiert, entschlüsselt werden. Das Problem ist: Die Konfiguration ist nicht immer leicht und hier liegt der Teufel im Detail. :!:

Bei SSL und Apache sind die Cipher sicher, welche mit DH_ DHE_ anfangen. Bei openvpn muss reneg-* genutzt werden bei Server und Client um PFS zu nutzen. Wenn das auf 0 ist, wird der Server Key verwendet und alles läuft, aber kein PFS ...

Da ich weis, das ca 3000 Bit bei RSA noch etwas reichen, geh ich auf 4096 Bit: Weil: Es macht bei mir keinen Unterschied ob ich hier beim Verbindungsaufbau mit RSA 4096 rechne oder mir RSA2048. Ich baue nur ein paar Verbindungen auf. Nicht wie ein großer VPN Anbieter. ;) Bis RSA8192 würde ich auch noch nicht gehen. Wir haben noch nicht 2050 :-D .

Ich fand beim CCC immer die Vorträge von Tanja Lange und DJB sehr informativ. :)

[1] https://de.wikipedia.org/wiki/Perfect_Forward_Secrecy
[2] https://de.wikipedia.org/wiki/Diffie-He ... laustausch
[3] https://www.heise.de/security/artikel/Z ... 23800.html
[4] https://bettercrypto.org/#_forward_secrecy
[5] https://community.openvpn.net/openvpn/w ... n24ManPage

TomL

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von TomL » 05.11.2019 20:50:40

schorsch_76 hat geschrieben: ↑ zum Beitrag ↑
05.11.2019 20:45:05
Es hängt vom Verfahren ab das angewendet wird, wie und ob der Schlüssel zurück gerechnet werden kann. Wenn PFS nicht an ist, wird der Server Key verwendet.
Ja, richtig, das betrifft die typischen Static-Key-Konfigurationen mit OpenVPN ... okay, aber ist das ist ja bekannt, dass es damit keine PFS gibt. Mit DH ist das jedoch gegeben, der aktuell verwendete Sitzungsschlüssel hat NUR für die Sitzung Gültigkeit und ist imho nicht mal mit bekannten Keyfiles und gehacktem RSA-Traffic rückwirkend rekonstruierbar.

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von schorsch_76 » 05.11.2019 20:56:43

TomL hat geschrieben: ↑ zum Beitrag ↑
05.11.2019 20:50:40
schorsch_76 hat geschrieben: ↑ zum Beitrag ↑
05.11.2019 20:45:05
Es hängt vom Verfahren ab das angewendet wird, wie und ob der Schlüssel zurück gerechnet werden kann. Wenn PFS nicht an ist, wird der Server Key verwendet.
Ja, richtig, das betrifft die typischen Static-Key-Konfigurationen mit OpenVPN ... okay, aber ist das ist ja bekannt, dass es damit keine PFS gibt. Mit DH ist das jedoch gegeben, der aktuell verwendete Sitzungsschlüssel hat NUR für die Sitzung Gültigkeit und ist imho nicht mal mit bekannten Keyfiles und gehacktem RSA-Traffic rückwirkend rekonstruierbar.
Genau! So ist auch mein Verständnis :!:

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von wanne » 06.11.2019 05:21:44

Mit DH ist das jedoch gegeben, der aktuell verwendete Sitzungsschlüssel hat NUR für die Sitzung Gültigkeit und ist imho nicht mal mit bekannten Keyfiles und gehacktem RSA-Traffic rückwirkend rekonstruierbar.
Das problem ist, dass sich alle Angriffe auf RSA (Die sich nicht fixen lassen. Die ganzem Bleichenbacher sind ja konkrete Implementierungsfehler. Wenn auch notorisch bei RSA.) auch auf DH übertragen lassen. (Ich glaube wir haben seit neuestem sogar einen Beweis dafür, dass das wirklich immer geht. Auf jeden Fall war das in der Vergangenheit so.)
Sprich wenn du PFS benutzt verlagerst du das Problem nur auf die DHE-Schlüsselläge.
Während für so ein Setup die RSA-Schlüssellängen entsprechend irrelevanter sind, weil sie live von einem MITM geknackt werden müssten, sind sie das für DHE nicht und entsprechend wichtig sind dann dort längere Schlüssellängen. In sofern finde ich PFS ein bisschen overhyped. Klar das hilft gegen den Diebstahl von Schlüsseln. Jemand der wegspeichert und nacher entschlüsseln will, kann das aber weiter tun. – Er muss dann halt nur DH knacken. (und die DH-Parameter lassen sich leider oft nicht so einfach konfigurieren. Bei OpenVPN ist das aber relativ obvius.)


Zum Thema Schlüssellänge. Es ist natürlich weitaus wahrscheinlicher dass einen mal wieder irgend ein Implementierungsehler einholt, als, dass man konkret wegen der Schlüssellänge geknackt wird. Aber mein erster RSA-Key hatte 512Bit. Das sollte man wirklich nicht mehr verwenden. (Bitte beachten: Das knacken von RSA keys ist exponentiell mit der Länge! 1024Bit ist ne gaaanz andere Nummer als 512Bit. Die Leute aus Logjam haben das z.B. gemacht um kaputte TLS-Implementierungen angreifen zu können. Das ist kein theoretisches szenario. Und ist der Key ein mal geknackt: Kannst du die zwischenergebnisse für jeden Verbindungsaufau wiederverwerten, und kannst dann auch neue Nachrichten in Sekunden entschlüsseln.) Der Aufwand das zu beheben ist dagegen weitestgehend eine größere Zahl in ein Configfile zu schreiben. Das mit den zu kurzen Schlüsseln passiert mir kein zweites mal...
Entsprechend laufen meine DH-Parameter auf 6000Bit. Nicht dass es wahrscheinlich ist, dass das mal irgend wann hilft. Aber bis auf die Zeit zum generieren, kostet mich das einfach nichts und z.B. Logjam ist damit einfach an mir vorüber gegangen. Und man kann die btw. recyclen. Kann die auch einfach auf einem Leistungsstarken Rechner für alle generieren. (Du kannst glaube ich auch einfach die nehmen: https://tools.ietf.org/html/rfc3526. Gibt's da irgend welche Einwände?)


Das mit den Schlüssellängen bei RSA und DH ist btw. eine Besonderheit:
Bei normaler Verschlüssung, die per brute Force (AES/(3)DES/CAMELLIA/CAST5...) unterschied zwischen deinem modernen i5 und der vollen Microsoft Acure Cloud. (Die wohl im Moment gerade die Amazon-Cloud überholt hat,) (Also die CPU Leistung für alle Nutzer zusammen, wenn du das alles mietest.) geben dir in gleicher Zeit nicht mal 20Bit. Alle CPUs der Welt ca. 40Bit. (Hab jetzt einfach mal deren Stromverbrauch der Rechenzentren genommen und angenommen, dass sie einigermaßen sparsame Prozessoren haben. SWR/Microsoaft hat dafür zahlen.)
Auf deinem i5 wirst du in einem Jahr so 45Bit knacken können. Bist du mit der vollen Azure Cloud in einem Jahr bei 65Bit. (Und dann hast du ein ganzen Jahr gebraucht.)
Der größte Brute-Force den man mit CPUs gemacht hat, war wohl Facebook mit seinem Onion-Service, der wohl so 50Bit gebrute-Forced hat. (Die wollten einen Schlüssel, sodass der Key mit facebook+irgend ein Wort in base32 anfängt.)
Kurz: Mit mehr CPUs kommst du da nicht weit. Sinnvoller weise kaufst du dir irgend welche Spezialhardware.
Je nach Budget werden das dann zuerst Grafikkarten dann FPGAs und dann ASICs, die zwar mehr kosten aber trotzdem um viele Größenordnungen bessere Preis-Leistungsverhältnise zum Knacken haben.
Damit kommst du dann mit einem Normalen Budget von einigen 100000€ in den Bereich wo die ganze Azure Cloud schaffen würde. Entsprechend willst du mehr wie die 64Bit haben.
Google konnte mit Grafikkarten SHA-1 für den zum Kollisionen erzeugen 2^65 (Also entsprechend 65Bit.) nötig sind, knacken.
Das ist das größte Rechenprojekt, das mir bekannt ist.

Aber bei RSA verbessert sich kontinuierlich die Mathematik: Statt schlicht schlüssel durchzuprobieren, finden sich seit 1643 (Seit Fermats Faktorisierungsmethode) alle paar Jahre kontinuierlich bessere Verfahren zum knacken.
Da die Nachfolger meist nur minimal besser oder gar schlechter als die Vorgänger waren hat das bis jetzt schlicht nur zu immer längeren Schlüsseln geführt. Trotzdem ist doppelt beunruhigend:
a) Man das weiter interpolieren, wie das BSI das macht und annehmen, dass es da weiter inkrementelle Verbesserungen gibt. Das führt zu den langen Schlüsselempfehlungen auf lange Sicht.
b) Man kann annehmen dass wenn es dauernd neue Entdeckungen auf dem Gebiet gibt auch irgend wann mal der große Durchbruch kommt, der sich dann auch nicht mehr mit noch längeren Schlüsseln fixen lässt. Daraus folgt die Empfehlung hin zu elliptischen Kurven

Man kann aber auch annehmen, dass auf einem Feld auf dem seit 2000 Jahren aktiv geforscht wird und es seit 350 Jahren nur inkrementelle Verbesserungen gibt nicht mehr so viel passiert und deswegen RSA den ECC-Algorithen vorziehen..

Zuletzt ist klar, dass Für Quantencomputer das Brechen von RSA oder ECC-Algorithmen kein Problem darstellt, wenn diese ausreichend groß sind. 2001 wurde ein Quantencomputer gebaut, der erfolgreich 4-Bit RSA knacken konnte. (Und damit mit ähnlich langen ECCs klar gekommen wäre.) 2012 war man dann bei 5Bits. Bei derertiger rate dauert es noch lange bis wir bei 2000Bit sind. Trotzdem weiß man dass z.B. die NSA ca. seit 2010 annimmt, dass die Fortschritte bei Quantencomputern bald Sprünge machen.
Google hat jetzt einen Quantencomputer mit 53Bit. Der kann zwar nicht faktrisieren. Aber wie ich das verstehe, ist es durchaus denkbar, dass man den dahingehend umbauen könnte.
Auch da erkauft man sich vermutlich ein paar Jahre mit längeren schlüsseln.

Aber im Allgemeinen stimmt es natürlich schon: Wenn du wirklich Langzeitsicherheit haben willst, musst du auf Verfahren wie AES oder so setzen wo weder Quantencomputer noch Matematische Durchbrüche eine wahrscheinliche Gefahr darstellen.
Leider ist das halt ein bisschen nervig, wenn man immer vorher auf sicherem Weg einen Key austauschen muss.
rot: Moderator wanne spricht, default: User wanne spricht.

sergej2018

Re: easyrsa: wie viel bit sinnvoll?

Beitrag von sergej2018 » 06.11.2019 09:24:41

Moin zusammen,

find das prima, welche Diskussion hier zustande kommt :)

@wanne: Warum bin ich bei symmetrischem AES vor Quantencomputern sicher?
Auch da kann man doch "einfach" den Key bruteforcen?

Ansonsten fand ich dein Argument gut zu sagen "hey, why not? Das Nutzen längerer RSA-Keys bedeutet für mich ja nur den einmaligen Aufwand beim Erstellen". Denn das war ja auch schon mein Eingangs-Argument: Im Grunde ist es kein Stress, einfach größere Keys/Zertifikate zu nutzen.

Antworten