Sicherer E-Mail-Dienste-Anbieter (DNSSec+DANE) How-To slides

Gunnar Haslinger | Sicherer E-Mail-Dienste-Anbieter basierend auf DNSSec & DANE 1
Sicherer E-Mail-Dienste-Anbieter
basierend auf
Domain Name System Security Extension (DNSSec)
&
DNS-based Authentication of Named Entities (DANE)

Aufgabenstellung
• Gesicherte DNS-Abfragen (DNSSec)
• Vertrauenswürdige Zertifikate
• Sichere Kryptographie
• Obligatorische Verschlüsselung (DANE/TLSA)

E-Mail: DNS-Cache-Poisoning und Umleitungsangriffe

E-Mail: Downgrade Angriffe, MITM

• Baut auf DNSSec auf und nutzt TLSA Records (Transport Layer Security RR)
• Pinning von Zertifikaten oder Public-Keys (mittels TLSA-Records)
• DNSSec bietet zwei Varianten von Authenticated Denial of Existence
• Unterbindet Man-in-the-Middle und Klartext-Downgrade

DNS & DNSSec

DNS Angriffspunkte

DNSSec – DNS Security Extension
• Integritätsschutz
• Asymmetrische Kryptographie
• RSA Signaturen
• SHA2 Hashes
• Neue Resource-Record-Typen
RRSIG Signature Resource Record
enthält die kryptographische Signatur zu einem Record
DNSKEY DNS Key Resource Record
enthält den Public Key, wird von Resolver zur Signatur-Verifikation genutzt
DS Delegation Signer Resource Record (in der darüber liegenden Parent-Zone)
enthält den Hash eines DNSKEY (typischerweise des Key Signing Keys)

DNSSec – Zusammenwirken der Einträge
RRSIG Signature Resource Record
enthält kryptographische
Signatur zu einem Record
DNSKEY DNS Key Resource Record
enthält Public Key, Resolver nutzt
diesen zur Signatur-Verifikation
DS Delegation Signer Resource Record
enthält den Hash eines DNSKEY
der die Sub-Domain signiert
Domain
Owner
it-sec.ovh
Zone Signing Key
{ZSK: private-Key}
Key Signing Key
{KSK: private-Key}
Zonendatei: IT-Sec.ovh
it-sec.ovh. DNSKEY <KSK>
it-sec.ovh. DNSKEY <ZSK>
it-sec.ovh. RRSIG ...Signatur
www.it-sec.ovh. A 104.46.42.66
www.it-sec.ovh. RRSIG ...Signatur
Zonendatei: .ovh
ovh. DNSKEY <KSK>
ovh. DNSKEY <ZSK>
ovh. RRSIG ...Signatur...
it-sec.ovh. NS ns1.it-sec.ovh
it-sec.ovh. NS ns2.it-sec.ovh
it-sec.ovh. RRSIG ...Signatur
it-sec.ovh. DS <HASH KSK>
it-sec.ovh. RRSIG ...Signatur...
signiert
signiert
verweist auf
TLD: .ovh
Domain
Owner
Zone Signing Key
{ZSK: private-Key}
Key Signing Key
{KSK: private-Key}
signiert
signiert
signiert

Beispiel: mail.it-sec.ovh
Analyse mit dnsviz.net
• URL: http://dnsviz.net/d/mail.it-sec.ovh/dnssec/
• Hash-Funktion: SHA256
• Key-Signing-Keys: RSA 2048
• Zone-Signing-Keys: RSA 1024

Beispiel: DNSSec Query

DNS – Unterdrückung von Records (z.B. TLSA, …)
• DNS Request ohne Antwort -> NXDOMAIN
• Was wenn jemand absichtlich Antwort unterdrückt? –> DNSSec deckt das auf!

Authenticated Denial of Existence: NSEC
• NXDOMAIN – Die angefragte Domain / angefragter Eintrag existiert nicht
• NSEC Records = Next Secure, bilden verkettete Liste
• Zone: it-sec.ovh

NSEC – Zone Walking
• Problem: Zone-Walking möglich – egal?

Authenticated Denial of Existence
• Problem: Zone-Walking, z.B. in der Zone .at oder der Zone .br
• NSEC3 = Next Secure v3 oder NSEC Hashed Autenticated Denial of Existence
• Anstatt im Klartext lesbarer NSEC Einträge werden Hashes verwendet
NSEC Next Secure Resource Record
NSEC3 Next Secure v3 (oder NSEC Hash) Resource Record
NSEC3PARAM NSEC3 Parameter

