On 8/24/2016 2:13 AM, Jeremy Harris wrote: > On 23/08/16 20:03, Phillip Carroll wrote:
>> > Although, because of
>> > fallback to unencrypted mode, I admit I can't say for certain that it
>> > "works" in the sense of all traffic being encrypted in both directions.
When I penned the quoted remark, I mainly was thinking of the fact that
the exim logs (by default) show an "X=cipher" where encryption was used,
and not when it wasn't. however, $tls_in_cipher provides a simple basis
for studying how much of the inbound traffic is encrypted.
> For incoming, use an "encrypted = *" ACL condition.
> For outgoing, use a "hosts_require_tls = *" option on all relevant smtp
> transports.
>
Subsequent to writing the quoted remark---in light of the issues so
definitively documented by Viktor Dukhovni in various official and
unofficial writings justifying DANE---I have a substantially different
view toward smtp TLS than previous. I now understand fully why smtp TLS
is entirely a different matter than https.
As a result of this education, I could never envision using an exim
"encrypted = *" ACL condition except when combined with AUTH. (In other
words, on submission of emails by authorized users)
(a) A manual study of my recent logs reveals several hosts that send
regular emails never use TLS, despite my advertising it. For instance,
the publisher of our daily newspaper sends a daily email that is
effectively a blog containing links to key stories of the day posted in
their online version.
(b) Encryption of the type of email described in (a) is pointless
anyway. A newspaper story is hardly private, and the story selection is
not personally tailored.
(c) Encryption of only the "last hop" of a multi-hop email trip is also
pointless, DANE notwithstanding.
I view "tls_advertise_hosts = *" as a mere courtesy to those hosts
wishing to send private communications---at least insofar as it applies
to my own server.
The only guaranteed private communication is on a secure channel. Either
end to end encryption of the email itself, or more generally, use of a
VPN or equivalent. (Of course, given unlimited resources, nothing is
private.)
>
> If you're interested in observing peer certificates, look into Exim's
> Events extension and the certificate-related string expansions. You'll
> be amazed how many certs presented are non-verifiable. IMHO, after
> just getting people to make encryption available, cert verifiability
> will be the next Big Problem
DANE seems to be the only solution to that, barring a total replacement
of smtp with something else. I had thought (until DANE study) that use
of a CA-issued cert was sufficient.
But, given all the issues, I have no current interest in DANE even,
although I do see it as useful in some circumstances that don't apply to
my smtp server.
