Status of opportunistic encryption
Victor Duchovni
Victor.Duchovni at MorganStanley.com
Mon May 29 12:03:05 EDT 2006
On Mon, May 29, 2006 at 07:21:29AM +0200, Florian Weimer wrote:
> * Sandy Harris:
>
> > Recent news stories seem to me to make it obvious that anyone with privacy
> > concerns (i.e. more-or-less everyone) should be encrypting as much of their
> > communication as possible. Implementing opportunistic encryption is the
> > best way I know of to do that for the Internet.
> >
> > I'm somewhat out of touch, though, so I do not know to what extent people
> > are using it now. That is my question here.
>
> It seems to me opportunistic encryption has moved to the application
> layer, at least as far as Internet mail is concerned. Many MTAs use
> TLS automatically with whatever certificates they can get. Of course,
> this only guards against active attacks, but it seems to me that this
> is a reasonable threat model.
It only guards against *passive* eavesdropping. Active attacks can
forge DNS MX records, inject BGP routes, ... Actual MITM resistant
peer authentication with SMTP+TLS is extremely rare. I know it happens
sometimes because I have it running for a small number of destinations,
otherwise I would suspect that nobody is doing it.
http://www.postfix.org/TLS_README.html#client_tls_harden
Once the new 2.3 TLS code is folded into the production Postfix 2.3
snapshots (at which point the new documentation will be published), see
http://www.postfix.org/TLS_README.html#client_tls_levels
http://www.postfix.org/TLS_README.html#client_tls_policy
Preview:
It is regrettably the case, that TLS secure-channels (fully authenticated
and immune to man-in-the-middle attacks) impose constraints on the sending
and receiving sites that preclude ubiquitous deployment. One needs to
manually configure this type of security for each destination domain,
and in many cases implement non-default TLS policy table entries for
additional domains hosted at a common secured destination. With Postfix
2.3, we make secure-channel configurations substantially easier to
configure, but they will never be the norm. For the generic domain with
which you have made no specific security arrangements, this security
level is not a good fit.
Historical note: while the documentation of these issues and many of
the related features are new with Postfix 2.3, the issue was well
understood before Postfix 1.0, when Lutz Jaenicke was designing
the first unofficial Postfix TLS patch. See, his original post
http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=304 and the first
response http://thread.gmane.org/gmane.ietf.apps-tls/304/focus=305. The
problem is not even unique to SMTP or even TLS, similar issues exist
for secure connections via aliases for HTTPS and Kerberos. SMTP merely
uses indirect naming (via MX records) more frequently.
I should also note that once one abandons the (still) unrealistic
assumption of a secure DNS, it is not just SMTP + TLS that runs into
trouble.
For example, many Kerberos client libraries do a forward lookup (to
alias- expand CNAMEs) and some perversely a reverse lookup (often the
owner of the IP address is the worst source of the machine's name), and
then give you a mutually authenticated channel to whatever principal
they construct from now rather questionable data. This carries over
to SASL GSSAPI, where GSSAPI abstraction makes working around this
(in practice nobody tries even with native Kerberos) even harder.
Consequently, also SSH with GSS KEX, is not MITM resistant when the
attacker can tamper with DNS responses.
Ultimately, to close similar security issues in many other protocols,
we need a secure DNS, but I am somewhat pessimistic about the likelihood
of this happening soon.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAIL Morgan Stanley confidentiality or privilege,
and use is prohibited.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list