selbstsigniertes SSL Zertifikat riskant?

[Gelöschtes Mitglied 63700]

Vorweg, ich bin IT-Laie.

Ich habe mir einen eigenen Mail-Server (hMailServer - Windows) aufgesetzt. Nun möchte ich auch mit 'nem Client von außerhalb darauf zugreifen können und nicht nur aus dem LAN. Ich habe mir daher von einer Website ein Self-Signed Certificate für meine dyndns-Adresse generieren lassen.
Nach Bestätigung akzeptiert Thunderbird auch dieses und ich kann E-Mails abrufen und senden.

Meine eigentliche Frage ist, wie sicher ist das Ganze?
Kann ich leichter durch einen MITM komprimiert werden?

Da ich von Linux keine Ahnung habe und keinen Webserver betreibe, scheidet wohl Let’s Encrypt erst mal aus.

 

[fdsonne]

Die Unsicherheit bei dem Thema kommt bestenfalls, wenn du gleichsam von der Seite dort deinen private Key hast bekommen...
Denn dann hat den potentiell ein "Dritter" und kann damit einfach und schnell die mit diesem Key verschlüsselten Verbindungen öffnen und im Klartext auslesen.
Hast du den Key aber nicht, sollte grundsätzlich nicht sooo viel dagegen sprechen.

Sinnvoller wäre aber trotzdem, wenn es so oder so selfsigned ist/sein soll, das Zertifikat selbst zu erstellen, inkl. Key und allem drum und dran. Dann hast du es in der Hand und definitiv auch kein Dritter die Finger im Spiel.
Anleitungen im Netz gibts für OpenSSL bspw. wie Sand am Meer. Das brauchst du effektiv auch vorerst nur einmal... Sprich CA installieren, Zertifikat rauslassen, Key rauslassen und am Mailer einspielen -> fertig. Achso, auf deinen Clients das CA Certifikat hinterlegen nicht vergessen, sonst gibts ggf. Probleme.


Willst du mehr Sicherheit, brauch es dann schon was richtiges...
EV-Zertifikate bspw. Da siehst du dann im Client (Browser bspw.), ob jemand MITM spielt. Das ist aber auch nicht sooo viel mehr Sicherheit. Vor allem nicht bei einem Clientzugriff über ein Mail Programm, denn Thunderbird wird es wohl nicht interessieren, wer das Zertifikat signiert hat bzw. wo es her kommt. Wäre aber für einen Webmail Zugriff über den Browser ggf. sinnvoll.



Wichtiger als den ganzen Zertifikatskram halte ich aber defakto die Settings am "Server", wenn du dort aufgrund von Unwissenheit oder technischer Notwendigkeit (alte Clients) bspw. unsichere Verschlüsslungsmethoden zulässt/zulassen musst, dann hast du effektiv ganz andere Einfallstore und Angriffsvektoren. Ich würde primär auch das Teil nicht direkt public stellen. Sprich kein Port Forwarding von außen direkt bis in die Kiste rein tätigen, sondern mindestens mal einen Reverse Proxy dazwischen schalten, der den Spaß dann terminiert und unliebsame Zugriffe von außen direkt wegdropt. VirenScan für Up/Down im Stream ist auch nicht ganz verkehrt. Denn was nutzt dir die sicherste Kiste, wenn das Ding einfach virenverseuchte Mails direkt in den Speicher lädt und sich damit selbst lahmlegt? -> oder dann von dor aus weiter ausbricht?

 

[fax668]

Meine eigentliche Frage ist, wie sicher ist das Ganze?

Unsicher. Dieser Webdienst ist eine Frechheit.

Kann ich leichter durch einen MITM komprimiert werden?

Der Betreiber dieses Webdienstes könnte das, der kennt nämlich deinen privaten Schlüssel. Dazu wird das alles noch über eine unverschlüsselte Verbindung abgewickelt. Etwas unprofessionelleres habe ich schon lange nicht mehr gesehen.

Lass dir ein Zertifikat von CAcert.org ausstellen. Oder lade dir die OpenSSL Binaries für Windows runter. Es gibt hundertfach Anleitungen im Web, wie man ein Zertifikat damit erzeugt. Von Microsoft gibt es auch ein einfach zu bedienendes Tool names selfssl. Das ist allerdings schon ziemlich alt und ich weiß nicht, ob man das noch guten Gewissens empfehlen kann.

