IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Security (Seite 12 von 15)

VirtualBox CompareExchange128

Veraltet: Windows 8 und 8.1 sind seit Januar 2023 komplett ohne Support. Das hier beschriebene VirtualBox-Problem ist nur bei diesem spezifischen Upgrade-Pfad relevant.

Da versuche ich gerade mein Windows 8 auf Windows 8.1 in der VirtualBox zu heben, da springt mich unverhofft eine Meldung an. Ich könne Windows 8.1 nicht installieren da mein Prozessor CompareExchange128 nicht unterstützt.

CompareExchange 128? Das kommt mir im Zusammenhang mit C/C++ und dem Compiler irgendwie bekannt vor. Ich hatte da mal etwas mit einer Binary unter einem FreeBSD. Hing zusammen mit einer AMD64 CPU und noch irgendwas… Gott, warum kann ich mir so einen Mist nicht merken. Aber ich habe in meiner aktuellen Kiste eine Intel CPU. Wobei es wohl eher mit 64Bit als mit dem CPU Hersteller zu schaffen hat. Kann mich da bitte noch mal jemand schlau machen?

Öhm wie auch immer ich erinnere mich daran dass irgendeine recht kryptisch aussehender „Befehlssatz/Anweisung“ im Prozessor genutzt werden sollte. Das Programm auf dem FreeBSD war irgendwie sehr Hardwarenahe übersetzt worden……

Google brachte mich auf den richtigen Weg, nachdem ich es mit: FreeBSD Compareexchange 128 und AMD64 gefüttert hatte. Plöp: http://en.wikipedia.org/wiki/X86-64 und CMPXCHG16B instruction.

Meine CPU:

$ cat /proc/cpuinfo |grep "model name"|uniq
model name : Intel(R) Core(TM) i5-3450 CPU @ 3.10GHz

Kann diese instruction aber und ich wüsste jetzt nicht das mein Bios oder Hostkernel es abschaltet (warum auch?). AAABBBER vielleicht muss man es für VirtualBox einschalten?!? Ok also VBoxManage und öhm sicherlich VBoxInternal und ich würde es bei CPUM?/device? Vermuten… Ach noch mal Google fragen!

Google bringt mit den Worten: CMPXCHG16B und VirtualBox auch direkt ein passendes Ergebnis!

$ VBoxManage setextradata "Windows 8 " VBoxInternal/CPUM/CMPXCHG16B 1

Tja, was soll ich sagen? Geht. Gefühlt habe ich mich mit dem Thema schon wieder zu lange beschäftigt und vor allem zu oft Google fragen müssen (ich bin so schlecht). Also tippe ich mal CompareExchange128 CPU und Instruction hier hin. Dann erinnere ich mich sicher daran es mal hier hin geschrieben zu haben .o0(oder auch nicht).

Sicheres SSL / TLS Zertifikat

Es ist Zeit für ein neues Serverzertifikat. Im Standard sind dieses RSA Schlüssel mit einer Länge von 2048 Bit und SHA1 als Hash Algorithmus für Signaturen. Bei SHA1 bekommt man leider etwas Bauchschmerzen… 2048 Bit Keys sind nun ebenfalls nicht SO lang. Theoretisch noch „sicher“ aber wer will es schon darauf anlegen?

Nun wurde über Jahre an SSL / TLS Zertifikaten dieser Art festgehalten. Meist um kompatibel mit älteren Systemen zu sein. So können zum Beispiel die Betriebssysteme Windows XP sowie das darauf basierende Server Betriebssysteme von der Firma Microsoft, Windows Server 2003, nicht mit SHA2 umgehen.

Ich werde für die nächste Zertifikatsrunde auf 4096 Bit lange Schlüssel und SHA2 (SHA256) setzten. Selbst wenn ich damit einige Windows XP Benutzer abhängen werde!

Natürlich braucht man zusätzlich eine CA, welche mit X.509 Zertifikaten dieser Art umgehen kann. StartCOM / StartSSL kann dieses glücklicherweise. Ich erstelle die Zertifikate jeweils mit openSSL (Patch nicht vergessen!).

Key erstellen:

openssl req -new -outform PEM -out http.cert -sha256 -newkey rsa:4096 -nodes -keyout http.key -keyform PEM -days 730 -x509

Zertifizierungsanforderung (CSR) erstellen:

