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

Schlagwort: TLS (Seite 2 von 5)

Postfix: Eingehende E-Mails ohne TLS ablehnen

Standardmäßig nimmt Postfix E-Mails auch ohne Transportverschlüsselung an. Mit smtpd_tls_security_level = may bietet der Server TLS an, erzwingt es aber nicht. Das bedeutet: Wenn die Gegenseite kein STARTTLS kann oder will, wird die Mail trotzdem im Klartext übertragen.

Man kann das ändern und E-Mails ohne TLS komplett ablehnen. Die Frage ist ob man sich das leisten kann.

Konfiguration

# /usr/local/etc/postfix/main.cf
smtpd_tls_security_level = encrypt

Mit encrypt verweigert Postfix die Annahme wenn der sendende Server kein STARTTLS aushandelt. Die Gegenseite bekommt einen temporären Fehler (454) und kann es später nochmal versuchen. Im Log steht dann:

postfix/smtpd: NOQUEUE: reject: RCPT from mail.example.de[...]: 454 4.7.0 TLS is required but was not offered

Vorher prüfen

Bevor man TLS erzwingt, sollte man wissen wie viele Mails betroffen wären. Im Postfix-Log lässt sich das auswerten:

# Anteil TLS vs. Klartext bei eingehenden Verbindungen
grep "TLS connection established" /var/log/maillog | wc -l
grep "connect from" /var/log/maillog | wc -l

In der Praxis liegt der TLS-Anteil bei den meisten Mailservern über 95 Prozent. Die letzten paar Prozent sind oft schlecht gewartete Systeme, Onlineshop-Bestätigungen oder Geräte aus Asien die sich nie um TLS gekümmert haben. Ob das ein Problem ist, hängt davon ab wessen Mails man bereit ist zu verlieren.

Ausgehend erzwingen

Für ausgehende Mails ist die Situation anders. Mit smtp_tls_security_level = encrypt verweigert Postfix die Zustellung wenn die Gegenseite kein TLS anbietet. Das ist riskant, weil man keine Kontrolle darüber hat ob der Empfänger-Server TLS kann.

Der bessere Weg für ausgehende Mails: MTA-STS und DANE prüfen automatisch ob die Zieldomain TLS verlangt und welches Zertifikat erwartet wird. Damit erzwingt man TLS nur dort wo die Gegenseite es auch unterstützt und verifiziert gleichzeitig die Identität.

# Ausgehend: opportunistisch, aber DANE wenn verfügbar
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec

Mit dane als Security-Level nutzt Postfix DANE/TLSA-Records aus dem DNS. Ist ein TLSA-Record vorhanden, wird TLS erzwungen und das Zertifikat verifiziert. Ohne TLSA-Record bleibt es bei opportunistischem TLS. Zusammen mit dem Abschalten von TLS 1.0/1.1 ergibt das eine saubere Konfiguration. Fragen? Einfach melden.

Postfix-Fehlerantworten anpassen: So gehst du vor

Wieder wurde ich gefragt wie ich bei meinem Postfix den Error Reply für rejected 5xx E-Mails geändert habe. Nun ja, das habe ich überhaupt nicht.

Postfix hat seit vielen Jahren die Option: smtpd_reject_footer diese wurde in 2011 beim „Aufräumen“ umbenannt in: smtpd_reject_footer

Cleanup: smtpd_reject_contact_information is renamed to smtpd_reject_footer, because it can be used for non-contact information.

Beide Optionen sind anscheinend eher unbekannt. Was ich gut verstehen kann. Denn setzt man nun in seiner main.cf den smtpd_reject_footer wird diese zwar brav angehangen und taucht sogar beim Absender im Postfach auf, nur welcher Benutzer liest diese schon und folgt dann noch dem jeweiligen Hinweis? Bisher ist diese Rückmeldung meines Systems nur sehr wenigen überhaupt aufgefallen ;-P

