-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Schlagwort: Post-Quantum

Post-Quantum TLS für Nginx — X25519MLKEM768 auf FreeBSD 15 konfigurieren

7. März 2026 / / 6 Kommentare

Nachdem ich zuerst OpenSSH und dann Postfix und Dovecot mit Post-Quantum-Kryptografie ausgestattet habe, kamen einige Rückfragen: Wie sieht das eigentlich für Nginx aus? Kann man das auf dem Webserver genauso einfach aktivieren? Kurze Antwort: Ja. Noch kürzer sogar als bei E-Mail.

Nginx TLS-Konfiguration mit Post-Quantum-Key-Exchange X25519MLKEM768 für HTTPS.

Spannend finde ich dabei, dass ausgerechnet der Webserver die meisten Nachfragen erzeugt hat. SSH und E-Mail laufen hier längst mit X25519MLKEM768, aber die Leser wollten vor allem wissen, wie das für HTTPS geht. Vermutlich weil jeder eine Webseite hat, aber nicht jeder seinen eigenen Mailserver betreibt?! Es kommt ja immer darauf an, was man macht und welche Daten man übermittelt. Aber SSH oder E-Mail würde mich selbst nervöser machen als normales surfen. Wobei…. Ich melde mich ja auch an, hm. OK, immer MFA. Na, eine normale E-Mail ist ja schon immer eine Postkarte, wenn man keine zusätzliche Verschlüsselung nutzt (was kaum jemand macht).

Worum geht es?

Wer die Vorgeschichte noch nicht kennt: X25519MLKEM768 ist ein hybrider Schlüsselaustausch, der klassisches X25519 (Curve25519 ECDH) mit dem Post-Quantum-Algorithmus ML-KEM-768 kombiniert. Standardisiert vom NIST als FIPS 203. Der Vorteil des hybriden Ansatzes: Selbst wenn sich ML-KEM irgendwann als unsicher herausstellt, bleibt X25519 als Absicherung. Und andersherum genauso.

Das „Store now, decrypt later“ Szenario kennt ihr vielleicht schon aus den anderen Beiträgen. Jemand schneidet heute euren TLS-verschlüsselten Datenverkehr mit und entschlüsselt ihn in ein paar Jahren mit einem Quantencomputer. Bei HTTPS betrifft das alles, was über die Leitung geht: Formulardaten, Login-Credentials, API-Aufrufe, Session-Cookies. Ob das in der Praxis relevant ist? Kommt auf euer Bedrohungsmodell an. Aber der Aufwand für die Absicherung ist so gering, dass es keinen Grund gibt, es nicht zu tun.

Es hängt an OpenSSL, nicht an Nginx

Das ist eigentlich die zentrale Erkenntnis aus allen drei Beiträgen: Ob PQC funktioniert oder nicht, entscheidet fast ausschließlich die OpenSSL-Version. Nginx, Postfix, Dovecot, OpenSSH, sie alle delegieren den Schlüsselaustausch an OpenSSL (oder LibreSSL, BoringSSL, je nach System). Die Anwendung selbst muss lediglich die gewünschte Gruppe konfigurieren können. Und das können alle genannten Programme seit Jahren.

Konkret braucht ihr OpenSSL 3.5 oder neuer. Erst ab dieser Version ist ML-KEM nativ im Default-Provider enthalten, ohne externen OQS-Provider, ohne liboqs, ohne selbst kompilieren. FreeBSD 15 liefert das von Haus aus. Bei den meisten Linux-Distributionen sieht es Stand heute leider noch anders aus. Ubuntu 24.04 hat OpenSSL 3.0, Debian 12 hat 3.0, RHEL 9 hat 3.0. Für ein aktuelles OpenSSL müsst ihr dort entweder selbst bauen oder auf neuere Releases warten.

Voraussetzungen prüfen

Auf meinem FreeBSD 15:

$ openssl version
OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)

Nginx muss natürlich gegen dieses OpenSSL gelinkt sein. Das prüft ihr so:

$ nginx -V 2>&1 | grep -oE 'OpenSSL [0-9]+\.[0-9]+\.[0-9]+'
OpenSSL 3.5.4

Und dann die entscheidende Frage: Kennt OpenSSL die Gruppe X25519MLKEM768?

$ openssl list -tls-groups | grep -i mlkem
  X25519MLKEM768
  SecP256r1MLKEM768
  SecP384r1MLKEM1024

Wenn X25519MLKEM768 in der Liste auftaucht, kann es losgehen.

Nginx konfigurieren

In Nginx heißt die relevante Direktive ssl_ecdh_curve. Der Name ist etwas irreführend, denn sie steuert nicht nur ECDH-Kurven, sondern alle Key-Exchange-Gruppen die OpenSSL kennt. Also auch hybride PQC-Gruppen.