openssl req -new -key http.key -out http.csr -sha256

Die von er CA Unterzeichnete CSR einpflegen:

cat http.key http.crt > http.pem

Diffie Hellman Parameter erstellen und einfach mit ins pem werfen:

openssl gendh 4096 >> http.pem

Ja, es sind 4096bit für DH. dieses kann etwas dauern. Ist aber am Ende nötig damit zum Beispiel der Apache >=2.4 diese Bits auch nutzen kann!

Noch Fragen?

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

Warum keine Windows Server Sicherung?

Eine gute Frage, oder? Nun ja, man bekommt diese tolle Windows Server Image oder Image Server Sicherung ja kostenlos von Microsoft dazu. Mit ihr lassen sich auch tatsächlich komplette Server sichern. Dieses sogar zuverlässig.

Ich muss aber sicher nicht erwähnen, dass ich im Grunde keine Ahnung von Microsoft Systemen und vor allem der Windows Server Sicherung habe, oder? Egal, mal weiter! Ich wollte ja die Frage beantworten….

Die Windows Server Sicherung kann nicht mit Bandlaufwerken oder ähnlichem umgehen. Natürlich kann man auf einen Netzwerk Share -eine Freigabe- sichern. Da die Sicherung in diesem Fall leider keine Volume Shadow Copy vom Ziel erstellen kann, würde die laufende Sicherung also die bestehende Überschreiben. Bricht die Sicherung als „unvollständig“ ab, hat man nichts mehr.

Volume Shadow Copy…. Weist man der Windows Server Sicherung ein spezielles Backup Volume zu, gibt es der Windows Sicherung die Möglichkeit solche Schattenkopien vom Ziel anzulegen. Man verliert also bei einer unvollständigen Sicherung nicht unbedingt die alten Sicherungen.. Damit sind wir also bei einer im Rechner verbauten Platte, einer externen USB Platte (bis hier eine schlechte Idee) oder auch bei einer ISCSI Platte. Ersteinmal ok, oder? Jain, warum erkläre ich später! Erst noch etwas zu den Schattenkopien. Windows selbst hat natürlich die Möglichkeit einzelne Schattenkopie von seinen Dateien anzulegen. Diese werden sogar noch von der Serversicherung gesichert. So könnte man also nach dem Zurückspielen einer Vollsicherung sogar noch zu einem etwas älteren Stand zurückspringen. Denn noch muss zuerst die Vollsicherung zurückgespielt werden und dann geht es auf einen älteren Stand. Das ist im Falle einer Rücksicherung sehr langwierig. Funktioniert denn noch sehr gut…

Vollsicherung… Die Windows Server Sicherung kann nur Vollsicherungen erstellen, also keine inkrementell oder differentielle Datensicherung. Das bedeutet man muss jeden Tag die kompletten Daten zum Sicherungsziel „pumpen“. Nutzt man nun als Ziel ein intelligentes Storage System wie ein NetApp oder ein ZFS basiertes System (Nexenta, OpenIndiana, Solaris, FreeNas)… Vielleicht noch zusammen mit ISCSI…. dann bringen einem sehr viele der feinen Zusatzfunktionen des Storage Servers kaum noch etwas. Mal angenommen man möchte sein Storage System mit einem anderen abgleichen, dann wird ebenfalls wieder alles kopiert, da sich ja leider immer alles ändert. Dumme Sache das 🙁

Möchte man also seine Sicherung nicht im Unternehmen liegen haben (Feuer / Flugzeug / Wasser / ..) würde so jeden Tag die vollständige Sicherung bewegt werden müssen. Denkt man nun an ein paar TB wird schnell klar, das man sich schon extreme Anbindungen an seinen Standort mieten muss, nur um die Sicherung überhaupt in einem gewissen Zeitfenster aus dem Haus zu bekommen.

Hier kommen dann wieder die etwas teureren Sicherungsprogramme anderer Hersteller ins Spiel .-)

Um es also auf den Punkt zu bringen… Die Windows Server Sicherung funktioniert und hält was sie verspricht, ohne die Möglichkeit einer differentielle Sicherung wird sie denn noch von mir in fast allen Fällen eine Abfuhr bekommen.

Oh ja, sobald es die Möglichkeit einer differentiellen Datensicherung gibt, bitte melden!

Fragen? Einfach melden.