Vor ~12 Jahren habe ich sie wohl zum ersten Mal gesetzt. Ich meine da auf die Adresse vom Postmaster verwiesen zu haben, damit die Nutzer sich dort hin melden können. Später hatte ich mal einen Link auf eine zweisprachige Hilfeseite bei mir und noch später etwas wie: „Das Problem ist zu 99% dein Mailserver, frag DEINEN Admin!“. Dieses war es bis heute, denn heute habe ich die erneute Frage zum Anlass genommen, dieses hier zu schreiben und natürlich direkt auf riot.im zu verlinken. Dann kann man mich direkt anschreiben. Sicher etwas freundlicher als: „geh weg du bist eh das Problem“ und einfacher als noch eine E-Mail an den Postmaster zu schreiben. Sicher werde ich nun durch diese Nachricht 1 oder 2 mal im Jahr angeschrieben, wenn es dieses überhaupt wird.

Achja, so sieht der Eintrag in der main.cf von Postfix aus:

root@smtp:/usr/local/etc/postfix # postconf smtpd_reject_footer
smtpd_reject_footer = For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com

Damit lässt sich nun dieses Ergebnis erzielen:

banane@bsd03:~ # telnet smtp.kernel-error.de 25
Trying 2a01:4f8:150:1095::25...
Connected to smtp.kernel-error.de.
Escape character is '^]'.
220 smtp.kernel-error.de ESMTP Postfix
helo asdf
250 smtp.kernel-error.de
mail from: <test@spam.de>
250 2.1.0 Ok
rcpt to: <spamlover@kernel-error.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
subject: test
.test
.
554-5.7.1 Spam message rejected
554 5.7.1 For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com
Connection closed by foreign host.

Fragen? Dann wie immer bitte fragen…

Siehe auch: E-Mails ohne TLS ablehnen

Fragen? Einfach melden.

MTA-STS einrichten: Transportverschlüsselung für E-Mail erzwingen

SMTP überträgt E-Mails standardmäßig im Klartext. Mit STARTTLS lässt sich die Verbindung verschlüsseln, aber kein sendender Server ist gezwungen das auch zu tun. Schlimmer noch: Ein Angreifer im Netzwerk kann die STARTTLS-Antwort einfach unterdrücken und die Verbindung bleibt unverschlüsselt. MTA-STS (RFC 8461) löst dieses Problem: Der Empfänger veröffentlicht eine Policy, die sendenden Servern sagt „hier wird nur verschlüsselt zugestellt, mit gültigem Zertifikat, an genau diesen MX“.

MTA-STS vs. DANE

Es gibt zwei Wege, Transportverschlüsselung für E-Mail zu erzwingen: DANE und MTA-STS. DANE nutzt DNSSEC und TLSA-Records im DNS. Das ist technisch sauberer, setzt aber DNSSEC auf der Empfängerseite voraus. Viele große Provider (Google, Microsoft) haben kein DNSSEC. MTA-STS funktioniert ohne DNSSEC: Die Policy liegt als Textdatei auf einem Webserver, abgesichert durch ein normales TLS-Zertifikat. Wer beides kann, sollte beides einsetzen. DANE für die Server die DNSSEC können, MTA-STS für den Rest.

Die drei Komponenten

MTA-STS besteht aus drei Teilen: einem DNS-Record, einer Policy-Datei auf einem Webserver und optional TLS Reporting.

1. DNS TXT-Record

Ein TXT-Record unter _mta-sts.domain.de signalisiert, dass eine Policy existiert:

_mta-sts.kernel-error.de.  IN TXT  "v=STSv1;id=20260115130000Z;"

Die id ist ein beliebiger String. Sendende Server cachen die Policy und prüfen über die ID ob sich etwas geändert hat. Bei jeder Policy-Änderung muss die ID aktualisiert werden. Ich verwende dafür einen Zeitstempel, das macht es nachvollziehbar.

2. Policy-Datei

Die eigentliche Policy liegt unter https://mta-sts.domain.de/.well-known/mta-sts.txt. Wichtig: Der Webserver muss ein gültiges TLS-Zertifikat haben und unter genau diesem Hostnamen erreichbar sein.

version: STSv1
mode: enforce
mx: smtp.kernel-error.de
max_age: 2419200
modeenforce = nur verschlüsselt zustellen. testing = wie enforce, aber bei Fehlern trotzdem zustellen (gut zum Einstieg). none = Policy deaktiviert.
mxAn welche MX-Server zugestellt werden darf. Mehrere Einträge möglich (je eine Zeile). Wildcards gehen: *.kernel-error.de
max_ageWie lange die Policy gecacht wird, in Sekunden. 2419200 = 28 Tage.