Generell sind selbst signierte Zertifikate sehr sicher. Wichtig ist, dass niemand Zugriff auf den privaten Schlüssel hat. Thunderbird beschwert sich zwar, dass er das Zertifikat nicht kennt, aber das kannst du ihm ja beibringen.

 

[fax668]

Natürlich schützt es vor MITM. MITM ist nur möglich, wenn der Mann in der Mitte dir entweder dein eigenes Zertifikat unterschieben kann oder dein Client das Zertifikat nicht ordentlich prüft. Dein eigenes Zertifikat kann nur jemand nachmachen, der deinen privaten Schlüssel hat. Und wie du schon selbst schreibst, prüft Thunderbird das Zertifikat und macht nicht weiter ohne deine Bestätigung.

 

[fax668]

Bei deinem eigenen Zertifikat weißt du genau, was du erzeugt hast und kennst den Fingerabdruck. Den kannst du jederzeit auf dem Client prüfen. Bei einem Zertifikat von einer Certificate Authority (CA) vertraust du nicht dem eigentlichen Zertifikat sondern dem übergeordneten Zertifikat der CA, das Windows in seinem Truststore abgelegt hat. Wer garantiert dir jetzt, dass z.B. die NSA diese CA nicht unterlaufen hat? Siehe z.B.: https://en.wikipedia.org/wiki/DigiNotar.

Ich will jetzt dieses System nicht generell schlecht reden, aber die Behauptung, dass selbst ausgestellte Zertifikate weniger sicher wären, ist faktisch falsch und im Gegenteil halte ich die normalerweise für sicherer, wenn man angemessen vorsichtig vorgeht.

 

[fax668]

Ich z.B. habe nicht vor mit den Fingerabdruck irgendwo zu notieren.

Das macht der Client für dich beim ersten Mal. Und falls du mal einen neuen Client hast, schaust du notfalls halt kurz auf deinem Server nach.

 

[fax668]

Hier gibt's kostenlose Zertifikate, falls dir cacert.org nicht zusagt: https://www.startssl.com/Support?v=1

 

[TCM]

Eine externe CA ist immer nur notwendig, wenn du dich gegenüber dritten Clients authentifizieren willst, die du nicht selbst kontrollierst. Eine eigene CA oder direkt ein eigenes Zertifikat, von dem du den Fingerprint kennst und auf dem Client überprüfen kannst, ist immer sozusagen der Königsweg.

Externe CAs muss man als notwendiges Übel ansehen, die einzig den Zweck haben, deine Dienste für unbekannte Drittclients authentifizierbar zu machen. Wenn möglich, immer selbst signieren und überprüfen.

Edit: Eigene Zertifikate aber trotzdem nicht von irgendwelchen Dritten generieren lassen, sondern lokal mit openssl(1) selbermachen, auf einer Kiste mit gutem RNG.

 

[fdsonne]

Authentifizierung ist mit der entscheidende Vorteil, den ein "ordentliches" Zertifikat hätte. Sobald ich eine Ausnahme hinzufügen muss, bin ich derjenige, der das Zertifikat authentifiziert.
Jetzt stell Dir vor, ich würde anderen Leuten ebenfalls Accounts anlegen, spätestens für die wird es dann problematisch, weil die keine Übersicht haben, welches Zertifikat jetzt wirklich das richtige ist.

Dann gibst du den "Leuten" sinnvollerweise das/dein CA Zertifikat dazu, welches die Zertifikate die dort im Mailing genutzt werden, signiert hat...

Im Endeffekt läuft der ganze public Kram exakt identisch ab, dein Client (Windows, Linux, Browser usw.) vertraut gewissen ausgewählten CAs. Das ist so, weil das irgendwann mal wer definiert hat. Entsprechend werden diese Root-CA Zertifikate bzw. die Zwischenzertifikate teils ebenso, per default an die Clients ausgeliefert.
Im Grunde ist das allerdings eben auch der größte Nachteil des ganzen Konstrukts. Denn JEDER Client mit entsprechenden Zertifikaten im Bauch vertraut automatisch JEDEM Zertifikat, was von der entsprechenden CA signiert wurde. Ob du nun willst oder nicht. Kannst dich nicht gegen zur Wehr setzen! Du kannst bestenfalls ein paar (oder alle) Zertifikate, die per default ausgeliefert werden, rausschmeißen. Nur wirst du wohl damit eine ganze Menge Probleme bekommen, weil dann effektiv sogut wie gar nix mehr geht, was SSL nutzt.

