DANE, validate the integrity of TLS certificates
Heuristic analysis
|
Anti-relay
|
Botnet / Zombie
|
Bounce
|
Dane
|
Denial of service - DDOS
|
DKIM
|
DMARC
|
DNSSEC
|
False-negatives
|
False positives
|
Bayesian filters
|
FOVI - President's scam
|
FQDN
|
Greylisting
|
Social Engineering
|
White lists
|
DNSBl blacklists
|
Malware
|
MTA / MDA
|
Opt-in
|
Opt-out
|
Ransomware
|
Scam / Nigerian419
|
Phishing
|
SMTP
|
Spam
|
Spear phishing
|
SPF
|
StartTLS
|
Virus
|
Teergrubing
|
Turing test
|
Definition of DANE
DANE (DNS-Based Authentication of Named Entities) is a security protocol that uses the DNS system to secure online communications. It guarantees the authenticity and integrity of secure connections such as SSL/TLS connections. DANE is a standardised protocol designed to validate the certificate used in a TLS-secured connection. The machine initiating a connection will be able to retrieve the fingerprint of its correspondent’s certificate via a DNS record in order to confirm its integrity.
Why secure your SMTP servers with DANE?
Securing SMTP servers with DANE ensures that communications between mail servers are authentic and confidential. This prevents attacks such as message interception and falsification of server identities.
How is the DANE protocol used?
The DANE protocol uses specific DNS records to store information about the public keys of mail servers. Mail servers can use these records to verify that the public key presented by the remote mail server is authentic and has not been tampered with. To use the DANE protocol, you need a DANE-compatible DNS provider and a mail client that supports this protocol.
Setting up DANE means generating and maintaining an up-to-date certificate key fingerprint. It must be accessible via a TLSA record associated with the host name of the machine concerned. The DNS server managing this record must use DNSSEC to ensure the validity of the transaction and data. DANE is compatible with all communications using TLS, but is mainly used to secure exchanges between SMTP servers.
Examples
Here’s a concrete example of how DANE works when sending an e-mail from “from@exp.fr” to “to@dest.fr”:
– The exp.fr server sends a DNS request to find out the MX of dest.fr:
# dig MX dest.fr
dest.fr. 3600 IN MX 10 mail.dest.fr
– The sending server checks whether the destination server has a TLSA entry. To do this, it generates a request containing the port number (25), the protocol (TCP) and the host name:
# dig TLSA _25._tcp.mail.dest.fr
_25._tcp.mail.dest.fr. IN TLSA 3 1 1 42DDBACBE48CBB37…3D D53D2CB4
– It connects to the mail.dest.fr mail server, which transmits its public key (present in the certificate) during the TLS handshake. The sending server is then able to compare the fingerprint with the public key to verify its integrity. However, if the TLSA record is not signed by DNSSEC, or if an element is missing or incorrectly entered, the connection switches to conventional TLS.
Applications
All Altospam servers are configured to use DANE, so all our customers benefit from the protection applied to our equipment, without any modification being necessary, whatever the destination domain. However, for this to work effectively, the customer’s domain must be secured by DNSSEC.
Email is the main vector for cyberattacks
New and increasingly sophisticated attacks are being launched around the world every day. Our solution detects and neutralizes phishing, spear-phishing, malware, ransomware and spam threats in real time.
Additional information
- RFC 7672 defining DANE
- AFNIC file on DANE – Article on Greylisting and its integration into ALTOSPAM