Meine Konfiguration in der TLS-Defaults-Datei, die per include in alle vHosts eingebunden wird:

ssl_ecdh_curve  X25519MLKEM768:X25519:secp384r1:prime256v1;

Das war’s. Eine Zeile. X25519MLKEM768 steht als bevorzugte Gruppe ganz vorne. Dahinter folgen die klassischen Kurven als Fallback für Clients, die noch kein ML-KEM sprechen. Die Reihenfolge ist die Präferenz.

Wer die Direktive lieber pro vHost setzen möchte, statt global, kann das natürlich auch tun. Ich bevorzuge eine zentrale TLS-Datei, weil ich sonst bei jedem TLS-Update zwanzig Configs anfassen müsste.

Zusätzlich habe ich die TLS 1.3 Cipher Suites explizit gesetzt:

ssl_conf_command  Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256;
ssl_conf_command  Options PrioritizeChaCha;

ChaCha20 als erste Wahl, weil es auf Clients ohne AES-NI (ältere Smartphones, ARM-Geräte) deutlich schneller ist. Auf Servern mit AES-NI ist der Unterschied minimal. PrioritizeChaCha sorgt dafür, dass der Server ChaCha20 bevorzugt, wenn der Client es an erster Stelle anbietet.

Die komplette TLS-Konfiguration sieht bei mir so aus:

# Protokolle
ssl_protocols              TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers  on;

# Key-Exchange-Gruppen (Reihenfolge = Präferenz)
ssl_ecdh_curve             X25519MLKEM768:X25519:secp384r1:prime256v1;

# TLS 1.3 Cipher Suites
ssl_conf_command           Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256;
ssl_conf_command           Options PrioritizeChaCha;

# TLS 1.2 Cipher Suites (nur ECDSA, kein RSA)
ssl_ciphers                ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256;

# Session Handling
ssl_session_cache          shared:SSL:50m;
ssl_session_timeout        1d;
ssl_session_tickets        off;

# OCSP Stapling
ssl_stapling               on;
ssl_stapling_verify        on;

# HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Danach die Konfiguration testen und Nginx neu laden:

# nginx -t
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
# service nginx reload

Überprüfen

Funktioniert es? Mit openssl s_client lässt sich das schnell prüfen:

$ openssl s_client -connect www.kernel-error.de:443 \
    -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group|Cipher'
Protocol version: TLSv1.3
Ciphersuite: TLS_CHACHA20_POLY1305_SHA256
Negotiated TLS1.3 group: X25519MLKEM768

TLSv1.3 mit X25519MLKEM768. Läuft. Der hybride Post-Quantum-Schlüsselaustausch ist aktiv.

Und was passiert, wenn ein Client kein ML-KEM kann?

$ openssl s_client -connect www.kernel-error.de:443 \
    -groups X25519 -brief </dev/null 2>&1 | grep -E 'Protocol|group|Cipher'
Protocol version: TLSv1.3
Ciphersuite: TLS_CHACHA20_POLY1305_SHA256

Sauberer Fallback auf X25519. Kein Fehler, keine Unterbrechung. Der Client bekommt einfach die stärkste Gruppe, die beide Seiten gemeinsam haben.

Browser-Support

Das Schöne bei HTTPS im Vergleich zu E-Mail oder SSH: Die Browser haben Post-Quantum-Kryptografie teilweise schon vor den Servern implementiert. Chrome verwendet seit Version 124 (April 2024) X25519MLKEM768 als bevorzugte Gruppe. Firefox seit Version 124 ebenfalls. Safari seit macOS 15 Sequoia und iOS 18. Edge zieht mit Chrome mit.

Wenn ihr also Nginx mit X25519MLKEM768 konfiguriert, profitieren die meisten eurer Besucher sofort davon. Ohne dass sie irgendetwas tun müssen. Das ist bei SSH und E-Mail anders, da sind die Clients noch nicht so weit. Womit sich auch erklärt, warum das Thema bei Webservern mehr Aufmerksamkeit bekommt.

HTTP/3 und QUIC

Wer wie ich HTTP/3 (QUIC) aktiviert hat, bekommt PQC dort automatisch mit. QUIC verwendet TLS 1.3 als Transportverschlüsselung und nutzt dieselbe ssl_ecdh_curve Konfiguration. Kein zusätzlicher Konfigurationsaufwand.

listen [::]:443 quic reuseport;
listen 443 quic reuseport;

Wer QUIC noch nicht nutzt: Der Overhead ist minimal, der Vorteil bei mobilen Verbindungen deutlich spürbar. Mehr dazu in meinem HTTP/3 Beitrag.