Der sichere GPG-Schlüssel

Absolut sicher ist nichts. Man kann nur versuchen, es Angreifern so aufwendig wie möglich zu machen. Bei GPG-Schlüsseln fängt das bei der Schlüssellänge und den Algorithmen an.

Schlüssellänge und Algorithmus

DSA-Schlüssel sind auf 512-1024 Bit begrenzt und anfällig bei schlechten Zufallsgeneratoren. ElGamal-Schlüssel können beliebig groß werden, teilen aber das Zufallsproblem. RSA mit 4096 Bit ist heute ein guter Kompromiss: rechenbar für aktuelle Hardware, nicht rechenbar für bekannte Angriffe. Quantencomputer könnten RSA in Zukunft gefährden, sind davon aber noch weit entfernt.

Unterstützte Verfahren anzeigen

gpg --version

Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

MD5 ist gebrochen, SHA1 gilt als unsicher. SHA-256 und SHA-512 sind die sinnvolle Wahl. Bei den symmetrischen Verfahren sind AES-256 und Twofish solide. 3DES bleibt als Fallback, weil GPG es als Pflichtverfahren mitführt.

Algorithmus-Präferenzen setzen

Man kann im eigenen Schlüssel festlegen, welche Algorithmen in welcher Reihenfolge bevorzugt werden. Die kurze Key-ID (0x0F9874D8) reicht dafür, auch wenn man für andere Zwecke besser die volle Fingerprint-ID nutzt.

gpg --edit-key 0x0F9874D8

Aktuelle Einstellungen anzeigen:

gpg> showpref
[ uneing.] (1). Sebastian van de Meer (E-Mail Address) kernel-error @ kernel-error.com;
Verschlü.: TWOFISH, AES256, AES192, 3DES
Digest: RIPEMD160, SHA512, SHA256, SHA1
Komprimierung: BZIP2, ZLIB, nicht komprimiert
Eigenschaften: MDC, Keyserver no-modify

Gewünschte Algorithmen setzen:

gpg> setpref TWOFISH AES256 AES192 RIPEMD160 SHA512 SHA256 BZIP2 ZLIB
gpg> q
Änderungen speichern? (j/N) j

Der Schlüssel arbeitet ab sofort nur noch mit den festgelegten Verfahren. Kommunikationspartner, deren GPG-Installation keines dieser Verfahren unterstützt, fallen automatisch auf 3DES zurück.

Welchen Verfahren man letztlich vertraut, muss jeder für sich entscheiden.


Update 2025: Gehärtete gpg.conf für GnuPG 2.4

Die Schlüssel-Präferenzen oben sind der erste Schritt. Der zweite ist die lokale gpg.conf. Sie bestimmt, welche Algorithmen GnuPG überhaupt anbietet, wie die Passphrase gehärtet wird und wo nach Schlüsseln gesucht wird. Meine aktuelle Konfiguration für GnuPG 2.4 unter Linux:

# ~/.gnupg/gpg.conf — Hardened Config für GnuPG 2.4

# Ausgabe: lange Key-IDs und Fingerprints anzeigen
keyid-format 0xlong
with-fingerprint
utf8-strings

# Schlüssel automatisch suchen: erst WKD, dann DANE, dann Keyserver
auto-key-retrieve
auto-key-locate wkd,dane,local,keyserver
keyserver hkps://keys.openpgp.org

# Starke Defaults
cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512

# KDF-Härtung: S2K mit 65 Mio. Iterationen
s2k-mode 3
s2k-digest-algo SHA512
s2k-cipher-algo AES256
s2k-count 65011712

# Legacy-Algorithmen komplett deaktivieren
disable-cipher-algo 3DES
disable-cipher-algo IDEA
disable-cipher-algo CAST5
disable-cipher-algo BLOWFISH
disable-cipher-algo TWOFISH

# Metadata minimieren
no-comments
no-emit-version
export-options export-minimal

# Trust-Modell: TOFU kombiniert mit Web of Trust
trust-model tofu+pgp

# Bevorzugte Algorithmen (lokal)
personal-cipher-preferences AES256 AES192 AES
personal-digest-preferences SHA512 SHA384 SHA256
weak-digest SHA1
force-ocb

# Default-Key (Ed25519)
default-key 0x5F279C362EEAB216

Was sich geändert hat