Den Part, den fax668 meint, du erstellst selbst eine Root-CA und du signierst mit dieser Root-CA Zertifikate zur eigenen Nutzung. -> dann muss natürlich auch JEDER Client diesem Root-CA Zertifikat vertrauen. Das übernimmt halt keiner für dich, das musst du dann selbst machen. Dafür bekommst du aber die "absolute" Sicherheit, da nur du mit dieser Root-CA Zertifikate signieren kannst. Und jeder Dritte, den du Services anbietest, hat genau diesen Vorteil (sofern er dir als Person traut)
Mit den public Zertifikatsstellen hast du halt den Umstand, du wirst quasi zu einem Vertrauen gezwungen Weil die Hersteller der Software da einfach mal Zertifikate rein knallen, dehnen du vielleicht gar nicht vertrauen willst.


PS: ob Lets Encrypt Zertifikate überhaupt gehen würden in deinem Konstrukt?
Kommt halt immer drauf an, was das für Zertifikate sind...
Lets Encrypt hat an der Stelle bspw. mir bekanntermaßen einen kleinen Nachteil -> du musst das automatisieren. Sonst änderst du alle Nase lang die Zertifikate auf dem Server Denn die validity ist sehr kurz. Das ist zwar auch ein Stück "Sicherheit", aber eben bei handarbeit echt nervig.

 

[Morpheus2200]

Ich verwende letsencrypt zwar in einer echten Linux Umgebung, aber diese Lösung sollte eigentlich für dich funktionieren:

kleine linux-vm, auf der eigentlich nix läuft außer letsencrypt und dem entsprechenden renewal-cronjob.

Beispiel virtualbox:

Bevor du letsencrypt auf der vm installierst, richtest du ein share via Virtualbox ein. Z.B. vom einem Ordner 'Certs', das share heißt z.B. auch 'certs'.

in die /etc/fstab trägst du nun ein:

certs   /etc/letsencrypt   vboxsf   rw  0   0

neustarten, dann letsencrypt installieren und ausführen. cronjob für den monatlichen renewal einrichten.

Vom Windows aus solltest du nun im freigegebenen Ordner 'Certs'\live\<namedeinerdomain> deine Zertifikate/keys finden.

Voila

 

[fax668]

Wie schon geschrieben - StartSSL. Gibt keinen guten Grund, sich mit den Let's Encrypt Skripten rumzuschlagen, IMHO. Fefe hat das ein bisschen drastischer formuliert: https://blog.fefe.de/?ts=a89f4ed6

 

[TCM]

Man muss ja nicht den LE-Client benutzen.

 

[fax668]

Unter den Android Einstellungen - Sicherheit - Zertifikate installieren kannst du eigene Zertifikate installieren. Habe ich selbst allerdings noch nie ausprobiert.

 

[fax668]

Probier mal K-9 Mail. Angeblich fragt das beim ersten Mal, ob man das Zertifikat akzeptieren will und sollte danach nicht mehr nachfragen.

 

[fdsonne]

Musst du zwingend IMAP machen?
Ich habe Null Probleme mit ActiveSync und Android bei einem selfsigned Zertifikat. Ändert sich das Zertifikat am Server, gibts ne Warnung auf dem Phone, die kann man dann einmal oder dauerhaft! bestätigen und es läuft...
Gleiches gilt auch für iPhones, fals das mal relevant sein sollte.
Witzig dabei ist, dass ich anfangs mal Probleme mit Windows Mobile hatte, das war aber noch zu Zeiten vor dem 10er... Maybe sogar vor dem 8er, bin ich nicht 100% sicher, sprich das wollte keine selfsigned Zertifikate fressen...

 

[fax668]

Ach ja, hatte ich vergessen. S/MIME geht nicht mit K-9 Mail, nur SSL von und zum Mail Server. OpenPGP geht, wenn OpenKeychain installiert ist.

Aber wieso kommst du jetzt eigentlich mit S/MIME an? Ich dachte, du wolltest dich gegenüber dem Mailserver authentifizieren bzw. der Server bei dir? S/MIME hat nichts damit zu tun, das braucht man für Ende-zu-Ende verschlüsselte Emails.

 

[NTB]

K9 fragt bei Einrichtung des Kontos, ob man das Zertifikat akzeptieren möchte und danach nicht mehr. Das funktioniert ohne Probleme.

 

[fax668]

Interessant. Traue keiner Software, die du nicht selbst getestet hast.