Der empfohlene Weg: Mit mode: testing anfangen und die TLS-Reports auswerten. Wenn alles sauber ist, auf enforce umstellen.

3. TLS Reporting

Wie bei DMARC gibt es auch für MTA-STS ein Reporting-System: SMTP TLS Reporting (RFC 8460). Ein weiterer DNS TXT-Record teilt Absendern mit, wohin sie Berichte über TLS-Verbindungsprobleme schicken sollen:

_smtp._tls.kernel-error.de.  IN TXT  "v=TLSRPTv1;rua=mailto:postmaster@kernel-error.de"

Die Reports kommen als JSON per Mail und enthalten Informationen über fehlgeschlagene TLS-Verbindungen, ungültige Zertifikate oder MX-Mismatches. Google und Microsoft schicken diese Reports zuverlässig.

Postfix und MTA-STS

Postfix prüft von Haus aus keine MTA-STS-Policies. Für die ausgehende Seite braucht es postfix-mta-sts-resolver, ein Policy-Daemon der sich als smtp_tls_policy_maps in Postfix einhängt. Der Daemon cached die Policies und liefert Postfix die passende TLS-Konfiguration pro Zieldomain.

# /usr/local/etc/postfix/main.cf
smtp_tls_policy_maps = socketmap:unix:/var/run/mta-sts-daemon/mta-sts-daemon.sock:postfix

Die eingehende Seite braucht keine Software. Die drei DNS-Records und die Policy-Datei auf dem Webserver reichen aus. Sendende Server wie Gmail, Outlook oder Yahoo werten die Policy selbständig aus.

Testen

# DNS-Records prüfen
dig TXT _mta-sts.kernel-error.de +short
dig TXT _smtp._tls.kernel-error.de +short

# Policy abrufen
curl https://mta-sts.kernel-error.de/.well-known/mta-sts.txt

Siehe auch: internet.nl: Mailserver-Sicherheit testen mit dem niederländischen Standard, TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration, internet.nl verschärft die TLS-Anforderungen für Mailserver

Zusammen mit SPF, DKIM, DMARC und DANE ergibt MTA-STS eine lückenlose Absicherung: Authentifizierung (wer darf senden), Integrität (DKIM-Signatur) und Transportverschlüsselung (DANE/MTA-STS). Fragen? Einfach melden.

TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration

TLS 1.3 ist im Mailbetrieb kein Sonderfall mehr, sondern der Normalzustand. Voraussetzung ist lediglich, dass Postfix und Dovecot gegen eine aktuelle OpenSSL-Version gelinkt sind. Sobald OpenSSL TLS 1.3 unterstützt, wird es automatisch verwendet. Eine explizite Aktivierung in der Applikation ist nicht erforderlich.

Die eigentliche Aufgabe der Konfiguration besteht daher nicht darin, TLS 1.3 „einzuschalten“, sondern darin, alte Protokollversionen sauber zu deaktivieren und für den verbleibenden TLS-1.2-Fallback eine kontrollierte Cipher-Policy zu definieren.

Illustration zu TLS 1.3 im Mailbetrieb: Symbolische Darstellung von Postfix und Dovecot mit Schloss und Schlüssel vor Server-Hintergrund, steht für verschlüsselte SMTP- und IMAP-Verbindungen mit modernen TLS-Standards.

Voraussetzungen

Postfix und Dovecot müssen gegen OpenSSL ≥ 1.1.1 gebaut sein. OpenSSL 3.x funktioniert ebenfalls ohne Einschränkungen. Welche Version tatsächlich genutzt wird, lässt sich eindeutig prüfen:

postconf -a | grep -i tls
dovecot --version
ldd $(which dovecot) | grep ssl
openssl version

Wenn hier OpenSSL 1.1.1 oder neuer auftaucht, ist TLS 1.3 verfügbar.

Postfix

Postfix verwendet TLS 1.3 automatisch, sofern der Client es anbietet. Entscheidend ist, welche Protokollversionen minimal erlaubt werden. TLS 1.0 und TLS 1.1 gelten als kryptographisch überholt und sollten nicht mehr akzeptiert werden.

