Um sein Geschäft mit X.509 Zertifikaten anzukurbeln, schreibt er eine Pressemeldung, die auch prompt von der Fuzo übernommen wird.
Es scheint um X.509 Zertifikate für SMTP/STARTTLS zu gehen, also die Verschlüsselung des Transportweges beim Mailversand.
Was ist da dran alles falsch?
- Hop-by-hop encryption kann nie end-to-end encryption wie PGP oder S/MIME ersetzen.
- Für reine Verschlüsselung, also gegen passives Abhören, brauch ich keine teuren Zertifikate, da reicht self-signed oder welche von cacert.org.
- Certification Authorities (CAs) brauch ich nur dann, wenn ich überprüfen will, ob ich mit dem richtigen Server spreche, und nicht mit einem man-in-the-middle attacker. Aktuell präsentieren mir aber jede Menge Mailserver im Internet Zertifikate, die self-signed sind, auf den falschen Namen lauten, abgelaufen sind, oder sonstwie nicht validieren. Im Gegensatz zu Zertifikatsproblemen bei Webbrowsern hat der MTA aber keine GUI, wo er den Sender fragen könnte, ob er trotzdem die Mail zustellen soll.
Schalte ich also in meinem MTA die Zertifikatsprüfung scharf, dann muss ich händisch Ausnahmelisten von Mailservern führen, die kein gültiges Zertifikat haben.
Das skaliert nicht, wie es auch die Dokumentation von postfix klar formuliert:
It is regrettably the case that TLS secure-channels (fully authenticated and immune to man-in-the-middle attacks) impose constraints on the sending and receiving sites that preclude ubiquitous deployment. One needs to manually configure this type of security for each destination domain, and in many cases implement non-default TLS policy table entries for additional domains hosted at a common secured destination. With Postfix 2.3, we make secure-channel configurations substantially easier to configure, but they will never be the norm. For the generic domain with which you have made no specific security arrangements, this security level is not a good fit.
Given that strong authentication is not generally possible, and that verifiable certificates cost time and money, many servers that implement TLS use self-signed certificates or private CAs. This further limits the applicability of verified TLS on the public Internet.
- ISPs, die Mailservice für viele Domains machen, können gar nicht korrekte TLS Zertifikate installieren, da alle Kundendomains im Zertifikat stehen müssten. Nochmal die postfix Dokumentation:
On the SMTP client, there are further complications. When delivering mail to a given domain, in contrast to HTTPS, one rarely uses the domain name directly as the target host of the SMTP session. More typically, one uses MX lookups – these are usually unauthenticated – to obtain the domain’s SMTP server hostname(s). When, as is current practice, the client verifies the insecurely obtained MX hostname, it is subject to a DNS man-in-the-middle attack.
If clients instead attempted to verify the recipient domain name, an SMTP server for multiple domains would need to list all its email domain names in its certificate, and generate a new certificate each time a new domain were added. At least some CAs set fairly low limits (20 for one prominent CA) on the number of names that server certificates can contain. This approach is not consistent with current practice and does not scale.
Wie auch immer.
Die von mir betreuten Mailserver unterstützen STARTTLS (mit self-signed certs) und da sehe ich durchaus viele erfolgreiche TLS connects, etwa mit diesel.bestpractical.com, metalab.at, mailman.sil.at, metternich.vibe.at, quizzebox.quintessenz.at, lists.sourceforge.net, …).
Erkennen kann man solche TLS Handshakes auch an den Received: Headern, die der empfangende Mailserver einfügt, etwa:
Exim:
Received: from [78.142.183.254] (helo=mail.ispa.at) by smtp-02.sil.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63)
Postfix:
Received: from liszt.debian.org (liszt.debian.org [82.195.75.100]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTP id A2CFA4CF0B
MUA / MTA
Ernsthaft Sinn macht STARTTLS immer dann, wenn sich ein Mailclient (MUA, etwa Thunderbird, Outlook, …) zum Mailversand an einen Mailserver wendet und sich dort per “AUTH” anmelden soll. Es gibt zwar dafür Challenge/Response-Verfahren, die das Passwort nicht im Klartext übermitteln, als deutlich einfacher und stabiler hat sich aber herausgestellt, zuerst per STARTTLS die Mithörer auszuschließen, und dann simples AUTH PLAIN zu verwenden.
Auch hier ist ein formal perfektes X.509 Zertifikat unnötig, da alle Clients sich auch ein selfsigned nach einmaligem nachfragen merken.