Git/email-toolbox-wiki
1
0
Fork 0
mirror of https://github.com/internetstandards/toolbox-wiki.git synced 2024-11-21 18:41:36 +01:00
Code Issues Packages Projects Releases Wiki Activity

Fixup review comments

Browse Source
This commit is contained in:
Viktor Dukhovni 2019-06-28 20:16:22 -04:00
parent 349e82b826
commit 5a3fb4ab53
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
DANE-for-SMTP-how-to.md
View File

@ -43,9 +43,9 @@ DANE is designed to work with any TLS service, not just email, but DANE for HTTP
# Why use DANE for SMTP? # Why use DANE for SMTP?
The use of opportunistic TLS (via STARTTLS) is not without risks: 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. * 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). * 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)).
- It was unclear which CAs to trust to validate the certificate for a given destination. - It was unclear which CAs to trust when validating the certificate for a given destination.
- As a result of MX indirection, it was unclear which names to verify in the certificate. - In MTA-to-MTA SMTP, server hostnames for the destination domain are obtained indirectly via DNS MX loookups, but, without DNSSEC, these names cannot be trusted. As a result, it was unclear which names to verify in the certificate.
* As as result, even when STARTTLS is used, a man in the middle attacker can intercept the traffic with any certificate of his choice. * As as result, even when STARTTLS is used, a man in the middle attacker can intercept the traffic with any certificate of his choice.
DANE addresses these shortcomings because: DANE addresses these shortcomings because: