[gelöst] Frage zu Certs (öffentlich + privat signiert) sowie Diffie-Hellman Key Exchange

[DarkTrinity]

Hallo liebe Community

ich versuche gerade mein Wissen zu TLS/SSL Zertifikaten zu vertiefen und es gibt da ein paar Unklarheiten - vielleicht kann mir ja jemand dazu einen Tipp geben

Bis jetzt "gab es für mich" immer nur 3 verschiedene Sorten von Zertifikaten:

• Selbstsignierte Zertifikate
  • haben garkeine Zertifizierungsstelle, da das Cert sich quasi selbst zertifiziert. Daher wäre die Bezeichnung "Selbstsignierend" in meinen Augen passender. DIe sollte man eher nicht benutzen. Dieses Cert ist oft in Netzwerktauglichen Peripheriegeräten (wie zB Druckern) vorhanden und kann bei guten Modellen gegen ein privat- oder öffentlich signiertes ausgetauscht werden.
• Privatsignierte Zertifikate
  • haben eine Zertifizierungsstelle, die ich selbst angelegt habe (CA). Das benutze ich zB in einem LAN, wo ich Webseiten entwickle bevor diese online gehen oder auch mal i-was teste.
• Öffentlich signierte Zertifikate
  • haben eine öffentlich anerkannte Zertifizierungsstelle. Sowas benutze ich auf meinem Webserver und zwar von Let's-Encrypt, wo die Zertifikate auf Domains bezogen sind

Soweit - Sogut

Nachdem ich meinen Testserver im LAN aktualisiert habe (u.a. Ubuntu auf Version 20), hatte ich plötzlich Probleme mit dem Abrufen der Test-Mailaccounts über einen Thunderbird Client. In den Logs fand ich dann sowas:
Apr 7 10:49:48 hostXXXXX dovecot: imap-login: Error: Failed to initialize SSL server context: Can't load DH parameters: error:1408518A:SSL routines:ssl3_ctx_ctrl:dh key too small: user=<>, rip=192.168.XXX.XXX, lip=192.168.XXX.XXX, session=<ezhkA16/hNLAqLwC>

Wegen diesem Problem bin ich auf die folgende Seite gestossen: https://weakdh.org/ und habe noch ein bissel rescherchiert

Ich habe dann einen "Diffi-Hellmann-Exchange Key" erstellt
openssl dhparam -out ./dh.pem 4096
und diesen in die Config von Dovecot und Postfix eingebaut
## dovecot ssl_dh = </opt/dhpem/dh.pem ## postfix smtpd_tls_dh1024_param_file = /opt/dhpem/dh.pem

Ergebnis: Emails sind wieder abrufbar

Auf der o.g. Seite wird ebenfalls empfohlen, dies für die Apache2- Webhosts zu machen.

Ok....

Aber ist dieses Diffie Hellman nicht eigentlich nur die hinter der Verschlüsselung stehende Berechnung ?

Anders gefragt:

1. Brauche ich dieses dh-param auch auf dem Webserver, der durch Lets-Encrypt versorgt wird, zwingend ?
2. Oder trat dieses Problem vielleicht nur deswegen auf meinem lokalen Testsever auf, weil die dort eingesetzten Zertifikate nicht ausreichend stark verschlüsselt sind ?
3. Kann man diesen Diffie-Hellman Parameter ergänzend zu dem "normalen" Zertifikat (ob nun privat oder öffentlich signiert) einsetzen oder ist es mehr ein "Entweder - Oder" ?
4. Ach ja - da gibts noch die "SSL Cipher Suites". Soweit ich verstanden habe, wird über diese Werte festgelegt, welcher genaue Verschlüsselungsalgorithmus zwischen Server und Client zur Anwendung kommen soll. Mit OpenSSL lassen sich Einträge ausgeben, die der Server umsetzen kann. So verstehe ich es zumindest - ist das auch richtig so ?
   
   PS Ist dieser DIffie-Hellman Parameter vielleicht eine Alternative zu der SSL Cipher Suites- Liste ?
   
   
5. I-wie habe ich immer noch nicht begriffen, was dieser "dh-Parameter" wirklich ist - hab nur "Vermutungen"

Es wäre toll, wenn ich hier einen entsprechenden Link oder eine kurze Erklärung dazu bekommen könnte. Ich habe selbst schon viel gegoogelt aber die o.g. Unklarheiten kriege ich irgendwie nicht

 

[d4f]

Bis jetzt "gab es für mich" immer nur 3 verschiedene Sorten von Zertifikaten:

Als kleine Anmerkung; das Root-Zertifikat von Kategorie 2 (private CA) ist auch self-signed da es keine höhergehende Chain hat. Um bei neuen CA die Vertrautheit zu garantieren verwendet man bei öffentlichen CA deshalb cross-signing, was einer Chain-of-trust zwischen Organisationen ist.

haben eine öffentlich anerkannte Zertifizierungsstelle.