Die folgende Konfiguration beschränkt Postfix auf TLS 1.2 und neuer. TLS 1.3 wird dabei bevorzugt ausgehandelt, TLS 1.2 dient nur noch als Fallback.

smtpd_tls_protocols = >=TLSv1.2
smtp_tls_protocols  = >=TLSv1.2

smtpd_tls_security_level = may
smtp_tls_security_level  = may

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/DOMAIN/privkey.pem

Cipher-Optionen in Postfix gelten ausschließlich für TLS 1.2 und ältere Protokolle. TLS 1.3 verwendet fest definierte Cipher-Suites und ignoriert diese Einstellungen vollständig. Dennoch ist es sinnvoll, für den TLS-1.2-Fallback eine saubere Policy zu setzen.

tls_preempt_cipherlist = yes

smtpd_tls_ciphers = high
smtp_tls_ciphers  = high

Damit werden nur moderne Cipher mit Forward Secrecy genutzt, abhängig von den OpenSSL-Defaults der jeweiligen Distribution. Wer zusätzlich sicherstellen will, dass ausgehende Verbindungen verschlüsselt bleiben, sollte sich MTA-STS ansehen.

Session-Caching reduziert Handshake-Overhead und sollte aktiv sein:

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database  = btree:${data_directory}/smtp_scache

Dovecot

Auch Dovecot nutzt TLS 1.3 automatisch, sofern OpenSSL es bereitstellt. Die relevante Einstellung ist die minimale Protokollversion. Alles darunter wird explizit ausgeschlossen.

ssl = required
ssl_min_protocol = TLSv1.2

Die Cipher-Liste in Dovecot betrifft ebenfalls nur TLS 1.2 und älter. TLS 1.3 wird davon nicht beeinflusst. Eine explizite, restriktive Cipher-Liste verhindert jedoch unsaubere Fallbacks bei älteren Clients.

ssl_cipher_list = \
ECDHE-ECDSA-CHACHA20-POLY1305:\
ECDHE-RSA-CHACHA20-POLY1305:\
ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES256-GCM-SHA384

ssl_prefer_server_ciphers = yes

Die Zertifikate werden wie gewohnt eingebunden:

ssl_cert = </etc/letsencrypt/live/DOMAIN/fullchain.pem
ssl_key  = </etc/letsencrypt/live/DOMAIN/privkey.pem

TLS 1.3 und Cipher-Suites

TLS 1.3 unterscheidet sich grundlegend von älteren Versionen. Die Cipher-Suites sind fest definiert und bestehen ausschließlich aus modernen AEAD-Verfahren mit integrierter Authentifizierung und Forward Secrecy. Typische Cipher sind AES-GCM und CHACHA20-POLY1305.

Postfix und Dovecot bieten keine Möglichkeit, diese Cipher direkt zu konfigurieren. Die Auswahl erfolgt intern durch OpenSSL während des Handshakes. Das ist beabsichtigt und reduziert Fehlkonfigurationen erheblich.

Wer versucht, TLS-1.3-Cipher über Applikationsoptionen zu beeinflussen, konfiguriert faktisch nur TLS 1.2.

Verifikation

Ob TLS 1.3 tatsächlich genutzt wird, lässt sich eindeutig prüfen.

SMTP mit STARTTLS:

openssl s_client -starttls smtp -connect mail.example.com:25 -tls1_3

IMAPS:

openssl s_client -connect mail.example.com:993 -tls1_3

Wird der Handshake erfolgreich aufgebaut und ein moderner AEAD-Cipher angezeigt, ist TLS 1.3 aktiv. Fällt die Verbindung auf TLS 1.2 zurück, greift die konfigurierte Cipher-Liste.

Fazit

TLS 1.3 erfordert in Postfix und Dovecot keine Sonderbehandlung. Entscheidend ist eine aktuelle OpenSSL-Version, eine klare Mindest-TLS-Policy und eine saubere Cipher-Konfiguration für den unvermeidbaren TLS-1.2-Fallback.

Alles andere erledigt der TLS-Stack selbst. Wer noch einen Schritt weiter gehen will, findet im Beitrag zu Post-Quantum TLS für E-Mail die nächste Stufe.

