Sicherstes SSL-Cert generieren?

[sergej2018]

Hi zusammen,

für den heimischen Webserver (über's Internet erreichbar) würde ich gern ein möglichst sicheres SSL-Zertifikat generieren.
Welche Parameter nutzt man dafür am besten?
Habe jetzt z.B. mit dem hier experimentiert:

Code: Alles auswählen

openssl req -x509 -nodes -days 365 -newkey rsa:16384 -keyout server.key -out server.crt

Dass die Apache-config selber um einiges wichtiger ist, ist schon klar

[Lord_Carlos]

Ich habe bei meinem Homeserver Let's encrypt benutzt. Das wird automatisch erneuert und ich kann auch ein Link an Freunde senden ohne das die sich Wundern warum der Browser eine rote Warnmeldung anzeigt.

Mann muss ein dyndns haben die damit klar kommen. Ich habe dynv6 genommen. Ist aber gerade nicht erreichbar? https://dynv6.com/

[uname]

Ich rate auch zu offiziellen Zertifikaten z. B. von Let’s Encrypt. Die "rote Warnmeldung" bei selbstsignierten Zertifikaten erscheint nur, da der Browser das zugehörige root-Zertifikat nicht kennt. Bei Let’s Encrypt hat man eine vollständige Zertifikatshierachie, die von jeden Browser akzeptiert wird. Verwendet man das Zertifikat nur selbst kann man ein selbst signiertes Zertifikat (natürlich erst nach Prüfung des Fingerprints) auch dauerhaft als Ausnahme akzeptieren.

[sergej2018]

Genau und ich würde einfach gern ein eigenes nutzen
Was ich nur festgestellt habe: Manche Geräte scheinen mit Zertifikaten von 16384 bit ihre Probleme zu haben...

[bluestar]

Was ich nur festgestellt habe: Manche Geräte scheinen mit Zertifikaten von 16384 bit ihre Probleme zu haben...

Du solltest dich erst einmal in OpenSSL einlesen, ich würde dir zu ECC raten und RSA den Rücken kehren.

Zu deiner Frage, wie man die Sicherheit erhöhen kann:
* Verwende ein Hardware Security Modul / Chipkarte.
* Beschäftige dich intensiv mit Debian Hardening.
* Kompiliere deine SSL Bibliotheken selbst und dabei deaktiverst du alle Algorithmen / Hash-Verfahren bis auf das mit dem du später arbeiten willst... Beachte hierbei das du die Kompatibilität deiner eigenen SSL-Bibliothek damit signifikant reduzierst und somit viele Client SSL Bibliotheken aussperrst... Also evaluierst du vorab deine "Clients" und beziehst deren SSL-Fähigkeiten beim Compilieren deiner SSL-Biblitohek mit in die Betrachtungsweise ein.

Wie man die Sicherheit nicht erhöht:
* Einfach einen x-beliebig langen RSA Schlüssel erzeugen.

[sergej2018]

Deine Vorschläge scheinen mir sinnvoll!
Was mich nur stutzig macht: Ich lese bei ECC an vielen Stellen über Zweifel. Insbesondere bei Brainpool und auch ansonsten scheint die u.A. NSA da ja beim Entwurf geholfen zu haben?

Und wenn ich das recht verstehe ist ECC ja nicht "sicherer" als RSA? Sondern lediglich effizienter in der Berechnung. Was aber auf Desktop-Clients - und selbst auf Smartphones - kein Problem sein dürfte.

[bluestar]

Und wenn ich das recht verstehe ist ECC ja nicht "sicherer" als RSA? Sondern lediglich effizienter in der Berechnung. Was aber auf Desktop-Clients - und selbst auf Smartphones - kein Problem sein dürfte.

Du hast die Clients nicht näher spezifiziert.

Da ECC neuer ist, dürftest du weniger Kompatibilitätsprobleme mit langen Schlüsseln haben.

Die RSA Implementationen sind halt teilweise halt recht alt und somit ist hier eine höhere Fehleranfälligkeit gegeben.

Bleibt schlussendlich die Gretchenfrage: Wozu das Ganze?

[wanne]

Da ECC neuer ist, dürftest du weniger Kompatibilitätsprobleme mit langen Schlüsseln haben.

Nein. ECDSA braucht kurven. Die haben feste Länge.
Mein Firefox kann laut wireshark secp256r1 secp384r1 secp512r1 und ecdh_x25519 der chromium secp256r1 secp384r1 und ecdh_x25519 Liest man auf Wikipedia nach kann Safari secp192r1 secp256r1 und secp512r1. Bleibt also lediglich secp256r1 wenn man alle drei großen supporten will. Damit hat man eine feste Länge von 256Bit. Was anderes geht nicht.

Die RSA Implementationen sind halt teilweise halt recht alt und somit ist hier eine höhere Fehleranfälligkeit gegeben.

Umgekehrt wird ein Schuh daraus: Jeder der mal mit brandneuer Software gearbeitet hat weiß, dass die immer um Größenordnungen mehr Fehler hat als alte abgehangene, wo schon viele Fehler behoben wurden.

Grundsätzlich gilt folgendes:
* Quantencomputer werden ECDSA etwa 2/3 mal so schnell knacken wie RSA. => So ein 4096Bit RSA wird um länger vor Quantencomputer sicher sein als 256Bit ECDSA. Die frage ist, ob das einen Unterschied macht. 2001 Gab es den ersten Quantencomputer der bis zu 4Bit RSA (oder theoretisch 2Bit EDSA) brechen konnte. Damit wurde erfolgreich 15=3*5 faktorisiert. 2012 ist die Größte durch Shor's Algorithmus gebrochene Zahl 21=7*3 (5Bit). Es ist fraglich ob jemand der einen Quantencomputer, der 256Bit ECDSA brechen kann nicht auch einen bauen könnte, der 4096Bit RSA bricht. Trotzdem: Wer Angst vor Quantencomputern hat sollte auf RSA setzen
* secp256r1 ist eine von der NSA desighnte wer Angst davor hat, dass die Backdoors eingebaut hat sollte RSA nutzen.
* Die forschung im Bereich EC ist sehr geheimdienstlastig. Es ist wahrscheinlich, dass eventuelle Sicherheitslücken dem Geheimdiensten deutlich schneller zur Verfügung stehen als dem Rest der Welt.
* Die Elementare Zahlentheorie ist zwar eines der ältesten Gebiete der Mathematik. Weshalb zur Erfindung von RSA angenommen wurde, dass sich da nicht mehr viel tut und RSA sicher bleibt. Zwischen 200v Chr. und 1981 hat sich da nicht viel getan. Seither ist da aber wieder ordentlich Bewegung drin. Dies führte dazu, das RSA immer längere schlüssel brauchte. Einige meinen dass ein Durchbruch jetzt kurz bevor steht. Wer angst vor weiteren Fortschritten dort hat sollte auf ECDSA setzen.
* Im Gegensatz dazu sind universelle Algebra und elliptische Kurven recht jung. Keiner hat Ahnung ob da jemand morgen was völlig neues entdeckt. Wer Angst vor Fortschritten dort hat sollte bei RSA bleiben.
* Der Effiziente und Seitenkanalfreie RSA-Implementirungen zu schreiben ist extrem schwer und somit Seitenkanäle aufgrund von Fehlern in der Software bei RSA deutlich wahrscheinlicher. ecdh_x25519 ist dagegen von Anfang an darauf designend worden, möglichst einfach zu implementieren zu sein. Die Gefahr von Seitenkanälen spricht deswegen dick gegen RSA.
* secp256r1 hat dagegen andere Fallstricke. Wer bei der Implementierung nicht aufpasst hat gerne mal einen Bug der nicht nur Seitenkanäle öffnet sonder sogar den geheimen Schlüssel offenbart. Das spricht dick gegen secp256r1.

* Sollte RSA oder DH grundsätzlich gebrochen werden, ist extrem wahrscheinlich, dass dies sich auch auf den jeweils anderen portieren lässt passiert. Bei RSA -> DH ist das glaube ich sogar vor ein paar Jahren bewiesen worden. Wer RSA bricht kann ach DH brechen. Sicher sind also eher RSA mit DH oder ECDH mit ECDSA. Die übliche ECDH-RSA Variante hat die doppelte Angriffsfläche.

[jph]

für den heimischen Webserver (über's Internet erreichbar) würde ich gern ein möglichst sicheres SSL-Zertifikat generieren.

Nutze etwas wie Let’s Encrypt, was dir bereits empfohlen wurde. Bei selbstgenerierten Zertifikaten wirst du immer das Problem haben, dass es vom Client zurückgewiesen wird. Wenn du bspw. eine Nextcloud betreiben willst, musst du jedem, dem du eine Dateifreigabe per Link schickst, erst einmal erklären, dass er die Sicherheitswarnung wegklicken soll und dass das in deinem Fall überhaupt kein Problem sein soll. Ist aus eigener Erfahrung ziemlich lästig.

Bei Let’s Encrypt kannst du zudem davon ausgehen, dass das von Leuten betrieben wird, die sich mit der Materie auskennen, d.h. die Zertifikate werden sinnvolle Parameter und Schlüssellängen verwenden.

[sergej2018]

Muss mich dann über Let's encrypt mal genauer einlesen.
Denn das Wegklicken der Fehlermeldung kann in der Tat lästig sein. Da der Server aber nur von Mitglieder der eigenen Familie verwendet wird, stellt das im Normalfall kein Problem dar.

[Lord_Carlos]

Dazu werden Let's encrypt Certificate auch noch automatisch erneuert.

[wanne]

Bei Let’s Encrypt kannst du zudem davon ausgehen, dass das von Leuten betrieben wird, die sich mit der Materie auskennen, d.h. die Zertifikate werden sinnvolle Parameter und Schlüssellängen verwenden.

Die Keys generierst du (wie bei jedem anderen vertrauenswürdigen Service) ja selbst.