Davon abgesehen, wie ist das eigentlich mit Microsoft? Cloudflare macht ja schon knapp zu 66% PQC im HTTP Traffic. Es ist 2026, fragen wir doch mal eine AI: claude „Sag mal, wie ist das eigentlich bei Microsoft Produkten, wie Exchange oder IIS im Bezug auf PQC? Wird das schon unterstützt oder kommt das bald?“

● Gute Frage — Microsoft ist da tatsächlich in einer interessanten Position:                                                                                                                                                                                                                                                  
                 
  Windows / Schannel (TLS-Stack)                                                                                                                                                                                                                                                                                              
                  
  - Windows 11 24H2 / Windows Server 2025 haben experimentelle Unterstützung für ML-KEM (X25519MLKEM768) in TLS 1.3 bekommen — allerdings zunächst nur als Preview/Feature-Flag, nicht standardmäßig aktiv.                                                                                                                   
  - Der zugrunde liegende TLS-Stack (Schannel) muss das können, damit IIS und Exchange davon profitieren.                                                                                                                                                                                                                     

  IIS

  - IIS nutzt Schannel direkt. Sobald Schannel auf dem jeweiligen Windows Server PQC-Key-Exchange unterstützt und es aktiviert ist, kann IIS das theoretisch sofort.
  - Stand meines Wissens (Mai 2025): Noch kein produktiver PQC-Support in IIS. Die Preview in Windows Server 2025 ist eher für Tests gedacht.

  Exchange

  - Exchange Online (Microsoft 365): Microsoft hat angekündigt, PQC schrittweise in ihre Cloud-Dienste zu integrieren. Für TLS-Verbindungen zwischen Microsoft-Datacentern wurde bereits mit PQC experimentiert.
  - Exchange On-Premises: Hängt komplett am darunterliegenden Windows Server / Schannel. Solange Schannel kein produktives PQC kann, kann Exchange es auch nicht.

  Microsofts Roadmap

  - Microsoft hat ein "Quantum-Safe Program" und arbeitet aktiv an PQC-Integration in Windows, Azure und M365.
  - Die Priorität liegt auf TLS 1.3 mit ML-KEM (hybrid, also X25519MLKEM768.
  - Einen festen Zeitplan für "PQC by default" in Exchange/IIS gibt es meines Wissens noch nicht.

  Fazit

  Microsoft ist hintendran verglichen mit dem Open-Source-Stack. OpenSSL 3.5+ / LibreSSL / BoringSSL haben PQC-Support bereits produktionsreif. Bei Microsoft wartet man darauf, dass Schannel das nativ und stabil liefert — und bis das
  in Exchange On-Prem ankommt, dauert es erfahrungsgemäß nochmal länger.

  Für Exchange Online dürfte Microsoft das irgendwann einfach serverseitig einschalten, ohne dass Admins etwas tun müssen. Für On-Prem heißt es: warten auf den nächsten Windows Server Release, der PQC in Schannel GA (General Availability) hat.

  Caveat: Mein Wissensstand ist Mai 2025 — es kann sein, dass Microsoft seitdem konkretere Termine genannt hat. Wäre ggf. einen Blick in den Microsoft Security Blog wert.

Klingt gut. Ich muss ja zugeben, dass ich, seit ich nicht mehr mit Martin Peuker bei Items arbeite, irgendwie komplett von der Microsoft-Welt abgekoppelt bin. Oh, ist das jetzt korrekt von der AI? Keine Ahnung, „klingt“ richtig.

Was das nicht leistet

Den Absatz kennt ihr inzwischen aus den anderen Beiträgen, aber er gehört dazu: Wir sichern hier den Schlüsselaustausch ab, nicht die Authentifizierung. Die TLS-Zertifikate nutzen weiterhin klassische Algorithmen (in meinem Fall ECDSA P-384). Für Post-Quantum-Signaturen bräuchte man ML-DSA (ehemals CRYSTALS-Dilithium) in den Zertifikaten, aber keine öffentliche CA stellt solche Zertifikate aus. Das wird kommen, aber noch nicht heute.

In der Praxis heißt das: Ein Angreifer mit Quantencomputer könnte die Serverauthentifizierung angreifen, müsste das aber in Echtzeit tun. „Store now, decrypt later“ greift dort nicht. Der Schlüsselaustausch und damit die Vertraulichkeit eurer Daten ist durch X25519MLKEM768 geschützt. Auch in Zukunft.

Fazit

Eine Zeile in der Nginx-Konfiguration, ein Reload, fertig. Euer Webserver verhandelt danach mit jedem modernen Browser einen quantensicheren Schlüsselaustausch. Vollständig abwärtskompatibel für ältere Clients. Kein Risiko, kein Aufwand, kein Nachteil.

Die eigentliche Hürde ist nicht Nginx, sondern die OpenSSL-Version auf eurem System. Wer FreeBSD 15 oder ein System mit OpenSSL 3.5+ hat, kann sofort loslegen. Alle anderen müssen auf ihre Distribution warten oder selbst bauen.

Damit habe ich jetzt SSH, E-Mail und Webserver mit Post-Quantum-Kryptografie abgedeckt. Fehlt eigentlich nur noch DNS. Aber DoH und DoT laufen ja auch über TLS … *grübel*

Wie immer: Bei Fragen, fragen.

Post-Quantum TLS für E-Mail — Postfix und Dovecot mit X25519MLKEM768 auf FreeBSD 15

12. Februar 2026 / / 6 Kommentare
Visualisierung hybrider Post-Quantum-TLS-Verschlüsselung für E-Mail mit X25519MLKEM768 (ML-KEM-768 + X25519) auf Postfix und Dovecot unter FreeBSD 15

Nachdem 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.

Warum überhaupt PQC für E-Mail?

Das „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.

Heiß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.

Was steckt hinter X25519MLKEM768?

Kurz 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.

Der 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.

Wer 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*.

Voraussetzungen prüfen

Bevor ihr konfiguriert, solltet ihr sicherstellen, dass euer OpenSSL ML-KEM überhaupt kann. Auf meinem FreeBSD 15:

$ openssl version
OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)

