{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreic6xs2n6ix2brmijkgftx5ep3do7bulvxhncmxkslqhevbhpebpvi",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmj6xdbebaw2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiaursqccywa2iqjjwyx5f4b5a2o7ca4y7jxa7wwsrwospcjludqwe"
    },
    "mimeType": "image/png",
    "size": 1226150
  },
  "description": "Siehe auch: Post-Quantum TLS für Nginx — X25519MLKEM768 auf FreeBSD 15 konfigurieren\n\nNachdem ich im letzten Beitrag OpenSSH mit hybriden Post-Quantum-Algorithmen abgesichert habe, lag die Frage nahe: Was ist eigentlich mit E-Mail? Mein FreeBSD 15 liefert Postfix 3.10.6, Dovecot 2.3.21.1 und OpenSSL 3.5.4 – und genau diese Kombination bringt alles mit, was man für quantensichere Verschlüsselung im Mailverkehr braucht. Ohne zusätzliche Pakete, ohne Patches, ohne Gefrickel.\n\nWarum […]",
  "path": "/2026/02/12/post-quantum-tls-fuer-e-mail-postfix-und-dovecot-mit-x25519mlkem768-auf-freebsd-15/",
  "publishedAt": "2026-05-23T10:01:16.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "Dovecot",
    "Email",
    "Encryption",
    "FreeBSD",
    "PostQuantum",
    "Postfix",
    "Security",
    "TLS",
    "Post-Quantum TLS für Nginx — X25519MLKEM768 auf FreeBSD 15 konfigurieren",
    "OpenSSH mit hybriden Post-Quantum-Algorithmen abgesichert",
    "Store now, decrypt later",
    "ML-KEM",
    "FIPS 203",
    "Curve25519",
    "Postfix-Users Mailingliste",
    "fragen"
  ],
  "textContent": "Siehe auch: Post-Quantum TLS für Nginx — X25519MLKEM768 auf FreeBSD 15 konfigurieren\n\nNachdem ich im letzten Beitrag OpenSSH mit hybriden Post-Quantum-Algorithmen abgesichert habe, lag die Frage nahe: Was ist eigentlich mit E-Mail? Mein FreeBSD 15 liefert **Postfix 3.10.6** , **Dovecot 2.3.21.1** und **OpenSSL 3.5.4** – und genau diese Kombination bringt alles mit, was man für quantensichere Verschlüsselung im Mailverkehr braucht. Ohne zusätzliche Pakete, ohne Patches, ohne Gefrickel.\n\n## Warum überhaupt PQC für E-Mail?\n\nDas „Store now, decrypt later„-Szenario, das ich beim SSH-Beitrag angesprochen habe, trifft auf E-Mail mindestens genauso zu. E-Mails werden über SMTP zwischen Servern transportiert – und dieser Transport ist grundsätzlich abfangbar. Wer heute TLS-verschlüsselten Mailverkehr mitschneidet und archiviert, könnte diesen in einigen Jahren mit einem ausreichend leistungsfähigen Quantencomputer entschlüsseln. Zumindest theoretisch.\n\nHeißt das, morgen liest jemand eure Mails? Nein. Aber wenn ihr vertrauliche Kommunikation betreibt und die heute eingesetzte Kryptografie in zehn Jahren noch standhalten soll, ist jetzt der richtige Zeitpunkt zum Handeln. Zumal der Aufwand (wie ihr gleich seht) überschaubar ist.\n\n## Was steckt hinter X25519MLKEM768?\n\nKurz zur Einordnung: ML-KEM (ehemals CRYSTALS-Kyber) ist der vom NIST im August 2024 standardisierte Post-Quantum-Algorithmus für den Schlüsselaustausch (FIPS 203). **X25519MLKEM768** ist ein sogenannter Hybrid-Algorithmus – er kombiniert das klassische X25519 (Curve25519 ECDH) mit ML-KEM-768 zu einem gemeinsamen Schlüssel.\n\nDer Clou dabei: Selbst wenn ML-KEM irgendwann gebrochen werden sollte, bleibt die klassische X25519-Komponente intakt. Und umgekehrt. Man muss also nicht darauf vertrauen, dass der neue Algorithmus auch wirklich hält – man bekommt das Beste aus beiden Welten.\n\nWer Firefox nutzt, hat das übrigens vermutlich schon in Aktion gesehen: Seit Firefox 124 wird bei TLS 1.3 standardmäßig **X25519MLKEM768** für den Schlüsselaustausch verwendet. Schaut mal in die Verbindungsdetails einer HTTPS-Seite – die Chancen stehen gut, dass dort bereits ein hybrider PQC-Schlüsselaustausch stattfindet. Also, wenn der Server das anbietet, wie dieser hier *zwinker*.\n\n## Voraussetzungen prüfen\n\nBevor ihr konfiguriert, solltet ihr sicherstellen, dass euer OpenSSL ML-KEM überhaupt kann. Auf meinem FreeBSD 15:\n\n\n    $ openssl version\n    OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)\n\nUnd dann die entscheidende Frage – kennt OpenSSL die benötigten KEM-Algorithmen?\n\n\n    $ openssl list -kem-algorithms | grep -i mlkem\n      ML-KEM-512\n      ML-KEM-768\n      ML-KEM-1024\n      X25519MLKEM768\n      SecP256r1MLKEM768\n\nWenn **X25519MLKEM768** in der Liste auftaucht, seid ihr startklar. Das ist bei OpenSSL ab Version 3.5 der Fall – der ML-KEM-Support ist im Default-Provider enthalten, es wird kein zusätzlicher OQS-Provider und kein liboqs benötigt.\n\nNoch ein Check – sind die Algorithmen auch als TLS-Gruppen verfügbar?\n\n\n    $ openssl list -tls-groups | grep -i mlkem\n      X25519MLKEM768\n      SecP256r1MLKEM768\n      SecP384r1MLKEM1024\n\nPerfekt. Weiter geht’s.\n\n## Postfix konfigurieren\n\nPostfix steuert die verwendeten TLS-Gruppen für den Schlüsselaustausch über den Parameter **tls_eecdh_auto_curves**. Dieser gilt sowohl für eingehende (smtpd) als auch für ausgehende (smtp) Verbindungen.\n\nVorher:\n\n\n    tls_eecdh_auto_curves = X25519, prime256v1, secp384r1\n\nNachher:\n\n\n    tls_eecdh_auto_curves = X25519MLKEM768, X25519, prime256v1, secp384r1\n\nDas war’s. Eine Zeile. **X25519MLKEM768** wird als bevorzugte Gruppe an den Anfang gestellt, die klassischen Kurven bleiben als Fallback erhalten. Clients die kein ML-KEM beherrschen, verhandeln einfach X25519 oder prime256v1 – die Abwärtskompatibilität bleibt also vollständig gewahrt.\n\nDie Änderung setzt ihr entweder direkt in `/usr/local/etc/postfix/main.cf` oder über:\n\n\n    # postconf \"tls_eecdh_auto_curves = X25519MLKEM768, X25519, prime256v1, secp384r1\"\n    # postfix reload\n\n**Wichtig:** Dieser Parameter beeinflusst alle Postfix-Dienste – SMTP (Port 25), Submission (Port 587) und SMTPS (Port 465). Ihr müsst also nicht jeden Port einzeln konfigurieren.\n\n**Update 01.04.2026:** Die oben gezeigte globale Methode über main.cf hat einen Haken, den ich erst später auf der Postfix-Users Mailingliste realisiert habe. Die korrigierte Konfiguration mit getrennten Einstellungen für Inbound und Outbound findet ihr weiter unten im **Nachtrag**.\n\n## Dovecot konfigurieren\n\nDovecot verwendet den Parameter **ssl_curve_list** um die TLS-Gruppen für IMAP-Verbindungen festzulegen. Standardmäßig ist dieser leer, was bedeutet, dass OpenSSL seine eigenen Defaults verwendet. Das _kann_ funktionieren, muss aber nicht.\n\nIn `/usr/local/etc/dovecot/conf.d/10-ssl.conf`:\n\n\n    ssl_curve_list = X25519MLKEM768:X25519:prime256v1:secp384r1\n\nAchtung: Dovecot verwendet **Doppelpunkte** als Trennzeichen (OpenSSL-Syntax), Postfix verwendet **Kommas**. Nicht verwechseln. Ja, passiert mir oft.\n\nDanach:\n\n\n    # doveadm reload\n\n## Überprüfen\n\nJetzt wird’s spannend. Funktioniert es tatsächlich? Zum Testen verwende ich `openssl s_client` direkt auf dem Server; denn euer lokales Linux oder macOS hat möglicherweise noch kein OpenSSL 3.5 mit ML-KEM-Support. Mein Linux Mint 22.3 hat es leider noch nicht *schnief*\n\n###  **SMTP (Port 25, STARTTLS):**\n\n\n    $ openssl s_client -connect smtp.kernel-error.de:25 -starttls smtp \\\n        -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group'\n    Protocol version: TLSv1.3\n    Negotiated TLS1.3 group: X25519MLKEM768\n\n### **SMTPS (Port 465):**\n\n\n    $ openssl s_client -connect smtp.kernel-error.de:465 \\\n        -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group'\n    Protocol version: TLSv1.3\n    Negotiated TLS1.3 group: X25519MLKEM768\n\n### **Submission (Port 587, STARTTLS):**\n\n\n    $ openssl s_client -connect smtp.kernel-error.de:587 -starttls smtp \\\n        -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group'\n    Protocol version: TLSv1.3\n    Negotiated TLS1.3 group: X25519MLKEM768\n\n### **IMAPS (Port 993):**\n\n\n    $ openssl s_client -connect imap.kernel-error.de:993 \\\n        -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group'\n    Protocol version: TLSv1.3\n    Negotiated TLS1.3 group: X25519MLKEM768\n\nAlle vier Ports verhandeln **TLSv1.3 mit X25519MLKEM768**. Die hybride Post-Quantum-Verschlüsselung ist aktiv.\n\nWenn ihr testen wollt, was passiert wenn ein Client kein ML-KEM unterstützt:\n\n\n    $ openssl s_client -connect imap.kernel-error.de:465 \\\n        -groups X25519 -brief </dev/null 2>&1 | grep -E 'Protocol|group'\n    Protocol version: TLSv1.3\n    Negotiated TLS1.3 group: X25519\n\nFallback auf X25519 – funktioniert sauber.\n\n## Was das nicht leistet\n\nWie schon beim SSH-Beitrag muss ich auch hier einschränken: Wir sichern damit den **Schlüsselaustausch** ab, nicht die **Authentifizierung**. Die TLS-Zertifikate verwenden weiterhin klassische Algorithmen (RSA, ECDSA). Für Post-Quantum-Signaturen in Zertifikaten bräuchte man ML-DSA (ehemals CRYSTALS-Dilithium) – und obwohl OpenSSL 3.5 das theoretisch unterstützt, gibt es Stand heute keine öffentliche Zertifizierungsstelle, die ML-DSA-Zertifikate ausstellt. Das wird kommen, ist aber noch Zukunftsmusik. Hey, wie ECDSA bei S/MIME (oder ist das schon anders?).\n\nFür die Praxis bedeutet das: Ein Angreifer mit einem Quantencomputer könnte theoretisch die Serverauthentifizierung angreifen (ECDSA/RSA brechen), müsste das aber in Echtzeit tun – hier greift „store now, decrypt later“ nicht, weil eine gefälschte Authentifizierung nur im Moment der Verbindung nützt. Der Schlüsselaustausch hingegen – und damit die eigentliche Vertraulichkeit der transportierten E-Mails – ist durch X25519MLKEM768 auch gegen zukünftige Quantenangriffe geschützt.\n\n## Nachtrag (01.04.2026): Inbound und Outbound trennen\n\nIch muss die Postfix-Konfiguration oben korrigieren. Der Parameter **tls_eecdh_auto_curves** gilt für SMTP-Client _und_ SMTP-Server gleichzeitig. Steht X25519MLKEM768 an erster Stelle, wird der PQC Key-Share direkt im initialen ClientHello mitgeschickt. Das bläht den ClientHello von rund 400 auf über 1400 Bytes auf.\n\nKlingt erstmal harmlos. Ist es aber nicht. Manche Zielserver kommen mit dem übergroßen ClientHello nicht klar, der TLS-Handshake scheitert. Bei `smtp_tls_security_level = may` fällt Postfix dann stillschweigend auf Plaintext zurück. Dasselbe passiert bei `dane` ohne TLSA-Records, also bei der Mehrheit aller Domains da draußen. Eure Mails gehen raus, aber unverschlüsselt. Super.\n\nDas Problem ist, dass hier zwei unterschiedliche Policies in einem Parameter stecken. Inbound will man PQC bevorzugen, weil man selbst kontrolliert was der Server akzeptiert. Outbound will man Kompatibilität priorisieren, weil man nicht weiß was auf der anderen Seite steht. Die gehören nicht in einen globalen Parameter.\n\nDie Lösung: **tls_eecdh_auto_curves** nicht mehr global in main.cf setzen, sondern per master.cf pro Dienst überschreiben.\n\n**Server-Seite (Inbound)** – PQC bevorzugen, an allen smtpd-Listenern:\n\n\n    smtp      inet  n       -       n       -       -       smtpd\n      -o tls_eecdh_auto_curves=X25519MLKEM768,X25519,prime256v1,secp384r1\n\n    submission inet n       -       n       -       -       smtpd\n      -o tls_eecdh_auto_curves=X25519MLKEM768,X25519,prime256v1,secp384r1\n\n    smtps     inet  n       -       n       -       -       smtpd\n      -o tls_eecdh_auto_curves=X25519MLKEM768,X25519,prime256v1,secp384r1\n\n**Client-Seite (Outbound)** – kleiner ClientHello, PQC nur via HelloRetryRequest:\n\n\n    smtp      unix  -       -       n       -       -       smtp\n      -o tls_eecdh_auto_curves=X25519,X25519MLKEM768,prime256v1,secp384r1\n\nDer Trick: Outbound steht X25519 an erster Stelle. Der initiale ClientHello bleibt damit klein. X25519MLKEM768 steht trotzdem in den supported_groups und wird verhandelt, wenn der Zielserver per HelloRetryRequest nachzieht. Inbound bekommen moderne Clients dagegen sofort PQC.\n\nDovecot ist davon nicht betroffen. Da gibt es nur die Server-Seite, `ssl_curve_list` bleibt wie oben beschrieben.\n\nNoch ein Wort zum Postfix-Default: `postconf -d` zeigt auf meinem 3.10.6 kein X25519MLKEM768 im Default. Die postconf(5)-Doku beschreibt zwar für neuere Builds ein Delayed-Key-Share-Verhalten, aber was die Doku beschreibt und was ein konkreter Build tut, können zwei verschiedene Dinge sein. Deshalb die explizite Trennung per master.cf. Danke an die Postfix-Users Mailingliste für die Diskussion, die mich auf dieses Problem aufmerksam gemacht hat und selbstverständlich an den Kommentierenden!\n\nZwei Zeilen Konfiguration, ein Reload pro Dienst – und euer Mailserver verhandelt quantensichere Verschlüsselung. Okay, es sind jetzt ein paar mehr Zeilen als ursprünglich versprochen. Aber die Trennung zwischen Inbound und Outbound ist es wert, denn blind auf Kompatibilität aller Zielserver zu hoffen ist keine Strategie.\n\nViel Spaß beim Nachbauen – und wie immer: bei Fragen, fragen.",
  "title": "Post-Quantum TLS für E-Mail — Postfix und Dovecot mit X25519MLKEM768 auf FreeBSD 15"
}