NSEC Hashed Autenticated Denial of Existence

DNSSec - Aktivierung
• DNSSec fast 10 Jahre alt, alle gängigen BIND-Versionen geeignet
• Neue Bind-Version (z.B. v9.9.x) jedoch deutlich komfortabler
• BIND als iterativer Resolver
• beherrscht DNSSec
• Konfiguration (aktivieren) genügt
• ROOT-Key im Paket
• BIND als autoritativer Nameserver für Zone

DNSSec Resolver
• do Flag (DNSec unterstützt)
• ad Flag – Authenticated Data
• NOERROR
(Fehlschlag wäre: SERVFAIL)
• RRSIG Signature RR
• 5 = RSA/SHA1
(8 = RSA/SHA256)
• Ablaufdatum Signatur
• Signaturzeitpunkt
• 6003 = DNSKey Key-Tag

DNSSec fähiger autoritativer Server
• Inline-Signing Modus für automatisierten DNSSec-Betrieb
• Vom Admin verwaltete Zonen-Files ohne RRSIG, DNSKEY, NSEC, NSEC3 Einträge
• dnssec-keygen für Generierung von Key-Signing-Keys und Zone-Signing-Keys

DNSSec fähiger autoritativer Server, Zonen-Konfig
• Key-Directory
• Inline-Signing
• maintain -> auto KeyChange
• Zone-Transfer (AXFR) zu den Secondary Nameservern
• Mittels Transaction Signatures (TSIG) per shared Secret abgesichert
• beinhaltet alle DNSSec Einträge
• Am Secondary daher kein Schlüsselmaterial
• Hidden Master möglich

DNS Zonen-Einträge

DNS Zone
• Binärfile
• .signed
• RRSIG
• DNSKEY
• NSEC3
• NSEC3PARAM

Re-Signing, Schlüsselwechsel
• Signatur der Zonen-Einträge: Default 30 Tage gültig, Re-Signing alle 7½ Tage
Konfiguration mittels sig-validity-interval
• Auto-DNSSec maintain:
• Key-Verzeichnis wird überwacht, ZSK-Schlüsselwechsel (halb)automatisch
• Ablaufdatum
festlegen
• Successor
erstellen

Beispiel: Wechsel des Zone Signing Key (ZSK)

DNSSec - Aktivierung
• Erzeugung Schlüssel, Signatur der Zone, Replikation auf sekundäre Server
• Eintragung des KSK in der darüber liegenden Zone mittels Domain-Registrar

Best Practise und Learnings
• Inline-Signing und automatisches Key-Maintaining nutzen
• RSA / SHA256 nutzen
• RSA verpflichtend unterstützt
• DSA möglich, nicht Pflicht, nutzt niemand
• ECDSA – im Kommen, Unterstützung noch nicht breit genug
• SHA256 breit unterstützt, SHA1 wird ausgephast
• ZSK: 1024 bit -> kurze Signaturen, nicht langfristig sicher, NIST: 1 Jahr
• KSK: 2048 bit -> ausreichend sicher für ein paar Jahre, NIST: 5 Jahre
• KeyGen: Entropie nötig! Auf vServern HAVEGED nötig!
Hardware Volatile Entropy Gathering and Expansion Daemon

DNS-Check
• mxtoolbox.com
• Allgemeiner DNS-Check

DNSSec-Check
• dnscheck.iis.se
• Summary

DNSSec-Check
• dnscheck.iis.se
• Details

DNSSec-Debugger
• dnssec-debugger.verisignlabs.com

Analyse mit dnsviz.net
• Grafische Darstellung
• Zeigt Zone-Delgation
• Grafische Veranschaulichung
der Key-/Trust-Hierarchie

DANE

Rückblick: SMTP Transport, Angriffe
• Umlenkung, MITM, Downgrade,

• Existenz des
TLSA-Records
und NSEC/NSEC3
verhindern Downgrade
• Inhalt des TLSA-Records
pinnt Zertifikate
oder pinnt CAs
oder pinnt PublicKeys

DANE baut auf TLS auf -> benötigt Zertifikate
• Könnten Self-Signed sein
• Jedoch besser aus getrusteter CA, da DANE noch Nischen-Technologie
• Kostenfrei Domain-Validated (DV) TLS-Server Zertifikate:
• StartCom Ltd.: https://www.startssl.com/
• ISRG (Internet Security Research Group) & Mozilla: https://letsencrypt.org/
• WoSign: https://www.wosign.com/english/freeSSL.htm