Und dann die entscheidende Frage – kennt OpenSSL die benötigten KEM-Algorithmen?

$ openssl list -kem-algorithms | grep -i mlkem
  ML-KEM-512
  ML-KEM-768
  ML-KEM-1024
  X25519MLKEM768
  SecP256r1MLKEM768

Wenn 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.

Noch ein Check – sind die Algorithmen auch als TLS-Gruppen verfügbar?

$ openssl list -tls-groups | grep -i mlkem
  X25519MLKEM768
  SecP256r1MLKEM768
  SecP384r1MLKEM1024

Perfekt. Weiter geht’s.

Postfix konfigurieren

Postfix 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.

Vorher:

tls_eecdh_auto_curves = X25519, prime256v1, secp384r1

Nachher:

tls_eecdh_auto_curves = X25519MLKEM768, X25519, prime256v1, secp384r1

Das 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.

Die Änderung setzt ihr entweder direkt in /usr/local/etc/postfix/main.cf oder über:

# postconf "tls_eecdh_auto_curves = X25519MLKEM768, X25519, prime256v1, secp384r1"
# postfix reload

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.

Dovecot konfigurieren

Dovecot 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.

In /usr/local/etc/dovecot/conf.d/10-ssl.conf:

ssl_curve_list = X25519MLKEM768:X25519:prime256v1:secp384r1

Achtung: Dovecot verwendet Doppelpunkte als Trennzeichen (OpenSSL-Syntax), Postfix verwendet Kommas. Nicht verwechseln. Ja, passiert mir oft.

Danach:

# doveadm reload

Überprüfen

Jetzt 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*

SMTP (Port 25, STARTTLS):

$ openssl s_client -connect smtp.kernel-error.de:25 -starttls smtp \
    -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

SMTPS (Port 465):

$ openssl s_client -connect smtp.kernel-error.de:465 \
    -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

Submission (Port 587, STARTTLS):

$ openssl s_client -connect smtp.kernel-error.de:587 -starttls smtp \
    -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

IMAPS (Port 993):

$ openssl s_client -connect imap.kernel-error.de:993 \
    -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

Alle vier Ports verhandeln TLSv1.3 mit X25519MLKEM768. Die hybride Post-Quantum-Verschlüsselung ist aktiv.

Wenn ihr testen wollt, was passiert wenn ein Client kein ML-KEM unterstützt:

$ openssl s_client -connect imap.kernel-error.de:465 \
    -groups X25519 -brief </dev/null 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519

Fallback auf X25519 – funktioniert sauber.

Was das nicht leistet

Wie 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?).

Fü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.

Zwei Zeilen Konfiguration, ein Reload pro Dienst – und euer Mailserver verhandelt quantensichere Verschlüsselung. Vollständig abwärtskompatibel, ohne Einschränkungen für bestehende Clients. Es gibt eigentlich keinen Grund, das nicht zu tun. Oder fällt euch etwas ein?

Viel Spaß beim Nachbauen – und wie immer: bei Fragen, fragen.

Perfect Forward Secrecy für Postfix und Dovecot konfigurieren

