On 8/24/2016 8:30 AM, Viktor Dukhovni wrote:
> As highlighted by the recent DROWN attack, there is a potential for cross-protocol attacks
> where security of keys used in one context can be weakened or compromised by their use in
> a different context. Thus for example, one should not use the same key with both SSLv2 and
> SSLv3/TLSv1.x (though one should not really use SSLv2 at all).
>
My site requires TLSv1.2 for both https and STARTTLS. Possibly you would
recommend something less restrictive, but that seems to not cause any
problems. My site visitors are software developers that tend to use the
latest technology. I have no need to support someone using an ancient
XP-based browser.
The smtp traffic is broader based, of course, but most smtp connections
are either:
X=TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
or
X=TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128
So I conclude that mail servers are mostly up to date on encryption.
> Therefore, on port 25, I would more typically go with a self-signed cert or a private CA
> issued cert...
That is what I have gone back to.
> ...while on port 587 one might use an LE cert that is used with HTTP, provided
> both services are configured with essentially identical protocol and cipher settings
We submit email to our server solely via SSH tunnel, so have no need of
587. We don't advertise AUTH and in fact any attempt to use AUTH causes
a 24 hour all-port block of the offending IP.
> TLS in email is typically opportunistic and subject to active attacks, both
> STARTTLS stripping and DNS forgery. See:
>
> https://tools.ietf.org/html/rfc7672#section-1.3
> https://tools.ietf.org/html/rfc7435#section-4
Very interesting! Definitely leads one to consider studying DANE.
The Wikipedia article on DANE defines it as a DNS alternative to trust
of CAs based on reputation. As such, it would appear that DANE is (in
some sense) essentially a competitor to LE as a mechanism for obtaining
no-cost certificates to validate identities of server domains.
On the one hand, a fully automated scheme to provide free certificates
from a trusted CA (LE). On the other hand, a system that depends on DNS
as the trusted authority for self-generated certificates. (Of course,
browsers universally insist on the reputation-based CAs. And moisture
generally starts to appear on my forehead when confronted with openssl
syntax. <g>)
Cheers
- Phil Carroll
