Ich bin beim sehen fast vor Lachen umgefallen. Nur gut, dass ich zwischendurch auch weinen musste. So hat es sich etwas ausgeglichen. Viel "Spaß"..
Fragen? Einfach melden.
Schlagwort: Security (Seite 3 von 16)
Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.
Über die Techniken DoT (DNS over TLS) habe ich bereits im Zusammenhang mit Bind 9.16 geschrieben. Ebenfalls DoH (DNS over HTTPS) gibt es einen kleinen Beitrag.
Zu diesem Zeitpunkt bracht BIND 9 die Unterstützung für DoH und DoT noch nicht selbst mit. Daher waren zu diesem Zeitpunkt noch Umwege über stunnel oder nginx zusammen mit doh-proxy nötig.
Zum Glück kommt die letzte stable Version 9.18.0 (26. Januar 2022) mit dem nötigen Support.
named now supports securing DNS traffic using Transport Layer Security (TLS). TLS is used by both DNS over TLS (DoT) and DNS over HTTPS (DoH).
Warum möchte man noch gleich DoH oder DoT benutzen? Ganz einfach… Über diese Techniken werden DNS Abfragen verschlüsselt übertragen. Dieses ist ein weiterer Schutz davor manipulierte Antworten zu bekommen und selbstverständlich, damit die eigenen DNS Abfragen erst überhaupt nicht mitgelesen werden. Denn wenn von einem Gerät im Netzwerk die DNS Abfrage zu z.B.: www.tagesschau.de kommt, könnte man davon bereits Dinge ableiten.
Wie die meisten Bind Konfigurationen ist dieses ebenfalls straightforward. Ab Version 9.18 bringt Bind alles Nötige mit. Da wir nun TLS mit dem Bind sprechen möchten, benötigen wir natürlich ein gültiges Zertifikat, wie z.B. beim nginx für seine Webseite.
Ebenfalls sollte man ein paar frische Diffie-Hellmann Parameter generieren:
openssl dhparam -out dhparam.pem 4096
Die eigentliche bind Konfiguration kann in der named.conf.options geschehen:
options {
[...]
listen-on port 853 tls local-tls { 37.120.183.220; };
listen-on-v6 port 853 tls local-tls { 2a03:4000:38:20e::853; };
listen-on port 443 tls local-tls http default { 37.120.183.220; };
listen-on-v6 port 443 tls local-tls http default { 2a03:4000:38:20e::853; };
[...]
allow-recursion-on { 127.0.0.0/8; ::1/128; 2a03:4000:38:20e::853; 37.120.183.220; };
[...]
};
Da der bind auf weiteren Ports lauschen soll erweitert man diese für IPv4 und IPv6. Der Default Port für DoH ist dabei 443 und der default Port für DoT ist 853, beides TCP.
listen-on sowie listen-on-v6 sind wohl selbsterklärend.
port ist der TCP Port und erklärt sich ebenfalls.
tls sagt dem Bind das wir tls sprechen möchten.
local-tls verweißt auf den gleichnamigen tls Block über welchen man seine TLS Konfiguration vornimmt.
http ist für DoH.
default gibt den eigentlichen endpoint für die DoH Abfragen an, im default ist es /dns-query
Da der Server unsere DNS Abfragen erledigen soll, müssen wir ihm dieses noch per allow-recursion-on auf den jeweiligen Adressen erlauben.
Als nächstes wird die eigentliche TLS Terminierung konfiguriert (das lässt sich ebenfalls auslagern, wenn gewünscht). Dafür wird der folgende Block, außerhalb der Options Blocks, ergänzt:
tls local-tls {
cert-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/chain.crt";
key-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/http.key";
dhparam-file "/usr/local/etc/ssl/dhparam.pem";
protocols { TLSv1.2; TLSv1.3; };
ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
prefer-server-ciphers yes;
session-tickets no;
};
local-tls ist dabei der name des Blocks. Auf diesen verweisen wir oben.
cert-file ist der Pfad zum Zertifikat. Ich habe dort nicht nur das Zertifikat, sondern die gesamte Chain, also mit Intermediate und Root.
key-file ist der Pfad zum Key des Zertifikates.
dhparam-file ist der Pfad zu den Diffie-Hellman Parametern.
protocols definiert die zu verwendenden TLS Protokolle. In diesem Beispiel TLS1.2 sowie TLS1.3.
ciphers definiert die zu verwendenden cipher. Es soll ja „sicher“ bleiben.
prefer-server-ciphers übermittelt dem Client die Information, in welcher Reihenfolge protokoll/cipher Kombinationen probiert werden sollen um einen Match zu finden. Erst das vermeintlich sicherste und dann immer „schlechter“.
session-tickets regelt ob eine Wiederaufnahme von TLS Sessions erlaubt ist oder nicht. Da ich forward secrecy nutzen möchte, ist es deaktiviert.
Damit ist die Konfiguration schon abgeschlossen (Firewall ggf. nicht vergessen!). Also testen….
Ein einfaches Tool dafür ist dog, oder natürlich dig aus den bind-tools aber Version 9.18. Für bind gibt es dann die Optionen +https oder auch +tls
dig +https @dns.kernel-error.de www.kernel-error.de A dig +tls @dns.kernel-error.de www.kernel-error.de A
Der gleiche Test mit dog, sieht wie folgt aus:
dog www.kernel-error.de --tls "@dns.kernel-error.de" A www.kernel-error.de. 6h00m00s 148.251.40.23 dog www.kernel-error.de --https "@https://dns.kernel-error.de/dns-query" A www.kernel-error.de. 6h00m00s 148.251.40.23
Das war es auch schon! Viele Spaß mit einem „besseren“ DNS und wenn es noch Fragen gibt, einfach fragen.
Ich nutze Joomla seit 2006, als es aus Mambo hervorging. Die Datenbank und einige Plugins/Teils sind inzwischen also sehr alt und machen bei Versionssprüngen immer mehr Probleme. Den Wechsel vom CMS habe ich dennoch immer von mir weggeschoben, denn es macht viel Arbeit und für eine solch kleine Spielerei lohnt der Aufwand kaum. Da ich es inzwischen eh nur noch für einfache Blogeinträge nutze… Nun ich werde wohl in der nächsten Zeit auf WordPress wechseln. Damit wird es ebenfalls einen neuen RSS Feed geben und sicher wird ebenfalls viel Content verschwinden.
Fragen? Einfach melden.
Lieber Thorben,
vielen Dank, dass du uns so lange ertragen hast. Du hast unsere Arbeit leichter und bunter gemacht. Ohne dich hätten wir sicher schon die Raufasertapete mehr als einmal von der Wand gefressen.
Vielen Dank für deine Unterstützung in technischer und menschlicher Weise! Wir werden dich NIE vergessen!
Liebe Grüße
Die zwei „Dicken“
Wenn ich schon bei Microsoft-Themen bin: Warum nicht gleich noch RRAS (Routing und RAS) mit einem L2TP/IPsec-VPN absichern? Im Standard verbinden sich die Clients nämlich mit SHA-1, 3DES und DH Group 2 (modp1024, also 1024 Bit). SHA-1 ist grenzwertig, 3DES muss nicht sein und modp1024 will man definitiv nicht mehr.
Hinweis: Ursprünglich für Windows Server 2012 R2 geschrieben (inzwischen End of Life). Die Konfiguration über die Windows-Firewall funktioniert auf neueren Versionen identisch.
Wo man die Einstellung findet (Spoiler: nicht bei RRAS)
Ich habe einige Zeit gesucht. Man würde erwarten, dass die IPsec-Cipher irgendwo in der Nähe von Routing und RAS konfiguriert werden. Falsch gedacht. Die Einstellung steckt in der Windows-Firewall mit erweiterter Sicherheit. Irgendeinen Grund wird es haben, das dort zu verstecken. Ich hätte dort nie gesucht.
Der Klickpfad: Windows Firewall → Rechtsklick auf „Windows-Firewall mit erweiterter Sicherheit“ → Eigenschaften → IPsec-Einstellungen → IPsec-Standardeinstellungen → „Anpassen“ → Schlüsselaustausch.
Hier kann man die Sicherheitsmethoden und Datenschutzeinstellungen anpassen. Windows Firewall als Ort für VPN-Cipher-Konfiguration. Kopfschütteln.
UDP Encapsulation hinter NAT
Steht der RRAS hinter einem NAT, muss man noch UDP Encapsulation per Registry aktivieren. Dafür habe ich ein Registry-File:
Nach allen Änderungen den Server neu starten. Microsoft halt.
Prüfen ob es geklappt hat
Auf einem Windows-Client per PowerShell (mit erweiterten Rechten) prüfen, welche Cipher die VPN-Verbindung tatsächlich nutzt:
Get-NetIPsecMainModeSA | Select-Object -First 1
Relevant sind CipherAlgorithm, HashAlgorithm und GroupId. Im Standard steht da 3DES, SHA-1 und DH Group 2 (1024 Bit). Nach den Änderungen:
Encryption: AES256 Authentication/Integrity: SHA-1 Key Size: DH Group 20 (384-bit ECC)
Immer noch SHA-1 für die Integrity, aber AES-256 und ECC sind ein großer Sprung. Über Gruppenrichtlinien ließe sich das Ganze auch zentral ausrollen, aber das ist nochmal ein eigenes Thema. Vor allem die Reihenfolge korrekt vorzugeben ist dort unerwartet fummelig.
Wer auch die TLS-Cipher für Exchange/OWA härten will: SSL Labs A+ mit Exchange. Fragen? Einfach melden.
Ich hatte hier einen Windows Server 2012 R2 mit Exchange 2016 stehen. Out of the Box sprach das Ding TLS 1.0, SSLv3 und RC4. Da gehen einem die Haare hoch. Kann man so ein System auf ein A+ bei Qualys SSL Labs bekommen und es funktioniert danach noch? Kleiner Spoiler: Ja, geht.
Ich muss zugeben, Microsoft-Produkte strengen mich in dieser Hinsicht immer an. Die haben ihre Daseinsberechtigung, keine Frage. Aber TLS-Hardening unter Windows fühlt sich an wie Zahnmedizin mit Handschuhen aus Pappe.
Hinweis: Windows Server 2012 R2 und Exchange 2016 sind inzwischen End of Life. Der Ansatz (Registry-Änderungen für TLS, HSTS im IIS) funktioniert auf Windows Server 2016/2019/2022 aber genauso.
HSTS im IIS setzen
Für ein A+ braucht man neben sauberen Ciphern und Protokollen auch HTTP Strict Transport Security (HSTS). Das ist im Grunde nur ein HTTP-Response-Header. Im IIS-Manager konfiguriert man ihn ganz oben auf Server-Ebene, damit er überall vererbt wird:
IIS-Manager → HTTP-Antwortheader → Hinzufügen:
Name: strict-transport-security Wert: max-age=31536000; includeSubdomains
TLS-Protokolle und Cipher härten
Jetzt der eigentlich spannende Teil. Man muss eine ganze Reihe von Registry-Änderungen vornehmen: MD5 und RC4 deaktivieren, SSLv3, TLS 1.0 und TLS 1.1 abschalten, TLS 1.2 aktivieren, schwache Cipher raus und eine sinnvolle Cipher-Reihenfolge vorgeben. Ich habe dafür ein Registry-File vorbereitet. Herunterladen, ausführen, Server neu starten (Microsoft halt).
Download: 
Ergebnis
A+ steht. Ich hätte gerne noch schönere Cipher gehabt, aber mehr war mit diesem Setup nicht drin. Immerhin: Kein RC4, kein 3DES, kein TLS unter 1.2. Und Exchange funktioniert danach noch, was bei Microsoft-Produkten ja nie selbstverständlich ist.
Wer auch die VPN-Cipher auf dem Windows Server härten will, findet die Anleitung im Beitrag RRAS mit sicheren Cipher Suites. Fragen? Einfach melden.
Wer sich mit TLS beschäftigt, stolpert früher oder später über Zeichenketten wie TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 oder TLS_AES_256_GCM_SHA384. Was da genau drinsteht, ist auf den ersten Blick nicht offensichtlich. Dabei folgt die Benennung einem klaren Schema.
Die Bestandteile einer Cipher Suite
Jede Cipher Suite beschreibt vier Dinge:
- Key Exchange — wie sich Client und Server auf einen gemeinsamen Sitzungsschlüssel einigen.
- Certificate Verification — wie das Serverzertifikat geprüft wird (Signaturverfahren).
- Bulk Encryption — die symmetrische Verschlüsselung der eigentlichen Daten.
- Hashing — die Prüfsummen, die Integrität und Authentizität sicherstellen.
TLS 1.2 vs. TLS 1.3
In TLS 1.2 stehen alle vier Bestandteile im Namen der Cipher Suite. Nehmen wir TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 auseinander:
TLS— das Protokoll (Transport Layer Security)ECDHE— Key Exchange (Elliptic Curve Diffie-Hellman Ephemeral)ECDSA— Certificate Verification (Elliptic Curve Digital Signature Algorithm)AES_256_GCM— Bulk Encryption (AES mit 256 Bit im Galois/Counter Mode)SHA384— Hashing (SHA-2 mit 384 Bit)
TLS 1.3 hat das Namensschema verkürzt. Key Exchange und Certificate Verification sind nicht mehr Teil des Cipher-Suite-Namens, weil sie separat verhandelt werden. Darum sieht TLS_AES_256_GCM_SHA384 so kompakt aus: nur Protokoll, Verschlüsselung und Hash.
Key Exchange
Der Schlüsselaustausch legt fest, wie Client und Server einen temporären Sitzungsschlüssel aushandeln. Man will hier Ephemeral-Verfahren, also temporäre Schlüssel. Warum? Selbst wenn jemand den Traffic mitschneidet und später an den privaten Schlüssel des Servers kommt, kann er die aufgezeichneten Verbindungen nicht entschlüsseln. Der Sitzungsschlüssel existiert nur für die Dauer der Verbindung. Das nennt sich Perfect Forward Secrecy.
DHE (Diffie-Hellman Ephemeral) funktioniert, sollte aber mindestens 2048 Bit nutzen. Besser ist ECDHE (Elliptic Curve DHE), weil es bei gleicher Sicherheit deutlich kleiner und schneller ist. Idealerweise bietet der Server nur ECDHE an. Alles ohne das E am Ende (also statisches DH) hat kein Forward Secrecy und gehört abgeschaltet.
In Zukunft kommt hier noch Post-Quantum dazu. Mit X25519MLKEM768 lassen sich hybride Verfahren nutzen, die auch gegen Quantencomputer absichern. Wer das auf Nginx einrichten will, findet bei mir eine Anleitung: Post-Quantum TLS.
Certificate Verification
Verschlüsselung allein hilft nicht, wenn man mit dem falschen Server spricht. Das Serverzertifikat beweist die Identität. Es wird von einer CA signiert, kann per DANE/TLSA im DNSSEC-geschützten DNS verankert sein und sollte nicht trivial fälschbar sein.
RSA-Zertifikate sollten mindestens 2048 Bit haben, besser 4096 Bit. Allerdings werden RSA-Schlüssel mit steigender Sicherheit immer größer und langsamer. ECDSA-Zertifikate lösen das elegant: Ein ECDSA-Schlüssel mit 256 Bit bietet vergleichbare Sicherheit wie RSA mit 3072 Bit, ist aber deutlich kleiner und schneller zu verifizieren. Als Kurve sollte es mindestens secp256r1 (P-256) sein. secp384r1 geht auch, bringt aber aktuell keinen praktischen Vorteil.
Bulk Encryption
Das ist die eigentliche Datenverschlüsselung. Brauchbare Kombinationen sind:
AES-128-GCModerAES-256-GCM— Standard, schnell, hardware-beschleunigt auf den meisten CPUsChaCha20-Poly1305— gute Alternative, besonders auf Geräten ohne AES-NI
AES mit CBC ist noch akzeptabel, aber GCM ist vorzuziehen. Von 3DES sollte man die Finger lassen. Wenn irgendwo RC4 oder DES auftaucht: abschalten.
Hashing
Der Hash sichert die Integrität der übertragenen Daten. Minimum ist SHA-256, ein guter Mittelweg ist SHA-384. SHA-1 sollte man nicht mehr einsetzen. Taucht MD5 auf, stimmt etwas grundlegend nicht.
Fragen, Korrekturen oder Ergänzungen? Einfach melden.
Wenn man mit einem System im Internet steht fummelt immer irgendein script kiddie oder bot an den Diensten herum. Oft ist hier eine IP Adresse aus China dabei. Dann probieren sie ein paar default logins und wandern weiter zur nächsten IP Adresse. Die Bots geben dem Ganzen in der Regel schon nicht mehr als drei Versuche, weil sie dann eh von irgendeinem Sicherheitssystem geblockt werden. Da es noch viele andere bots hinter anderen IP Adressen gibt, übermittelt der bot nur seinen Stand der Versuche an das Hirn des Botnetzes und der nächste, nicht geblockte bot, kommt und probiert es weiter…
Alles „kalter Kaffee“… In den letzten Wochen fallen mir zwei kleine Veränderungen auf.
Einmal kommen diese IP Adressen noch immer stark aus China… ABER sehr oft ebenfalls von DigitalOcean (USA). Zudem fallen mir die anderen Cloudprovider auf (Google, Microsoft, AWS…). Das verschiebt sich aktuell wohl etwas. Normalerweise kommt ganz viel aus China, dann ganz viel von verschiedenen dynamischen Endkundenanschlüssen auf der Erde. Jetzt kommt ganz viel aus China, dann unglaublich nahe daran Digitalocean, direkt gefolgt von der google-cloud und microsoft-cloud. Erst jetzt kommen die Endkundenanschlüsse und mischen sich mit Adressen aus der AWS-Cloud. Scheinbar haben die Amazonjungs irgendetwas „besser“ gemacht, um ihre Kunden davor zu schützen sich etwas „einzufangen“?!?
Zweitens scheint da ein Botnetz mit recht alter ssh Implementierung unterwegs zu sein. Oder es sucht halt speziell alte SSH-Server? Auf IoT Geräte mit alter Firmware tippe ich weniger, denn von diesen kommt ebenfalls etwas von Cloudanbietern. Bei denen unterstelle ich einfach mal, keine alten IoT Geräte im Einsatz zu haben, die infiziert sind. Naja… Oder es wird halt nach genau solchen Geräten gesucht. Warum alt? Weil ich so etwas in den Logs finde:
Apr 8 10:35:58 YOURMOM sshd[43201]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed. Apr 8 10:35:58 YOURMOM sshd[43201]: Did not receive identification string from 1.2.3.4 port 34244 Apr 8 10:36:22 YOURMOM sshd[43202]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed. Apr 8 10:36:22 YOURMOM sshd[43202]: Unable to negotiate with 1.2.3.4 port 36160: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth] Apr 8 10:36:42 YOURMOM sshd[43204]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed. Apr 8 10:36:42 YOURMOM sshd[43204]: Unable to negotiate with 1.2.3.4 port 39556: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
Wie ist das bei euch?
Siehe auch: SSH-Server absichern mit MFA, SSH-Bruteforce, DigitalOcean und AbuseIPDB – warum Blocken das Problem nicht löst, Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi
Fragen? Einfach melden.
ECDSA-Zertifikate (Elliptic Curve Digital Signature Algorithm) bieten bei 256 Bit das gleiche Sicherheitsniveau wie RSA mit 3072 Bit. Die Schlüssel sind deutlich kleiner, der TLS-Handshake ist schneller und die Signaturen kürzer. Für Webserver ist die Umstellung trivial. Bei Mailservern gibt es eine Besonderheit: Nicht alle sendenden Server können ECDSA. Postfix löst das elegant mit Dual-Zertifikaten.
ECDSA-Schlüssel erstellen
# EC-Schlüssel mit P-256 erzeugen openssl ecparam -genkey -name prime256v1 | openssl ec -out ec-server.key # CSR erstellen (für CA-signierte Zertifikate) openssl req -new -key ec-server.key -out ec-server.csr # Oder gleich ein selbstsigniertes Zertifikat (z.B. für Tests) openssl req -new -x509 -key ec-server.key -out ec-server.pem -days 365
P-256 (prime256v1) ist die gängige Kurve. Let’s Encrypt, DigiCert und andere CAs signieren ECDSA-CSRs problemlos. Bei Let’s Encrypt/certbot: certbot certonly --key-type ecdsa.
Nginx
Beim Webserver einfach den neuen Schlüssel und das Zertifikat hinterlegen. An der Cipher-Konfiguration muss nichts geändert werden, solange ECDSA-Ciphers enthalten sind:
ssl_certificate /path/to/ec-server.pem; ssl_certificate_key /path/to/ec-server.key; ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256;
Alle modernen Browser unterstützen ECDSA seit Jahren. Probleme gibt es nur noch mit sehr alten Clients (Android 2.x, IE 6). Wer die nicht bedienen muss, kann RSA komplett aus der Cipher-Liste streichen.
Postfix: Dual-Zertifikate
Bei E-Mail sieht es anders aus. Manche Mailserver (ältere Exchange-Installationen, schlecht gewartete Systeme) können kein ECDSA. Postfix bietet dafür eine saubere Lösung: Man hinterlegt sowohl ein EC-Zertifikat als auch ein RSA-Zertifikat. Der Server bietet dem Client beide an, der Client wählt das passende.
# ECDSA (bevorzugt) smtpd_tls_eckey_file = /usr/local/etc/postfix/ec-postfix.key smtpd_tls_eccert_file = /usr/local/etc/postfix/ec-postfix.pem # RSA (Fallback) smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem
Die Cipher-Reihenfolge entscheidet, was bevorzugt wird. ECDSA-Ciphers sollten vor den RSA-Ciphers stehen. Mit tls_preempt_cipherlist = yes bestimmt der Server die Reihenfolge:
tls_preempt_cipherlist = yes tls_high_cipherlist = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
Die TLS-1.3-Ciphers (TLS_AES_*) stehen ganz vorn. Danach kommen ECDHE-ECDSA für TLS 1.2 mit EC-Zertifikat, dann ECDHE-RSA als Fallback für Clients die kein ECDSA können. Alle Ciphers haben Perfect Forward Secrecy durch ECDHE.
Dovecot
Dovecot unterstützt seit Version 2.3.15 ebenfalls mehrere Zertifikate. In 10-ssl.conf:
ssl_cert = </path/to/ec-dovecot.pem ssl_key = </path/to/ec-dovecot.key ssl_alt_cert = </path/to/rsa-dovecot.pem ssl_alt_key = </path/to/rsa-dovecot.key
Verifizieren
Im Postfix-Log erkennt man am Cipher, welches Zertifikat verwendet wurde:
# ECDSA-Verbindung TLS connection established: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 # RSA-Fallback (TLS 1.2) TLS connection established: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
Mit openssl s_client lässt sich gezielt prüfen:
# ECDSA-Zertifikat anfordern openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 2>/dev/null | grep "Server public key\|Cipher" # Ergebnis: Server public key is 256 bit (EC)
Wer den nächsten Schritt gehen will: Mit Post-Quantum-Schlüsselaustausch (X25519MLKEM768) lässt sich zusätzlich der Key Exchange gegen Quantencomputer absichern. Das Zertifikat bleibt dabei ECDSA, nur der Schlüsselaustausch wird hybrid. Und natürlich gehört zu jedem Zertifikat ein DANE/TLSA-Record im DNS. Fragen? Einfach melden.
Zufällig habe ich gesehen, dass die Suchmaschine Shodan bereits die security.txt auswertet und als Security Contact auflistet. Genau so habe ich mir das vorgestellt. https://www.shodan.io/host/148.251.40.23
Zur security.txt habe hier hier schon was geschrieben: Draft zu Security Policies
Dann steht ab jetzt der Security Contact zumindest schon mal direkt über den offenen CVEs, hm?
Siehe auch: security.txt dieses Blogs
Fragen? Einfach melden.