15. Februar 2014 / / Keine Kommentare

Perfect Forward Secrecy (PFS) sorgt dafür, dass jede TLS-Verbindung einen eigenen temporären Schlüssel verwendet. Selbst wenn jemand den privaten Schlüssel des Servers in die Hände bekommt, kann er damit früher aufgezeichnete Verbindungen nicht entschlüsseln. Für E-Mail ist das besonders relevant, weil Mailverkehr gern auf Vorrat mitgeschnitten wird.

PFS bekommt man durch ECDHE- oder DHE-Schlüsselaustausch. Moderne OpenSSL-Versionen und aktuelle Postfix/Dovecot-Releases machen das Richtige von Haus aus. Trotzdem lohnt sich ein Blick auf die Konfiguration, um sicherzustellen, dass keine veralteten Protokolle oder Cipher-Suiten aktiv sind.

Postfix

Die relevanten Einstellungen in der main.cf:

# Eingehend (smtpd)
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_mandatory_ciphers = medium

# Ausgehend (smtp)
smtp_tls_security_level = dane
smtp_tls_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_mandatory_ciphers = medium

# Cipher-Präferenz beim Server
tls_preempt_cipherlist = yes

>=TLSv1.2 schaltet TLS 1.0 und 1.1 ab. tls_preempt_cipherlist = yes lässt den Server die Cipher-Reihenfolge bestimmen, nicht den Client. Postfix sortiert AEAD-Ciphers (GCM, CHACHA20) automatisch nach vorn, PFS-Ciphers haben Vorrang. Die medium-Stufe schließt alles unterhalb von 128-Bit-Verschlüsselung aus.

Für den ausgehenden Versand ist smtp_tls_security_level = dane die beste Wahl. Damit prüft Postfix TLSA-Records per DANE. Gibt es keinen TLSA-Record, fällt Postfix auf opportunistisches TLS zurück. Wer zusätzlich MTA-STS auswertet, deckt auch Server ohne DNSSEC ab.

Dovecot

In /usr/local/etc/dovecot/conf.d/10-ssl.conf (FreeBSD) bzw. /etc/dovecot/conf.d/10-ssl.conf (Linux):

ssl = required
ssl_min_protocol = TLSv1.2
ssl_prefer_server_ciphers = yes
ssl_options = no_ticket

ssl = required erzwingt TLS für alle Verbindungen. ssl_min_protocol = TLSv1.2 schließt alte Protokolle aus. ssl_prefer_server_ciphers = yes gibt dem Server die Kontrolle über die Cipher-Wahl. no_ticket deaktiviert TLS Session Tickets, die PFS untergraben können wenn der Ticket-Key kompromittiert wird.

Eine explizite Cipher-Liste ist bei aktuellem OpenSSL nicht nötig. Die Defaults bevorzugen ECDHE mit AEAD. Wer es trotzdem einschränken will:

ssl_cipher_list = ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20:!aNULL:!eNULL
ssl_cipher_suites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

ssl_cipher_list gilt für TLS 1.2, ssl_cipher_suites für TLS 1.3. Bei TLS 1.3 ist PFS immer aktiv, da gibt es keine Cipher-Suiten ohne Schlüsselaustausch mehr.

Testen

# Postfix (STARTTLS auf Port 25)
openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Postfix (Implicit TLS auf Port 465)
openssl s_client -connect smtp.kernel-error.de:465 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Dovecot (STARTTLS auf Port 143)
openssl s_client -starttls imap -connect imap.kernel-error.de:143 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Dovecot (Implicit TLS auf Port 993)
openssl s_client -connect imap.kernel-error.de:993 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

Entscheidend ist die Zeile Server Temp Key. Steht dort X25519, ECDH P-256 oder DH 2048, ist PFS aktiv. Mit OpenSSL 3.5+ und entsprechender Konfiguration sieht man dort auch X25519MLKEM768 für Post-Quantum-Schlüsselaustausch.

Siehe auch: Post-Quantum TLS für E-Mail

Fragen? Einfach melden.

Regelbuch

24. März 2012 / / Keine Kommentare

Regeln oder gute Vorsätze — Ausgabe 2026

Illustration eines IT-Regelbuchs 2026 mit Serverrack, Schloss-Symbolen, Backup-Medien, Laptop mit Malware-Warnung und Zero-Trust-Hinweis – Sinnbild für IT-Security-Grundregeln wie Backup, Verschlüsselung, Monitoring und Dokumentation.