öffentlich anerkannt ist nur richtig wenn du unter "öffentlich" schlicht die Mehrheit der Hersteller und/oder das Browser-CA Forum meinst.
Jeder Verwalter von CA-Datenbanken (Browser, Betriebssysteme, Java, ...) kann eigenständig entscheiden wer in seine Default-Liste kommt und wer fliegt. Deshalb kann eine CA von einigen Browser noch oder schon vertraut werden wenn andere Hersteller es nicht tun.
Einige Programme, bspw Filezilla, verwenden X509 aber ignorieren das ganze chain-of-trust Konzept aus Prinzip und betrachten jedes neue Zertifikat als unbekannt, egal wo es herkommt.

Aber ist dieses Diffie Hellman nicht eigentlich nur die hinter der Verschlüsselung stehende Berechnung ?

Diffie-Hellmann ist ein key-exchange Algorithmus, also das Verfahren welches ermöglicht dass 2 gegenseitig unbekannte Partner mittels asymmetrischer Kryptographie (public/private Key) einen gemeinsamen symmetrischen Key für die weitergehende (zumeist AES) Verschlüsslung finden. Der asymmetrische Schlüssel wird nicht für die ganze Dauer der Verbindung verwendet da der Aufwand um mehrere Grössenordnungen höher als bei symmetrischer Verschlüsslung ist.

Brauche ich dieses dh-param auch auf dem Webserver, der durch Lets-Encrypt versorgt wird, zwingend ?

Du zwingst hier über den Parameter eine Key-Exchange Grösse. Das gleiche Ergebnis hast du aber wenn unsichere Keyexchanges schlicht deaktiviert sind.

Oder trat dieses Problem vielleicht nur deswegen auf meinem lokalen Testsever auf, weil die dort eingesetzten Zertifikate nicht ausreichend stark verschlüsselt sind ?

Das Problem hier ist nicht die Key-Lenge des Zertifikates (das lässt sich nach Signatur des Keys nicht mehr verändern) sondern die zum Diffie-hellmann Exchange verwendeten Modulo.

Ach ja - da gibts noch die "SSL Cipher Suites". Soweit ich verstanden habe, wird über diese Werte festgelegt, welcher genaue Verschlüsselungsalgorithmus zwischen Server und Client zur Anwendung kommen soll.

Die Cipher-Suite steuert den ganzen Verschlüsslungskreis. Es gibt unterschiedliche Syntaxen und Präzisionsgraden der Syntax, zB "DH" definiert meist Diffie-Hellman, die bekannteste Alternative ist "RSA" (zB bei SSH-Keys sehr viel im Einsatz).
Ein hochspezifisches Beispiel ist ECDHE-RSA-AES256-GCM-SHA384, das steht für
* Key Exchange = elliptic-curve Diffie-Hellman ephemeral (also ein moderner nicht-lineare Diffie-hellmann mit perfect-forward-secrecy Unterstützung
* Authentifizierung = RSA
* Symmetrische Verschlüsslung = AES256 im Galois-Counter Modus
* SHA2 384bit als Hashing-Algorithmus

Daneben gibt es noch die Protocol-Version (SSLx oder TLS1.x), wobei TLS1.2 und TLS1.3 aktueller Stand der Technik sind und alles unter TLS1.1 (also TLS1.0, SSL3,SSL2,...) als gebrochen gelten.

Wünscheswert wäre den höchstmöglichen Verschlüsslungsgrad in die Ciphersuite zu packen, Protocol-Level TLS1.3 und fertig... So einfach ist das aber nicht da du ja auch ältere Geräte unterstützen musst. Da es aber oft möglich ist spezifische Kombinationen an zu greifen, gibt es empfohlene "best-practice" Listen welche hohe Sicherheit bei niedrigen Kompatibilitätsproblemen garantieren können.
Eine solche Liste wäre:

Cipherli.st - Strong ciphers for Apache, nginx and Lighttpd

Cipherli.st - Strong ciphers for Apache, nginx and Lighttpd

syslink.pl

Falls du genauere Daten über einen spezifischen Cipher willst, empfehle ich:

Ciphersuite Info

A searchable directory of TLS ciphersuites

ciphersuite.info

Um deine eigene Konfiguration zu testen, runden wir ab mit_

Qualys SSL Labs

Bringing you the best SSL/TLS and PKI testing tools and documentation.

www.ssllabs.com

Ich habe selbst schon viel gegoogelt aber die o.g. Unklarheiten kriege ich irgendwie nicht

Abhängig von deiner Mathematik/Algebra-Affinität empfehle ich einen Diffie-Hellman Keyexchange auf papier durch zu führen, dann "klickt" das Verständnis dazu gerne. Wird auch gerne als Grundlage der Information gelehrt (na gut, von den Studenten weniger gerne) - aber es ist sehr interessant zu kennen. Natürlich nicht mit internet-üblichen Keys, schliesslich soll man ja noch fertig werden Eine Beispielseite:

https://www.irongeek.com/diffie-hellman.php