Ed25519 statt RSA. Mein aktueller Schlüssel ist ein Ed25519. Kürzere Schlüssel, schnellere Operationen, gleiche Sicherheit. RSA 4096 funktioniert weiterhin, aber für neue Schlüssel gibt es keinen Grund mehr dafür.

Legacy-Algorithmen deaktiviert. 3DES, IDEA, CAST5, Blowfish und Twofish sind per disable-cipher-algo komplett gesperrt. GnuPG bietet sie nicht mehr an und akzeptiert sie nicht. Das ist aggressiver als setpref, weil es auch eingehende Nachrichten betrifft. Wer damit Probleme bekommt, hat ein Gegenüber mit sehr veraltetem Setup.

S2K-Hardening. Die s2k-count Direktive bestimmt, wie oft die Passphrase bei symmetrischer Verschlüsselung gehasht wird. 65 Millionen Iterationen machen Brute-Force auf die Passphrase deutlich teurer. Der Wert ist der Maximalwert, den GnuPG akzeptiert.

OCB statt MDC. force-ocb erzwingt Authenticated Encryption (OCB) statt des älteren MDC (Modification Detection Code). OCB erkennt Manipulationen kryptographisch, nicht nur per Hash.

TOFU+PGP. trust-model tofu+pgp kombiniert das klassische Web of Trust mit Trust on First Use. Beim ersten Kontakt wird der Schlüssel akzeptiert, danach warnt GnuPG bei Änderungen. Pragmatischer als reines WoT, das in der Praxis kaum jemand pflegt.

WKD und DANE. auto-key-locate wkd,dane,local,keyserver sucht Schlüssel zuerst per Web Key Directory und DANE, bevor der Keyserver gefragt wird. WKD liefert den Schlüssel direkt von der Domain des Empfängers. keys.openpgp.org als Keyserver statt der alten SKS-Pools, weil dort E-Mail-Adressen nur nach Bestätigung veröffentlicht werden.

Metadata minimieren. no-comments, no-emit-version und export-minimal sorgen dafür, dass verschlüsselte Nachrichten und exportierte Schlüssel keine unnötigen Informationen enthalten. Kein Kommentarfeld, keine GnuPG-Versionsnummer, keine überflüssigen Signaturen beim Export.

Siehe auch: GPG: E-Mails signieren und verschlüsseln mit GnuPG, GPG-Schlüssel per PKA im DNS veröffentlichen, OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen

Fragen? Einfach melden.

DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern

Meine Domain ist per DNSSEC gesichert, der Webserver bietet TLS an. Mit DANE (DNS-based Authentication of Named Entities) lässt sich beides verbinden: Die Checksumme des TLS-Zertifikats wird als TLSA-Record im DNS veröffentlicht — DNSSEC schützt diesen Record vor Manipulation.

Warum DANE?

Das klassische CA-System hat ein grundsätzliches Problem: Jede der hunderten Certificate Authorities kann ein Zertifikat für jede Domain ausstellen. Wird eine CA kompromittiert oder handelt fahrlässig, können gefälschte Zertifikate im Umlauf sein — der Browser merkt nichts. DANE löst das, indem der Domaininhaber selbst festlegt, welches Zertifikat gültig ist. Der Hash steht im DNS, DNSSEC garantiert die Integrität. Keine CA kann das unterlaufen.

Unterstützt ein Client DANE, prüft er beim TLS-Handshake, ob der TLSA-Record zum angebotenen Zertifikat passt. Das funktioniert auch mit selbstsignierten Zertifikaten — solange der Hash stimmt und DNSSEC aktiv ist, wird dem Zertifikat vertraut. Die Spezifikation steht in RFC 6698.

TLSA-Record erstellen

Der TLSA-Record enthält einen Hash des Public Keys (SPKI) aus dem Zertifikat. Mit OpenSSL erzeugt:

openssl x509 -in server.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Den Hash trägt man als TLSA-Record in die DNS-Zone ein. Für den Webserver (Port 443):

_443._tcp.www.kernel-error.de. 3600 IN TLSA 3 1 1 a321...f7

Die drei Zahlen 3 1 1 bedeuten:

  • 3 — DANE-EE (End Entity): Das Zertifikat wird direkt geprüft, kein CA-Vertrauen nötig
  • 1 — SPKI (Subject Public Key Info): Nur der Public Key wird gehasht, nicht das ganze Zertifikat. Vorteil: Bei Erneuerung mit demselben Key bleibt der TLSA-Record gültig
  • 1 — SHA-256 als Hash-Algorithmus