Dieses Regelbuch habe ich 2012 zum ersten Mal aufgeschrieben. 14 Jahre später — nach etlichen Migrationen, Security-Incidents, Nachtschichten und dem einen oder anderen Moment in dem ich mir selbst dankbar war, dass ich damals diese Regeln aufgestellt hatte — ist es Zeit für eine Überarbeitung. Die Grundidee bleibt: Regeln aus der eigenen Praxis, kein Lehrbuch. Hinter jeder Regel steht mindestens eine Geschichte, die ich lieber nicht noch einmal erleben möchte.

Was sich geändert hat? Die Welt ist komplexer geworden. Cloud, Zero Trust, DSGVO, Supply-Chain-Angriffe, Post-Quantum-Kryptografie — das gab es 2012 so nicht oder es hat damals niemanden interessiert. Was geblieben ist? Backups sind immer noch wichtig, Dokumentation macht immer noch keinen Spaß und das tote Pferd lässt sich immer noch nicht reiten.

#01 — Nenne das Kind beim Namen!

Klare Kommunikation. Kein Weichspüler, kein Drumherum-Reden. Wenn ein System am Limit ist, dann sage ich das — und zwar so, dass es auch der Geschäftsführer versteht. Nicht um Panik zu machen, sondern damit alle die gleichen Informationen haben und bewusste Entscheidungen treffen können.

Ich habe zu oft erlebt, wie Probleme so lange schöngeredet wurden, bis niemand mehr wusste, worum es eigentlich geht. Dann passiert der Fehler und alle sind überrascht. Klare Ansage, kurze E-Mail an alle Beteiligten — fertig. Schlafen alle besser.

#02 — Nicht ohne Backup!

Diese Regel ist 14 Jahre alt und hat sich kein einziges Mal als falsch herausgestellt. Vor jeder kritischen Operation — Patch, Migration, Upgrade, Plattentausch — gibt es ein Backup. Keine Ausnahme.

Was sich geändert hat: 3-2-1-Regel ist Pflicht geworden. Drei Kopien, zwei verschiedene Medien, eine davon offsite. Und seit Ransomware zum Volkssport geworden ist, braucht mindestens eine Kopie einen Schutz gegen nachträgliche Veränderung — immutable Snapshots, Air-Gap, WORM-Storage. Wer sein Backup auf demselben System lagert wie die Produktivdaten, hat kein Backup. Der hat eine Kopie, die beim nächsten Verschlüsselungstrojaner mit draufgeht.

Die Ausnahme von 2012 gilt immer noch: Kein Backup? Dann Regel #01 — und die Entscheider unterschreiben, dass sie das Risiko tragen. Schriftlich.

#03 — Teste dein Backup!

Ein Backup das niemand getestet hat, ist eine Wette. Vielleicht klappt der Restore, vielleicht auch nicht. Und im Ernstfall willst du das nicht zum ersten Mal ausprobieren — um drei Uhr nachts, mit dem Chef im Nacken.