Kein Feature-Flag.
Keine Magie.
Nur korrekte Defaults, bewusst begrenzt.

Fragen? Einfach melden.

Hardenize ein Security-Scanner für die Domain

Mir ist ein weiteres Onlinetool zum scannen seiner Domain durch den Browser gerutscht. https://www.hardenize.com/

Wie immer darf man nicht bild jedem Tool trauen und sich ohne denken darauf verlassen! Die Ergebnisse müssen immer mit dem nötigen Hintergrundwissen und Feingefühl interpretiert werden…. Hardenize testet nach der Eingabe einer Domain etwas umfassender. Es schaut sich die TLS Konfiguration der Webseite, sowie des Mailservers an. Prüft auf wichtige Policys, schaut in den DNS und bewertet somit etwas das Gesamtbild.

Vielleicht interessant für einen von euch.

Fragen? Einfach melden.

TLS 1.3 ist da!

Im August wurde TLS 1.3 auf der IETFE-Tagung als fertig beschlossen. Damit haben sich aber alle wirklich Zeit gelassen! OpenSSL hat am 11.09.2018 die Version 1.1.1 (LTS) freigegeben. Am 12.09.2018 ist diese in die FreeBSD Ports gekommen und:

root@www:/ # /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018

Fehlt also nur noch ein Eintrag in der make.conf und schon lässt sich nginx sauber dagegen bauen und alles automatisch mit portmaster auf dem neusten Stand halten 🙂

/etc/make.conf
DEFAULT_VERSIONS+= ssl=openssl111

Schaut mal nach, die meisten machen wohl jetzt schon TLS 1.3 beim lesen dieser Zeilen ^^

Qualys und SSL Labs hängen leider noch etwas nach, hier wird noch auf/gegen die Draft Version geprüft (For TLS 1.3 tests, we currently support draft version 28.). Aber ich wette das wird nicht mehr lange dauern!

Kleines Update, die HIGH-TECH Bridge Jungs testen sauber auf TLS 1.3.

Ich wurde gerade drauf hingewiesen, dass die Developer Version von ssllabs TLS 1.3 schon sauber testet. Danke Jost.

https://dev.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&s=2a01%3a4f8%3a161%3a3ec%3a0%3a0%3a0%3a443&hideResults=on&latest

Siehe auch: TLS 1.0 und 1.1 abschalten

Fragen? Einfach melden.

TLS 1.0 und 1.1 abschalten: Postfix, Dovecot und Nginx auf TLS 1.2+ umstellen

TLS 1.0 stammt von 1999, TLS 1.1 von 2006. Beide Versionen haben bekannte Schwächen (BEAST, POODLE, fehlende AEAD-Cipher) und werden seit 2020 von keinem Browser mehr unterstützt. Qualys SSL Labs vergibt seit 2020 maximal ein B-Rating wenn TLS 1.0 oder 1.1 aktiv ist. Es gibt keinen Grund mehr, diese Protokolle anzubieten.

Postfix

In der main.cf die Mindestversion auf TLS 1.2 setzen. Die Einstellungen gelten getrennt für eingehende (smtpd) und ausgehende (smtp) Verbindungen:

# Eingehend (smtpd)
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2

# Ausgehend (smtp)
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2

Die Syntax >=TLSv1.2 gibt es seit Postfix 3.6. Bei älteren Versionen muss man die alten Protokolle einzeln ausschließen: !SSLv2, !SSLv3, !TLSv1, !TLSv1.1. Wenn OpenSSL 1.1.1+ oder neuer installiert ist, wird TLS 1.3 automatisch unterstützt und bevorzugt.

Dovecot

In conf.d/10-ssl.conf:

ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
ssl_prefer_server_ciphers = yes

ssl_min_protocol gibt es seit Dovecot 2.3.15. In älteren Versionen heißt es ssl_protocols = !SSLv3 !TLSv1 !TLSv1.1. Die Cipher-Liste enthält nur AEAD-Cipher mit Forward Secrecy.

Nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;

Die TLS-1.3-Cipher (TLS_AES_*) werden von OpenSSL automatisch bevorzugt und lassen sich nicht über ssl_ciphers deaktivieren. Die Reihenfolge in der Cipher-Liste gilt nur für TLS 1.2.