Der TTL von 3600 Sekunden ist bewusst kurz gewählt — bei einem Zertifikatswechsel mit neuem Key soll der alte Record schnell ablaufen.

Prüfen

Mit dig lässt sich der TLSA-Record abfragen:

dig TLSA _443._tcp.www.kernel-error.de +short
3 1 1 a321...f7

Ob der Record auch zum tatsächlich ausgelieferten Zertifikat passt, prüft man mit OpenSSL — Hash vom Server-Zertifikat erzeugen und mit dem DNS-Record vergleichen:

echo | openssl s_client -connect www.kernel-error.de:443 2>/dev/null \
  | openssl x509 -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Stimmen die Hashes überein, ist alles korrekt. Komfortabler geht es mit posttls-finger (Teil von Postfix) — das Tool prüft TLSA-Record und Zertifikat in einem Schritt.

DANE für E-Mail

DANE funktioniert nicht nur für Webserver. Für E-Mail ist es sogar wichtiger — SMTP hat kein Vertrauensmodell wie Browser, opportunistisches TLS kann trivial per Downgrade-Angriff ausgehebelt werden. Mit DANE und TLSA-Records auf Port 25 wird die Verschlüsselung kryptographisch verifizierbar. Wie man das mit Postfix einrichtet, steht im Beitrag Postfix mit DANE und DNSSEC absichern. Zur Visualisierung des DANE-Anteils im Mailverkehr habe ich damals Mailgraph um DANE-Graphen erweitert.

Siehe auch: DNSSEC einrichten

Fragen? Einfach melden.

StartSSL Identiy Validation Class 2

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und eingestellt. Kostenlose Zertifikate gibt es bei Let’s Encrypt.

Na wunderbar, mein Class 2 x.509 S/MIME Zertifikat läuft in kürze aus. Die Class 2 Validation ist auch ausgelaufen, also muss ich wohl was tun, hm?


Schnell alles bei StartSSL angeschoben und auf den bekannten Anruf irgendwo aus Israel warten… Es klingelte auch aber aus 001 213-341. Die Landesvorwahl ist USA und mein Android meint der Rest wäre etwas aus Los Angeles, CA! Das hat mich etwas überrascht; whatever. Wie gewohnt war das Gespräch schnell erledigt. Wobei die Dame am anderen Ende der Leitung extrem schlecht zu verstehen war. Nun warte ich also auf die Bestätigung meiner Class 2 Zertifizierung.

 


 

*UPDATE*

Na wunderbar:

### Schnipp ###
To Sebastian Van De Meer,

This electronic mail message was created by StartCom’s Administration Personnel:

Congratulations! Your Class 2 Identity Validation has been confirmed and approved. You are eligible for certificates at Class 2 level until 2014-05-01.
Additionally you have been awarded with StartSSL™ Web-of-Trust Notary status due to your fulfilling of all requirements. Well done!

Best Regards
### Schnapp ###

Dann kann ich ja gleich mal von diesem Zertifikat:

Seriennummer: 13:27
SHA1-Fingerprint: 28:AE:4C:96:51:75:EB:18:03:F9:9E:E3:7A:ED:C7:EA:13:8B:44:99

Zu diesem Zertifikat wechseln:

Seriennummer: 33:97
SHA1-Fingerprint: 7F:8B:92:19:FF:07:BF:EB:8E:E0:18:D4:98:B8:48:DF:E3:0E:4A:85

 

 

Unix / Linux Openssl Zertifikat pem konvertieren zu Microsoft Windows pfx

Man man man… Da bittet ein Kollege um ein Zertifikat, ich schraube das schnell zusammen und schiebe es im als .PEM – Base64-kodiertes Zertifikat, umschlossen von „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ zu.

Nun versucht dieser das Zertifikat auf seinem Windows Server zu importieren. Klappt aber so einfach nicht. Microsoft hätte nämlich gerne das Zertifikat als .PFX (.P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten.) Macht ja auch Sinn wenn es eh in einer Zertifikatsverwaltung liegt und dass ganze Kennwortgeschützt ist. So ist es etwas sicherer, wenn die Datei mal jemanden in die Hände fällt, der es nicht haben soll!

