Generell hat mich dieses Konzept der Schlüsselserver nie wirklich überzeugt und ich lade daher grundsätzlich keine Ö-Schlüssel hoch, sondern verteile sie anders.

Dennoch teile ich nur bedingt dieses Rundumbashing gegen Email und XMPP. Gerade in Zeiten der kommenden Backdoors bei alternativen Messengern könnten beide noch mal ein Revival erleben, da beide bei korrekter Implementierung und Umsetzung immer noch die sichersten Kommunikationslösungen sind , die wir haben.

Mich würde zudem interessieren, welche Gedanken ihr zur zukünftigen zu erwartenden Sicherheit von kommerziellen Serverzertifikaten vs. Let's Encrypt habt.

Oder wie schätzt ihr das so ein?

Hallo Dr. Tux,

du machst da ein sehr weites Feld auf. Schwer das in einem kurzen Text zusammen zu beantworten. Ich habe das mal in drei Teile geteilt:
a) PGP Keyserver
b) E-mail, XMPP und "sichere" Kommunikation über unsichere Medien
c) Zertifikate

Zu den PGP Keyservern: Die Idee basierte darauf, das man damit kein Schindluder treiben würde. Da hat man sich geirrt und diese Designlücke macht das PGP Key Server system faktisch unbenutzbar. Komisch, das Leuten die die Vertauenswürdigkeit eines Zertifikats in 4 Stufen ausdrücken solch einen Fehler machen und übersehen das Hinz und Kunz ein Fakezertifikat für Dr.Tux ablegen können und damit die Verschlüsselung zu Dr. Tux empfindlich stören, weil jemand der Dr. Tux verschlüsselt schreiben möchte sich des Fakezertifikats bediehnt im Glauben es komme von Dr. Tux.
Da fehlt also zu 100% die Beglaubigung des auf dem Server abgelegten Zertifikats. Hätte man vielleicht auch mit asymmetrischer Verschlüsselung lösen können, aber da hat man gepatzt.

E-Mail und XMPP
E-Mail ist ein Dinosaurier. Man muss sich überlegen, das die Grundlagen noch aus den 1980ern kommen und 7Bit ASCII die Basis des Transport war. Daran hat man dann über diverse Erweiterungen versucht das Protokoll immer wieder fit für neues zu machen. Wenn du mir heute eine E-mail schickst mit weniger als 1000 Zeichen, dann sind die e-mail Header länger als dir Körper selbst. Kann man sich überlegen, ob man das effizient findet. Bzgl. Sicherheit ist jeder Header einer potentiell zu viel, er könnte mehr preisgeben, als die Nachricht selbst. Auch mit PGP verschlüsselten Inhalten kann man aus der Metainformation bereits viel gewinnen - wann hat wer mit wem gesprochen. Wenn man das in Bezug zu anderen Informationen setzt reicht das oft schon den Inhalt zu erraten.

XMPP ist ähnlich. Hier hat es unschuldig mit einem XML basierten, strukturierten Nachrichtenaustausch begonnen. Das ist dann auch in diversen Erweiterungen ausgeartet, die alle optional sind. Somit kann man sich auf nix verlassen. Ende zu Ende Verschlüsselt krankt hier aber auch an dem gleichen Metadatenprobelm wie die e-mails auch.
Aber das Problem der Metadaten ist ein grundlegendes. Man müsste sowas wie onion routing a la TOR etablieren, um diesen Faktor auszuschalten. Also quasi ein e-mail oder XMPP Protokoll über TOR.
Aber selbst mit TOR ist es schon des Öffteren vorgekommen das der für TOR verwendete Browser Informationen an den Webserver am anderen Ende der Verbindung gegeben hat, die es dem Webserver ermöglicht den User zu identifizieren..
Also sowas wie Anonymität ist sehr schwer herzustellen.

Und nun zu den Zertifikaten. Welchen Zertifikatsanbieter man auch wählt, wichtig ist bei jedem das er seinen Root Schlüssel extrem gut gesichert hat. Daran hängt die komplette Kette des Vertrauens. Und um Vertrauen geht es hier. Der Browser bekommt das Zertifikat des Webservers präsentiert und prüft dieses gegen die Information des Zertifikatsanbieters. Der Browser vertraut der Website.
Ob der Anbieter dir nun Geld dafür abknöpft oder im Fall von Let's Encrypt sich anders finanziert ist da erst mal egal.
Welches der beiden Finanzierungsmodelle jetzt das vertrauenswürdigere ist muss sich zeigen. Es gab aber schon ein paar Vorfälle mit kommerziellen Anbietern. Aber wenn jemand die Finanzierung von Let's Encrypt torpediert oder den Dienst unterläuf kann auch das Modell problematisch sein.

Liebe Grüße,
Klaren

Danke.

Und dein (unverbindliches) Fazit?

Klar, Sicherheitslücken, Unterwanderung, etc. sind Probleme die quasi für alles gelten. Dass man seit Enigmail v2.0 den Betreff mit verschlüsseln kann, halte ich für einen echten Zugewinn.