stunnel

Wer stunnel als TLS-Wrapper nutzt (z.B. für DNS over TLS):

options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1

Prüfen

Nach der Umstellung prüfen ob die alten Protokolle wirklich deaktiviert sind:

# TLS 1.0 testen (sollte fehlschlagen)
openssl s_client -connect smtp.example.de:25 -starttls smtp -tls1 2>&1 | grep "Protocol"

# TLS 1.2 testen (sollte funktionieren)
openssl s_client -connect smtp.example.de:25 -starttls smtp -tls1_2 2>&1 | grep "Protocol"

Für Webserver hilft Qualys SSL Labs. Wer noch einen Schritt weitergehen will: Mit ECDSA-Zertifikaten wird der Handshake schneller und mit Post-Quantum Key Exchange ist der Schlüsselaustausch auch gegen Quantencomputer abgesichert. Fragen? Einfach melden.

DNS over TLS mit Stunnel und BIND9: Eigenen DoT-Server einrichten

DNS-Abfragen laufen normalerweise im Klartext über UDP Port 53. Jeder der den Traffic mitlesen kann (ISP, Hotspot-Betreiber, Geheimdienst) sieht welche Domains aufgelöst werden. RFC 7858 definiert DNS over TLS (DoT): DNS-Abfragen über eine TLS-verschlüsselte TCP-Verbindung auf Port 853.

BIND9 konnte zum Zeitpunkt dieses Beitrags kein natives DoT. Die Lösung: stunnel als TLS-Wrapper vor den BIND stellen. stunnel terminiert die TLS-Verbindung auf Port 853 und leitet die entschlüsselten DNS-Pakete an BIND auf Port 53 weiter.

Stunnel-Konfiguration

Unter FreeBSD liegt die Konfiguration in /usr/local/etc/stunnel/conf.d/. Für IPv4 und IPv6 jeweils eine Sektion:

# /usr/local/etc/stunnel/conf.d/dnstls.conf

[dns4]
accept = 853
connect = 127.0.0.1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt

[dns6]
accept = :::853
connect = ::1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt

accept ist der Port auf dem stunnel lauscht (853 = DoT-Standard). connect ist der lokale BIND9. Das Zertifikat muss für den Hostnamen des DNS-Servers gültig sein, sonst schlägt die Validierung auf der Client-Seite fehl.

Testen

TLS-Verbindung prüfen:

openssl s_client -connect ns1.kernel-error.de:853

In der Ausgabe sollte Verify return code: 0 (ok) stehen und eine TLS-1.2- oder TLS-1.3-Verbindung angezeigt werden.

DNS-Abfrage über TLS mit getdns_query (in den FreeBSD-Ports als getdns):

getdns_query @ns1.kernel-error.de -s -a -A -l L www.kernel-error.de AAAA

Die Option -l L erzwingt TLS. Bei Erfolg kommt ein JSON-Objekt mit "status": GETDNS_RESPSTATUS_GOOD und der aufgelösten Adresse zurück. Alternativ kann man mit kdig (aus dem Paket knot-utils) testen:

kdig +tls @ns1.kernel-error.de www.kernel-error.de AAAA

Clients

Android 9+ hat DoT nativ eingebaut (Einstellungen → Netzwerk → Privates DNS). Dort den Hostnamen des eigenen DNS-Servers eintragen. Unter Linux kann systemd-resolved DoT, oder man nutzt stubby als lokalen DoT-Proxy.

Weiterentwicklung

Siehe auch: RFC 7858 – DNS over Transport Layer Security, DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten, DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server, BIND auf FreeBSD: DoT & DoH einrichten mit Views, IP‑Trennung und Testplan für IPv4/IPv6.

Neben DoT gibt es inzwischen auch DNS over HTTPS (DoH), das DNS-Abfragen über HTTPS auf Port 443 tunnelt. DoH hat den Vorteil, dass es durch Firewalls und Proxies nicht blockiert werden kann, weil es wie normaler HTTPS-Traffic aussieht. Mein DNS-Resolver dns.kernel-error.de bietet inzwischen beides an. Fragen? Einfach melden.

