Die Aktion in Ehren. Allerdings halte ich von DNSSEC wenig. DANE ansich wäre ja nicht schlecht, aber dadurch, dass es erst durch DNSSEC brauchbar wird sitzt es im gleichen Boot. DNSSec ist viel zu aufgeblasen, komplex und intransparent. DNSSEC verursacht eine Vertrauensebene auf niedererem Level zu erschaffen. Allerdings verlagert sich letztlich nur das Problem und beseitigt es nicht. Mit DANE & DNSSEC will man Wesentlichen nur die Spielregeln festlegen, also: "Welcher Server darf welches Zertifikat haben." Wäre eines der Hauptanwendungsgebiete. Damit spart man sich theoretisch das Beglaubigte Zertifikate auf dem HTTPS-Server, da ja der DNS-Server sagt: "Ja, das is gut, kannste nehmen!" oder "emails an @blablubb.com gehen nur über TLS raus, nixi unverschlüsselt!" Damit diktiert quasi der DNS-Server was Sache is. Das is solange cool, solange DNS-Einträge nicht von irgendwem manipuliert werden. Und an dem Punkt kommt DNSSEC ins Spiel. Alle DNS-Einträge sollen jeweils signiert sein, damit sie als vertrauenswürdig eingestuft werden. D.h. wieder das gleiche Spiel mit der Signiererei und dem vielgelobten Chain of Trust. Genau bei diesem fängt jedoch sprichwörtlich die Kacke zum Dampfen an.
Die traurige Tatsache ist, dass viele Anwendungen noch nichtmal Zertifikatsperrlisten überprüfen. Ergo ist -und bleibt- ein kompromittiertes Zertifikat bis zu seinem Verfallsdatum auf so manchem Server weiterhin gültig. Womit wir beim Thema Implementierung wären... Die beste Verschlüsselung nützt nix, wenn die Implementierung letztlich nicht korrekt ist oder durch Tolerierung von Fallback auf "unverschlüsselt" eliminiert wird.
Traurige Tatsache ist ebenfalls, dass SMTPS -wo wir gerade bei email sind- schon seit Ewigkeiten existiert. Es gibt Lesebestätigungen, Out of office replies, usw. Aber keinen Schalter für: "Diese email nicht im Klartext übertragen." Warum lauschen email-server nicht auch auf dem SMTPS-Port und warum steuern Browser nicht per default HTTPS an und geben eine Warnmeldung raus, wenn nur HTTP verfügbar ist? Ein selbstsigniertes Zertifikat führt zu 50 Sicherheitsmeldungen, aber einem Umleitung auf einen HTTP-Server zu keiner Einzigen. Finde den Fehler...
Verschlüsselung & Signierung is nach wie vor Opt-In...
Und damit es nicht heißt, ich mecker nur rum: Um Signierung und Verschlüsselung verwenden zu können
muss es
forciert werden (Beispiele):
- Browser per default auf HTTPS => HTTP entsprechend als nicht vertrauenswürdig brandmarken
- unsignierte emails as "unsigniert - nicht vertrausenwürdig" deklarieren
- Sperrlisten prüfen, wenn nicht möglich "Zertifikatstatus unbekannt - möglicherweise gesperrt" anzeigen
- usw
Dass das funktioniert hat Microsoft und Apple ganz gut gezeigt. Ohne Signatur auf deiner Anwendung gibt's eine orange Warnung bei der Ausführung des Programmes, bzw die App wird überhaupt nicht ausgeführt (Gatekeeper). Fazit:
Funktioniert.
Microsoft müsste nur bei Outlook definieren, dass unsignierte Mails als "nicht vertrauenswürdig" eingestuft werden. Ich wette, dann würden binnen weniger Monate zumindest im Unternehmensbereich nurnoch signierte Mails verschickt werden...
Ähnliches wenn die Browser HTTP-Verbindungen als solches deklassieren würden...
Ändert natürlich nix an der Problematik mit der Unsumme an "vertrausenwürdigen Stammzertifizierungsstellen". Allerdings liegt hier eine Abhilfe im Fingerprint Caching kombiniert mit persönlichen Begrüßungen oder dgl. (bei Loginseiten) sowie 2 Faktor-Authentifizierung. Für Server2Server-Kommunikation kann man so oder so nur hoffen, dass da verschlüsselt übertragen wird... In dem Fall schützt nur selbst verschlüsseln.