Also: Regelmäßig testen. Nicht nur prüfen ob der Job durchgelaufen ist, sondern tatsächlich Daten wiederherstellen. Dabei lernt man zwei Dinge — ob es funktioniert und wie lange es dauert. Beides will man vorher wissen, nicht nachher. Gehört übrigens in den DRP (Regel #15).

#04 — Wie wichtig ist das überhaupt?

Nicht jedes System ist gleich wichtig. Eine Firma kann Tage ohne die Bildergalerie im Intranet leben — aber vier Stunden ohne E-Mail oder Warenwirtschaft und es wird teuer. Das muss vorher geklärt und schriftlich festgehalten sein. Am besten mit konkreten Zahlen: Was kostet eine Stunde Ausfall? Was kostet die höhere Verfügbarkeit?

Wenn die Kosten neben der gewünschten Verfügbarkeit stehen, werden die Diskussionen plötzlich sachlich. Und wenn dann doch mal was ausfällt, gibt es keine Überraschungen — weil alle wussten, worauf sie sich eingelassen haben.

#05 — Datenschutz ist kein Feature!

2012 habe ich hier geschrieben, dass Admins entdeckte Datenschutzprobleme ansprechen sollten. Das gilt immer noch — aber die Lage hat sich massiv verändert. DSGVO, Schrems II, das ganze Programm. Datenschutz ist keine nette Empfehlung mehr, sondern Gesetz. Mit Bußgeldern, die wehtun.

Als Admin bist du oft der Einzige, der wirklich sieht, wo Daten hinfließen. Dieses Wissen verpflichtet. Wenn personenbezogene Daten in eine Cloud wandern, die unter US-Jurisdiktion fällt, oder wenn Mitarbeiterdaten unverschlüsselt über das Netz gehen — dann muss das auf den Tisch. Nicht weil man der Datenschutzbeauftragte ist, sondern weil man das als Vertrauensperson schuldig ist.

#06 — Klare Ansprechpartner!

Der Serverraum hat ein Problem — wen rufst du an? Und wenn der nicht erreichbar ist? Klingt banal, ist es nicht. Klare Zuständigkeiten mit Vertretungsregelung müssen vorher definiert sein. Ein guter Ansprechpartner hat technisches Grundverständnis und Entscheidungskompetenz. Das Schlimmste ist, wenn du um drei Uhr morgens jemanden erreichst, der zwar zuständig ist, aber nichts entscheiden darf.

#07 — Ein totes Pferd kann man nicht reiten.

Es gibt Systeme, die sind am Ende. End-of-Life Software, Hardware ohne Ersatzteile, Betriebssysteme ohne Security-Updates. Man kann noch so viel Geld und Zeit reinstecken — irgendwann hilft kein Workaround mehr. Dann muss man Nein sagen. Nicht aus Bequemlichkeit, sondern weil man für ein System, das nicht mehr zu verantworten ist, keine Verantwortung übernehmen kann.

2012 habe ich als Beispiel alte Windows-Server genannt und Debian-Systeme mit Archive-Quellen. 2026 stehen da noch ganz andere Dinge: PHP 7 im Internet, ungepatchte Log4j-Instanzen, TLS 1.0 auf dem Mailserver, CentOS 7 ohne Extended Support. Alles tote Pferde. Absteigen, neues Pferd suchen.

#08 — Workarounds dokumentieren!

Workarounds sind wie provisorische Brücken — sie helfen im Moment, aber wenn niemand sie aufschreibt, werden sie zum Dauerzustand. Und irgendwann weiß niemand mehr, warum dieser eine Cronjob jeden Dienstag um 04:17 Uhr den Apache neustartet.

Also: Jeden Workaround dokumentieren. Was ist das Problem? Was ist der Workaround? Warum keine echte Lösung? Und dann regelmäßig prüfen, ob sich die Lage geändert hat. Manchmal gibt es nach einem Update plötzlich eine richtige Lösung — aber nur wenn man noch weiß, dass da ein Workaround im Weg steht.

#09 — Es lebe die Dokumentation!

Jetzt mal unter Freunden — Dokumentation macht keinen Spaß. Hat es nie, wird es nie. Aber sie ist überlebenswichtig. Nicht für dich heute, sondern für dich in sechs Monaten, wenn du vergessen hast warum du diesen einen Parameter so gesetzt hast. Oder für den Kollegen, der deinen Dienst übernimmt während du im Urlaub bist.

Mein Ansatz: Ich dokumentiere so, dass mein zukünftiges Ich es versteht, wenn es müde und gestresst ist. Nicht mehr, nicht weniger. Und ja — dieser Blog ist ein Teil davon. Halb Dokumentation, halb Selbsttherapie.

#10 — Das richtige Werkzeug!

Wenn du mit dem falschen Schraubendreher lange genug an einer Schraube drehst, hast du am Ende eine runde Schraube und einen kaputten Schraubendreher. Gilt für Hardware, gilt für Software, gilt für Prozesse. Das richtige Werkzeug kostet manchmal Zeit zum Holen — spart aber ein Vielfaches an Reparaturzeit hinterher.

Heute heißt das auch: Nicht jedes Problem braucht eine Enterprise-Lösung. Manchmal ist ein Shell-Script besser als eine teure Plattform. Und manchmal ist die teure Plattform besser als drei zusammengestrickte Shell-Scripts. Den Unterschied zu erkennen ist die eigentliche Kunst.

#11 — Ist der Stecker drin?

Klingt dumm, ist es nicht. Systematisches Troubleshooting fängt bei den einfachsten Dingen an. Der Benutzer sagt, er habe alles probiert — trotzdem lohnt sich der eigene Blick. Zu oft war zwar der Stecker drin, aber der von der Kaffeemaschine.

Mein wichtigstes Troubleshooting-Prinzip: Nicht von der Mitte anfangen und raten, sondern systematisch von unten nach oben. Kabel, Link, IP, DNS, Dienst, Applikation. Und wenn man sich verrannt hat — zurück zum letzten Punkt, an dem noch alles funktioniert hat. Das klingt trivial, aber in der Hitze des Gefechts vergisst man es erstaunlich oft.

#12 — Jedem sein Login!

Personalisierte Accounts mit eigenen Zugangsdaten. 2012 wie heute, keine Diskussion. Nicht um jemandem etwas vorzuwerfen, sondern um nachvollziehen zu können was passiert ist und daraus zu lernen.

Was dazugekommen ist: MFA überall. Zweiter Faktor, keine Ausnahme. Am besten Hardware-Token oder Passkeys. SMS als zweiten Faktor akzeptiere ich nur noch unter Protest und mit Verweis auf Regel #01. Und geteilte Admin-Accounts? Tot. Jeder Admin bekommt seinen eigenen privilegierten Account — nachvollziehbar, sperrbar, auditierbar.

#13 — Verschlüssele alles!

Daten in Bewegung — verschlüsselt. Daten in Ruhe — verschlüsselt. Keine Ausnahme, kein „aber intern ist das ja sicher“. Intern ist gar nichts sicher, das hat uns jeder zweite Ransomware-Vorfall der letzten Jahre gezeigt.

TLS 1.3 als Minimum, Festplatten verschlüsselt, Backups verschlüsselt. Und wer heute noch Systeme ohne Transportverschlüsselung betreibt — SMTP ohne STARTTLS, HTTP ohne TLS, LDAP im Klartext — der muss sich fragen lassen, welches Jahr wir haben. Bonuspunkte für Post-Quantum-Kryptografie, denn Quantencomputer kommen schneller als man denkt.

#14 — Patch deine Systeme!

Ein ungepatchtes System ist eine offene Einladung. Das war 2012 schon so, aber heute ist die Zeit zwischen Veröffentlichung einer Schwachstelle und dem ersten Exploit auf Stunden geschrumpft. Nicht Tage, nicht Wochen — Stunden.

Patch-Management muss ein Prozess sein, kein Zufall. Regelmäßig, geplant, getestet. Und ja — Regel #02 kommt vorher. Erst Backup, dann Patch. Wenn ein Patch nicht eingespielt werden kann, weil die Software zu alt ist oder der Hersteller keinen mehr liefert — siehe Regel #07. Totes Pferd.

#15 — DRP!

Disaster Recovery Plan. Schon beim Erstellen werden einem Dinge bewusst, die man sonst übersieht. Systeme werden priorisiert (Regel #04), Verantwortliche benannt (Regel #06), Backups getestet (Regel #03). Ein DRP gibt nicht nur dem Admin Sicherheit — das ganze Unternehmen profitiert, weil es einen Plan für den Notfall gibt.

Neu seit 2012: Der DRP muss auch Cloud-Szenarien abdecken. Was passiert, wenn der Cloud-Provider ausfällt? Oder den Vertrag kündigt? Oder die Region nicht erreichbar ist? Und er muss getestet werden — nicht nur auf dem Papier, sondern als echte Übung. Einmal im Jahr den Ernstfall durchspielen. Das ist unbequem, aber es zeigt schonungslos, wo die Lücken sind.

#16 — Vertraue niemandem!

Zero Trust. Kein Gerät, kein Benutzer, kein Netzwerksegment ist automatisch vertrauenswürdig — auch nicht „das interne Netz“. Jeder Zugriff wird authentifiziert und autorisiert. Jedes Mal. Klingt paranoid, ist aber die einzige Architektur, die noch Sinn ergibt, wenn man akzeptiert, dass der Perimeter längst durchlöchert ist.

Das bedeutet nicht, dass man niemandem mehr trauen soll — aber das Vertrauen muss technisch durchgesetzt werden, nicht angenommen. Microsegmentierung, Least Privilege, kontinuierliche Verifikation. Und ja, das ist aufwendig. Aber weniger aufwendig als der nächste Incident, bei dem sich ein Angreifer lateral durch das „sichere“ interne Netz bewegt hat.

#17 — Was du nicht misst, existiert nicht.

Ein System ohne Monitoring ist wie Autofahren ohne Tacho und ohne Warnleuchten. Es läuft — bis es das nicht mehr tut, und dann weißt du nicht warum. Monitoring heißt nicht nur „ist der Server erreichbar“, sondern: Wie voll ist die Platte? Wie hoch ist die Load? Gibt es ungewöhnliche Login-Versuche? Läuft der Backup-Job durch?

Und dann brauchst du Alerting, das dich weckt, wenn etwas schiefgeht — nicht erst wenn der Benutzer anruft. Ein guter Alert ist einer, der dich aus dem Bett holt, bevor der Schaden eintritt. Ein schlechter Alert ist einer, der so oft kommt, dass du ihn ignorierst. Die Balance zu finden ist eine Kunst für sich.

Das waren 2012 dreizehn Regeln, jetzt sind es siebzehn geworden. Die Welt ist nicht einfacher geworden. Aber die Grundidee bleibt: Klartext reden, Backup machen, Dokumentation schreiben, tote Pferde rechtzeitig erkennen. Wer das beherzigt, schläft nachts besser.

Erste Fassung: März 2012 — Überarbeitet: März 2026

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