RFC 7858 – DNS over Transport Layer Security

Ich habe in den letzten Tagen etwas mit dem RFC 7858 (https://tools.ietf.org/html/rfc7858) herumgespielt. Meine Zonen und auch Dienste sind per DNSsec, HSTS, Pinning usw. usw. abgesichert. Warum also noch DNS per TLS? Nun ja… Sinn macht es sicher keinen, bei mir ist nichts spannendes zu finden und kaum ein Besucher wird mit Problemen rechnen müssen wenn er hier ist. Für mich sollte Kryptographie nicht die Ausnahme sondern der Normalzustand sein. RFC 7858 ist da nur ein weiteres Detail. In einer DNS Abfrage finden sich selten geheime Daten. Klar wäre es schlecht wenn diese verändert würden um diese zu verhindern reicht eine Signatur. Das mitlesen der DNS Abfragen würde einer dritten Person so aber offenlegen wo man surft und welche Dienste man nutzt. Sind diese Abfragen per TLS verschlüsselt bleibt dieses geheim. Daher macht es wohl am meisten Sinn es für seinen lokalen DNS Resolver zu nutzen oder es auf großen DNS Servern zu aktivieren. DNS Servern welche sich um viele Zonen kümmern….

Um irgendwo zu starten und selbst einen Eindruck davon zu bekommen habe ich es auf meinen DNS Servern für meine Zonen aktiviert. Bis auf ns2.kernel-error.org haben die Server gültige Zertifikate. Bei ns2.kernel-error.org muss ich mal schauen wie es sich entwickelt.

Als Test:

$ getdns_query -s www.kernel-error.de a @176.9.109.53 -l L

Viel Spaß

Siehe auch: DoT und DoH mit BIND 9.20, DNS over TLS mit Stunnel und BIND9: Eigenen DoT-Server einrichten, DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten, DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server

Fragen? Einfach melden.

Ein Blick auf die Apache Header

TLS allein reicht nicht. Auch mit einem A+ bei Qualys SSL Labs fehlt ein wichtiger Teil: die HTTP-Security-Header. Sie schützen vor Cross-Site-Scripting, Clickjacking und MIME-Sniffing. Trotzdem setzen die wenigsten Webserver sie. Einen schnellen Überblick gibt securityheaders.com.

Modul aktivieren

Apache braucht das Headers-Modul. Unter Debian/Ubuntu:

a2enmod headers
service apache2 restart

Für spätere Konfigurationsänderungen reicht ein Reload (service apache2 reload).

Header setzen

Die Header können global in /etc/apache2/conf-enabled/security.conf oder pro vHost in der jeweiligen Konfigurationsdatei gesetzt werden:

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Header set X-Content-Type-Options: "nosniff"
Header set X-Frame-Options: "sameorigin"
Header set X-Permitted-Cross-Domain-Policies: "master-only"
Header set X-XSS-Protection: "1; mode=block"
Header unset X-Powered-By

Was die einzelnen Einstellungen bewirken

ServerSignature Off entfernt die Serverversion aus Fehlerseiten. ServerTokens Prod reduziert den Server-Header auf das Wort „Apache“, ohne Versionsnummer. Komplett entfernen lässt sich der Header im Standard-Apache nicht. Es gibt dazu einen Bug-Report mit WONTFIX. Manche Distributionen patchen das, sonst muss man selbst kompilieren oder damit leben.

TraceEnable Off deaktiviert die HTTP-TRACE-Methode serverweit.

X-Frame-Options: sameorigin verhindert, dass die Seite in fremde iframes eingebettet wird. Wer Einbettungen braucht, sollte diesen Header weglassen oder auf Content-Security-Policy: frame-ancestors umsteigen.

X-Content-Type-Options: nosniff verhindert MIME-Type-Sniffing im Browser. X-XSS-Protection aktiviert den XSS-Filter in älteren Browsern. Moderne Browser setzen stattdessen auf Content Security Policy (CSP).

Header unset X-Powered-By entfernt den PHP-Versionsheader, sofern vorhanden.

Ergebnis prüfen

Nach dem Reload die eigene Domain auf securityheaders.com scannen. Die Bewertung sollte sich deutlich verbessert haben.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