So wie ich das einschätze, machen Matrix und Wire die elementaren Dinge richtig. Bei allen anderen Messengern habe ich aus verschiedenen Gründen Bedenken.

Und: Weißt du was darüber, ob LE Subdomains unterstützt? Dazu konnte ich nichts konkretes finden.

Hmm, mein persönliches Fazit:

Finger weg von PGP Key servern - lieber PGP Zertifikate auf anderen Wegen austauschen.
E-mail und XMPP - Hier habe ich keine Meinung. Dissidenten und Spione sollten vielleicht andere Wege suchen, für den Hausgebrauch sollte PGP über E-mail oder ende-zu-ende verschlüsseltes XMPP ausreichen.
Zu den Zertifikaten: Ich nutze Let's Encrypt - muss ich mehr sagen? Ich denke, das ein kommerzieller Anbieter nicht automatisch auch seine Rootschlüssel sicherer verwahrt. Aber, das ist nur eine relative, temporäre Aussage. Die Zeit muss zeigen, ob Let's Encrypt es wirklich besser macht. Der Erfolg von LE zeigt aber, das ein rein kommerzielles Handling eine Blockade für flächendeckende Verschlüsselung war.

Als Unternehmen ist es sicherlich eine gute Idee seine Zertifikate von einem kommerziellen Anbieter zu beschaffen, da man hier auch andere Servicelevel, Sicherheitsansprüche und Regressansprüche gegen den Anbieter hat.

Ich hab mich mal aufgeschault: Subdomains werden von LE unterstützt. Hängt von deinem Certbot ab, ob der das von der Kommandozeile kann. Schau dir mal die Option "--expand" an mit der du ein existierendes Zertifikat um weitere Domains erweitern kannst.
Bei uns hatte ich das noch mit 4 Einzelrequests gelöst, da es anfänglich nicht ging. Heute würde ich das anders machen.

Liebe Grüße,
Klaren

Thanx again. Dein Fazit teile ich.

Folgefrage: Da ich für meine unendlich zahlreichen Verlinkungen immer wieder händisch prüfe, ob Seiten mit oder ohne "www" auflösen (viele Server sind nämlich falsch konfiguriert), führt genau dies dann bei zertifikatabgesicherten Seiten zu hässlichen Fehlermeldungen. Liegt das alleine an der Serverconf, die von ohne auf mit "www" umleiten muss, oder spielt da das Zertifikat irgendeine Rolle, wo beide Versionen in irgendeiner Weise mit eingearbeitet sein müssen? Ganz bescheuert finde ich die Variante, dass Seiten zwar ohne "www" aufrufbar sind, der Mouseover bei Links dann aber mit "www" anzeigt. Solch einen Mumpitz will ich bei meinen Seiten natürlich vermeiden. Genau so wie die weitere Hässlichkeit, dass die Hauptseite per https, die Subdomains aber her http kommen (was aber wohl mit dem oben besprochenen Punkt zusammen hängt, wenn ich das richtig verstehe).

Also das ist tatsächlich eine Frage, was genau im Zertifikat beglaubigt wurde. Darin ist immer eine FQDN (Fully Qualified Domain Name) also einen DNS Namen.
Der kann auch Wildcarded sein, muss es aber nicht. Wenn er Wildcarded ist, bedeutet das, das allen Namen unterhalb des im Zertifikat genannten Domain auch durch dieses Zertifikat repräsentiert werden können.
Ein paar Beispiele:
Zertifikat: kaalug.de
Ist nur und genau für kaalug.de/ verwendbar, nix anderes. Also speziell auch nicht für kaalug.de

Zertifikat: www.kaalug.de
Ist nur und genau für www.kaalug.de/ verwendbar, für nix anderes - also speziell auch nicht für kaalug.de

Zertifikat: *.kaalug.de
Ist für alles ab und inklusive kaalug.de verwendbar. Also auch www.kaalug.de oder hinz.und.kunz.kaalug.de oder was.auch.immer.kaalug.de und somit auch www.kaalug.de

Wenn ich nun "verwendbar" schreibe, dann heißt das man kann, muss aber nicht das Zertifikat für die gültigen Bereiche verwenden.
Es obliegt also dem Admin mit der Webserverkonfiguration die Zertifikate auszuwählen. Und hier geht es dann schon Mal durcheinander. Der Admin ist oft nicht in Personalunion auch der, der die Seiten erstellt. Und damit kommt es zu Missverständnissen wie du sie beschreibst.
Also der Webseitenbauer lebt in der www Welt und meint da müsse immer ein "www" hinter dem https:// stehen.. oder umgekehrt, der Admin hat vielleicht dem Webserver fix auf "www" konfiguriert um das DNS sauber nach Diensten zu strukturieren und die Webseitendesigner meinen aus künstlerischer Freiheit oder Ästhetik das www einfach weglassen zu müssen...

Liebe Grüße,
Klaren