Wie also nun aus PEM ein PFX machen? Openssl hilft:

# openssl pkcs12 -export -out telefon.de.pfx -inkey telefon.de.key -in telefon.de.crt -certfile CACert.crt

telefon.de.key sowie telefon.de.crt sollten wir beim einfachen erstellen des Zertifikates per Openssl ja bereits haben. CACert.crt ist einfach der Zertifikat der CA, mit welchem unsere CSR unterschrieben wurde. Noch Fragen?

Siehe auch: Elliptic Curve Zertifikate mit OpenSSL

Fragen? Einfach melden.

Thunderbird Autoconfig: Automatische E-Mail-Konfiguration für den eigenen Mailserver

Thunderbird kann sich selbst konfigurieren. Der Benutzer gibt E-Mail-Adresse und Passwort ein, Thunderbird sucht die Servereinstellungen automatisch — kein Eintippen von Hostnamen, Ports oder Verschlüsselungsoptionen. Das funktioniert nicht nur bei Gmail oder GMX, sondern auch mit dem eigenen Mailserver. Man muss nur eine XML-Datei an der richtigen Stelle bereitstellen.

Wo Thunderbird nach der Konfiguration sucht

Thunderbird arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig:

1. Thunderbird ISPDB — Mozilla pflegt eine zentrale Datenbank mit Konfigurationen für große Provider. Steht die Domain dort, ist sofort alles konfiguriert. Für eigene Mailserver irrelevant.

2. autoconfig.<domain> — Thunderbird fragt https://autoconfig.example.org/mail/config-v1.1.xml. Das ist der Weg, den wir nutzen. Ein CNAME im DNS, ein Webserver mit gültigem TLS-Zertifikat, eine statische XML-Datei — fertig.

3. .well-known auf der Domain — Thunderbird versucht https://example.org/.well-known/autoconfig/mail/config-v1.1.xml. Funktioniert, wenn die Domain selbst einen Webserver hat. Braucht keinen eigenen Hostnamen.

4. MX-Heuristik — Als Fallback versucht Thunderbird gängige Hostnamen wie imap.example.org und smtp.example.org mit üblichen Ports und Verschlüsselung. Klappt oft, ist aber Glückssache.

5. Manuell — Wenn nichts funktioniert, muss der Benutzer alles von Hand eingeben. Genau das wollen wir vermeiden.

Die config-v1.1.xml

Die XML-Datei beschreibt alle Servereinstellungen. Thunderbird liest sie und konfiguriert das Konto automatisch. Hier die Version, die ich für alle meine Maildomains einsetze:

<?xml version="1.0" encoding="UTF-8"?>
<clientConfig version="1.1">
  <emailProvider id="kernel-error.de">
    <domain>kernel-error.de</domain>
    <domain>kernel-error.com</domain>
    <domain>vandemeer.de</domain>
    <domain>fuchs-meckenheim.de</domain>
    <domain>heidbreders.de</domain>
    <domain>linux-rheinbach.de</domain>
    <domain>rfc-ignorant.de</domain>

    <displayName>kernel-error.de Mail</displayName>
    <displayShortName>kernel-error</displayShortName>

    <incomingServer type="imap">
      <hostname>imap.kernel-error.de</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>

    <outgoingServer type="smtp">
      <hostname>smtp.kernel-error.de</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
  </emailProvider>
</clientConfig>

Wichtige Details:

%EMAILADDRESS% — Thunderbird ersetzt das automatisch durch die eingegebene E-Mail-Adresse. Kein PHP nötig, kein dynamisches Script — eine statische Datei reicht. Das ist der große Unterschied zu Outlook Autodiscover, wo ein PHP-Script die E-Mail-Adresse aus dem POST extrahieren muss.

password-cleartext — Klingt gefährlich, ist es nicht. Es bedeutet, dass das Passwort über die TLS-verschlüsselte Verbindung gesendet wird. Der Name ist irreführend — Mozilla meint damit „Klartext innerhalb des verschlüsselten Kanals“ im Gegensatz zu Challenge-Response-Verfahren wie CRAM-MD5.

Port 465 (implizites TLS) — Die Verbindung ist sofort verschlüsselt, kein STARTTLS-Handshake nötig. Ein Eintrag reicht — Thunderbird braucht keinen Fallback.