Zertifikat ausstellen:
Typische Vorgangsweise
• RSA Schlüsselpaar generieren
• CSR erstellen
• CSR an CA übermitteln
• Zertifikat erhalten
• Zertifikat + CertChain installieren

Alternative:
• Automatisierter DV-Vorgang
• Python Client
• Zertifikatserneuerung
vollautomatisch alle 60 Tage
• CSR-Nutzung möglich
-> Schlüsselpaar kann gleich bleiben

TLSA Record für DANE Transport Layer Security Protocol
• DNSSec Voraussetzung
• TLSA RR
• Pinning
• Zertifikat oder CA
• Zertifikats-Hash
• oder PubKey-Hash

DANE: PubKey Hash -> TLSA Record
• Im Zonen-File der Domain wird ein TLSA-Record ergänzt

Absicherung: SMTP, HTTPS, IMAPS, POP3S
Preisfrage: Warum Hash überall gleich?

Komfortable Alternative: TLSA Record Generator

Zertifikatswechsel – Erneuerung der TLSA-Records?
• Wenn gleiches Schlüsselpaar (CSR) weiterverwendet wird nicht nötig
• Ansonsten: TTL beachten, Gültigkeitszeitraum im Auge behalten
• Mehrere TLSA Records parallel für gültig erklären (Überlappender Zeitraum)
• Let‘s Encrypt: Nicht den Default-Automatismus nutzen, sondern CSR

Prüfung TLSA-Record
• Check mit: dane.sys4.de
• Check mit dig
• Mehr Checks später (MailServer)

Mailserver MTA, LDA, MDA, Anbindung MUA, WebMail,

• CentOS 7.2
• Debian 8.2
• BIND 9.9.4 / 9.9.5
• Postfix 2.11.3
• Dovecot 2.2
• Apache 2.4.10
• PHP 5.6.13
• MySQL 5.5.46
• RoundCube 1.1.3
Realisierung

Mailserver mit DANE – Alternativen?
• Postfix 2.11 erst ab Debian 8 bzw. Ubuntu 14.04 LTS verfügbar
< 2.11 unter RHEL, CentOS, SLES,
evtl. (zuverlässige) Drittanbieter-Pakete nutzen?!
• EXIM ab v4.85
Weder in Debian noch Ubuntu LTS noch CentOS noch SLES verfügbar
• SendMail – aktuelle 8.15.2 immer noch kein DANE
• Microsoft Exchange – kein DANE
Drittanbieter-Erweiterung: CryptoFilter

Postfix-Konfiguration
• Allgemein: Mailserver-Konfiguration grundsätzlich (beim ersten mal) knifflig
• Zertifikat + Chain konfigurieren
• SSL/TLS konfigurieren – für MTA: Default-Config (Cipher)
schlechte Crypto besser als gar keine Krypto (Plaintext-Fallback)
• Submission-Port: Mandatory TLS, nur „gute“ Cipher-Suiten erlaubt
• Authentifizierung nur mit STARTTLS und am Submission-Port zulassen
• DANE: straight forward

Verbreitung von TLS und DANE bei MTA‘s
• TLS: siehe z.B.:
Google Transparency
Report
• DANE:
Starker Trend in .de
Dzt. aber nur vereinzelt
• Mail.de, posteo.de
+ viele Ankündigungen!

Mailserver-Studie: SSL / TLS-Protokollversionen

Mailserver-Studie: Cipher-Suite Unterstützung

Mailserver-Studie: eingesetzte Zertifikate
• ssc = self signed Cert
• local = unbekannte CA
• ssc chain = CertChain fehlt

Dovecot: POP3 & IMAP
• Setup straight forward
• Zertifikat konfigurieren
• Nur TLS zulassen, Cipher-String gemäß BetterCrypto.org „CipherString B“
• Dovecot stellt SASL (Simple Authentication and Security Layer) für Postfix bereit

Mailserver-Checks
• Basis-Check: MxToolbox.com
• Versand & Empfang:
CheckTLS.com
• Detailierte Analyse per Reply-Mail

CheckTLS.com
Mail-Empfang
Check

OpenSSL
s_client -starttls

Prüfung: DH-Parameter, 2048bit ?

