Geleitschutz: DANE verbessert sicheren Transport zwischen Mailservern
Seite 2: … Kontrolle ist besser
… Kontrolle ist besser
Wer konsequent sicherheitsgerichtet denkt, weist seinen Server an, die Kommunikation bei Unregelmäßigkeiten wie einem abgelaufenen Gültigkeitszeitraum, einem nicht zum Namen im Zertifikat passenden Hostnamen des Zielservers oder einer unterbrochenen Vertrauenskette zum CA-Root-Zertifikat abzubrechen.
Meist werden die Server aber so konfiguriert, dass sie derlei nach dem Motto „Wird schon gut gehen“ ignorieren und dennoch eine verschlüsselte Verbindung aufbauen. Nun kann der Sender aber nicht mehr sicherstellen, dass er wirklich mit dem richtigen Ziel spricht (Authentizität).
Zwar könnte ein Admin die öffentlichen Schlüssel von Gegenstellen manuell in die Konfiguration seines Servers eintragen. Aber dieses Vorgehen skaliert nicht: Selbst kleinere Firmen müssen mit Dutzenden bis Hunderten externer Server kommunizieren. Manuell eine dedizierte Vertrauensbeziehung zwischen Allen zu konfigurieren ist offensichtlich illusorisch.
Diese beiden Schwachstellen eliminiert DANE: Statt mehrerer CA-Stellen gibt es nur einen Ort, der ein gültiges Zertifikat benennen kann, nämlich das DNS der Empfängerdomain. Über die dort veröffentlichte Prüfsumme des Server-Zertifikats kann der sendende Server das Ziel zweifelsfrei identifizieren.
Sicherheitsunterdrückung
Die dritte TLS-Schwachstelle offenbart sich bei Man-in-the-Middle-Angriffen: Jeder Verbindungsaufbau startet unverschlüsselt. Über den unsicheren Kanal vereinbaren die Kommunikationspartner per STARTTLS-Befehl das Chiffrieren. Unterstützt einer der beiden Server kein TLS, so müssen die E-Mails zwischen ihnen unverschlüsselt fließen.
Schaltet sich ein Angreifer zwischen die Server, kann er schlicht den STARTTLS-Befehl herausfiltern und damit offenen Mailtransport erzwingen. Den Angriff, also das Filtern, erleichtert, dass Standarddienste immer dieselben Ports benutzen: 80 für HTTP, 443 für HTTPS, 143 für IMAP (Internet Message Access Protocol, Mailabfrage), 993 für IMAPS (verschlüsseltes IMAP).
Für verschlüsselte Mailweiterleitung per SMTP (Simple Mail Transport Protocol) ist dagegen kein separater Port festgelegt, SMTP und SMTP über TLS laufen in der Praxis beide über Port 25. Für verschlüsseltes SMTP war ursprünglich Port 465 vorgesehen. Doch das wurde nie zum Standard und wird daher selten benutzt.