Mehrere <domain>-Einträge — Eine XML-Datei für alle Maildomains. Thunderbird prüft, ob die Domain der eingegebenen E-Mail-Adresse in der Liste steht.

DNS und Webserver

Für jede Maildomain wird ein DNS-CNAME angelegt:

autoconfig.vandemeer.de.  IN CNAME www.kernel-error.de.

Alle CNAMEs zeigen auf denselben Webserver. Dort braucht jeder Hostname einen eigenen HTTPS-Server-Block mit passendem TLS-Zertifikat — Thunderbird akzeptiert keine Zertifikatsfehler. Die Nginx-Konfiguration ist simpel:

server {
    listen      [::]:443 ssl;
    listen      443 ssl;
    server_name autoconfig.vandemeer.de;

    ssl_certificate     /usr/local/etc/letsencrypt/live/vandemeer.de/fullchain.pem;
    ssl_certificate_key /usr/local/etc/letsencrypt/live/vandemeer.de/privkey.pem;

    location /mail/ {
        alias /usr/local/www/autoconfig-mail/mail/;
    }
}

Das TLS-Zertifikat muss autoconfig.vandemeer.de als SAN enthalten. Bei Let’s Encrypt reicht ein certbot --cert-name vandemeer.de -d vandemeer.de -d www.vandemeer.de -d autoconfig.vandemeer.de beim nächsten Renewal.

Für Domains mit Wildcard-Zertifikat (*.kernel-error.de) entfällt das — der Hostname ist direkt abgedeckt.

Unterschied zu Outlook Autodiscover

Thunderbird und Outlook lösen dasselbe Problem auf unterschiedlichen Wegen:

Thunderbird Autoconfig — Statische XML-Datei, %EMAILADDRESS% als Platzhalter, GET-Request, kein serverseitiges Scripting nötig.

Outlook Autodiscover — POST-Request mit E-Mail-Adresse im Body, PHP-Script extrahiert den Benutzernamen dynamisch, DNS SRV-Records statt CNAME. Details dazu: Outlook Autodiscover für IMAP/SMTP

Beide können auf demselben Webserver laufen. Bei mir bedient autodiscover.kernel-error.de Outlook per POST und liefert gleichzeitig /mail/config-v1.1.xml für Thunderbird aus.

Fragen? Gerne per Kontaktseite.

SPF Records

Veraltet: Der dedizierte SPF-DNS-Record-Typ (Typ 99) wurde mit RFC 7208 im Jahr 2014 als deprecated eingestuft. SPF wird heute ausschließlich über TXT-Records veröffentlicht. Siehe den aktuellen SPF-Beitrag.

Es gibt seit einiger Zeit einen dedizierten SPF-Record. Dieser wird auch bereits von vielen SPF-Filtern sowie Bind seit Version 9.4 unterstützt. Dieses entlastet etwas die TXT Anfragen und sorgt für mehr Ordnung. Wird dieser SPF Record vom jeweiligen SPF Filter unterstützt, fragt dieser meist zuerst nach dem SPF-Record und wenn es keine Antwort gibt als nächstes nach einem TXT-SPF Record.

Um diesen Filtern etwas Arbeit zu ersparen, das DNS etwas aufzuräumen und auf lange Sicht RFC konform zu bleiben (es würde mich nicht wundern wenn der TXT-SPF Record bald ausstirbt). Sollte man ebenfalls bei seiner SPF geschützten Domain einen solchen Record erstellen.

Für meinen Bind und die Domain kernel-error.de würde ein Beispiel wie folgt aussehen:

kernel-error.de.    IN    SPF    "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

Geprüft werden kann alles schnell und einfach mit DIG:

# dig kernel-error.de IN SPF +short
"v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

Sobald alle gängigen Filter die SPF-Records implementiert haben und alle Postmaster ihre Einführungszeit hatten, kann man dann sicher seinen TXT-SPF-Record entfernen. Dieses dauert sicher wieder ein paar Jahre! Ach ja, mein TXT SPF Record schaut so aus:

kernel-error.de.    IN    TXT    "v=spf1 ip4:212.23.142.146 ip6:2001:7d8:8001:100::2 ptr:smtp.kernel-error.de mx a:smtp.kernel-error.de -all"

 

 

Mehr zum Lesen:

SPF
SPF-RECORD
SPF-RECORD erkärt

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