DANE-Check
• PostTLS-Finger
• Mail-Empfangs-
Check

DANE-Empfangs-Check: dane.sys4.de

weitere Details
dane.sys4.de

Mailserver Check: Versand mit DANE
• Gegenstelle mit DANE Unterstützung erforderlich, z.B.: posteo.de

IMAPS, POP3S Test

TestSSL.sh Script

Web-Mail
Apache, PHP, MySQL, RoundCube WebMail

Plattform: LAMP-Stack auf Debian 8.2
• Apache 2.4.10
• Mod SSL
• Mod Headers
• Mod Rewrite
•
• PHP 5.6.13
• MySQL 5.5.46

Apache: SSL-Konfiguration
• Cipher-String: Anlehnung an BetterCrypto.org, jedoch selbst gebaut
• Inkonsistenzen im BetterCrypto-Guide „CipherString B“ aufgedeckt
• Zertifikat + Chain konfiguriert
• OCSP-Stapling aktiviert
• HTTP Strict Transport Security (HSTS)
• HTTP Public Key Pinning (HPKP) – Kapitel (von mir) nun in BetterCrypto enthalten

Apache
vHost
SSL
Config

Cipher-Suite: BetterCrypto „CipherString B“
• Enthält Camellia
• Priorisiert DH gegenüber ECDH
• Präferiert AES256 gegenüber AES128
• Unterstützt keine Java 1.7 Clients
• Ist sehr lang:
• Mein Cipher-String:

Client
Kompatibilität
Test mit
Qualys SSL Labs

OCSP
Stapling
Online Certificate
Status Protocol (OCSP)
Response im TLS-Handshake

HTTP Strict Transport Security (HSTS)
• Sorgt für das „+“ beim SSLLabs.com WebServer TLS-Check

HTTP Public Key Pinning (HPKP) als Ergänzung zu DANE
• DANE für WebSites (HTTPS) möglich aber nicht gebräuchlich
• Trust on First Use (TOFU) Prinzip
• Base64 encodierter Hash des Public-Key des Zertifikates
• Cert PubKey-Pinning
• CA PubKey Pinning
• Reserve-Key!

HTTP Public Key Pinning – Hash erzeugen
• OpenSSL
• WebService
https://report-uri.io

Prüfung:
HTTP Key Pinning

RoundCube Webmail
• Download (Sourcen) von SourceForce (kein Paket für Debian 8.2 im Repo)
• Einrichtung mit Web-Installer gemäß Doku
• Greift über LocalHost auf IMAP zu
• Versand: Nutzt Postfix über LocalHost
• Adressbuch & User-Settings: mySQL-DB
• Straight Forward, siehe Doku

RoundCube
WebMail

Checks:
Qualys SSL Labs
SSLLabs.com

Qualys
SSL Labs
• Server-Zertifikat
• 4096bit RSA
• SHA256
• OCSP verfügbar

Qualys SSL Labs
• Protokolle
• Cipher Suites

Qualys SSL Labs
• Protokoll Details
• OCSP Stapling aktiviert
• HTTP Strict Transport Security
• HTTP Public Key Pinning
• Sichere Cipher-Suiten
• Nur TLS, kein SSL aktiv
•

A-Sit
Firefox PlugIn

SIDN Labs
HTTPS
DANE Check

DNSSec
&
DANE
Validator
PlugIn

Sicherer E-Mail-Dienste-Anbieter
basierend auf
Domain Name System Security Extension (DNSSec)
&
Paper als Download (PDF): https://hitco.at/blog
https://hitco.at/blog/sicherer-e-mail-dienste-anbieter-dnssec-dane/

Quellen
• Abbildungen siehe Abbildungsverzeichnis sowie Literaturverzeichnis
im zugehörigen Dokument:
„Sicherer E-Mail-Dienste-Anbieter (DNSSec+DANE) HowTo.pdf“
Besonderer Dank an:
• SBA Research, insbesondere Aaron Zauner
• Heise-Verlag
• BetterCrypto.org
• Acidx‘s Blog – Markus Klein
• University Amsterdam
• Und allen anderen Quellen (siehe o.a. Dokument)

Sicherer E-Mail-Dienste-Anbieter (DNSSec+DANE) How-To slides

Weitere ähnliche Inhalte

Empfohlen (20)

Sicherer E-Mail-Dienste-Anbieter (DNSSec+DANE) How-To slides