mirror of
https://github.com/internetstandards/toolbox-wiki.git
synced 2024-12-22 17:45:06 +01:00
Update DANE-for-SMTP-how-to.md
This commit is contained in:
parent
53a1c70e78
commit
e3c510cfa9
@ -57,6 +57,8 @@ DANE is short for "**D**NS-based **A**uthentication of **N**amed **E**ntities" a
|
||||
DANE is designed to work with any TLS service, not just email, but DANE for HTTP is not presently supported by the major browsers and so has seen little deployment. DANE for SMTP (which is described in [RFC 7672](https://tools.ietf.org/html/rfc7672) on the other hand, is used increasingly and adds active attack (man-in-the-middle) resistance to SMTP transport encryption [RFC 7672 Section 1.3](https://tools.ietf.org/rfc7672#section-1.3). DANE for SMTP uses the presence of DANE TLSA records to securely signal TLS support and to publish the means by which SMTP clients can successfully authenticate legitimate SMTP servers. The result is called "opportunistic DANE TLS", and resists downgrade and man-in-the-middle (MITM) attacks when the destination domain and its MX hosts are DNSSEC signed, and TLSA records are published for each MX host.
|
||||
|
||||
# Why use DANE for SMTP?
|
||||
DANE offers several advantages by binding X.509 certificates to domains using DNSSEC. In an SMTP context this allows sending e-mail servers to verify the autenticity of the offered certificate by the receiving domain's e-mail server. This helps to address risks that occur when using TLS connections between e-mail servers.
|
||||
|
||||
The use of opportunistic TLS (via STARTTLS) is not without risks:
|
||||
* Because forcing the use of TLS for all mail servers would break backwards compatibility, SMTP uses opportunistic TLS (via STARTTLS) as a mechanism to enable secure transport between mail servers. However, the fact that STARTTLS is opportunistic means that the initial connection from one mail server to another always starts unencrypted making it vulnerable to man in the middle attacks. If a mail server does not offer the 'STARTTLS capability' during the SMTP handshake (because it was stripped by an attacker), transport of mail occurs over an unencrypted connection.
|
||||
* By default mail servers do not validate the authenticity of another mail server's certificate; any random certificate is accepted (see [RFC 3207](https://tools.ietf.org/html/rfc3207)).
|
||||
|
Loading…
Reference in New Issue
Block a user