[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100825180238.GQ2109@sentinelchicken.org>
Date: Wed, 25 Aug 2010 11:02:38 -0700
From: Tim <tim-security@...tinelchicken.org>
To: Holger Rabbach <hrabbach@...ssroad-networks.com>
Cc: Kari Hurtta <hurtta+bugtraq@...ja.mh.fmi.fi>,
bugtraq@...urityfocus.com
Subject: Re: Web Tool Announcement: ismymailsecure.com
> > And because mail server name and email address does not need to be any
> > connection also checking of signature of certificate agaist CA does not
> > help much. It does not protect attack agaist MX records on DNS.
>
> true - so in an ideal world, we would need DNSSec everywhere and strict
> certificate checking to significantly reduce the possibility of MiTM
> attacks. In a not so ideal world, every little bit helps, so if we can
> get mail servers to routinely use encryption between each other, that's
> a nice first step and using valid certificates that can actually be
> verified is a second one. Both will help significantly already.
Kari is correct in that server to server SMTP is not protected
*at all* with STARTTLS unless server administrators manually configure
them to say "anything at example.com must support STARTTLS". That is,
unless DNSSEC is used for that domain.
For client to server SMTP, some smart MUAs will detect STARTTLS the
first time they connect to the server and then from that point on
require it and will store the host's name for certificate validate
(i.e. not rely on MX), so in this case there are already work arounds.
Many MUAs are pretty terrible though, and don't do this. For
instance, if you configure Outlook in "auto" mode, it will be
vulnerable to MitM every time.
I would argue that if server admins and MUAs don't do all of these
things, however, there is no "significant" improvement in
communications security. It's either possible to read some one else's
mail on the wire, or it's not. (We often like to think that security
is a continuum of being more or less secure based on level of effort,
but in many cases that's simply not true. You're either vulnerable to
an issue or you're not.)
It's unfortunate that STARTTLS is currently a disaster to configure
securely, particularly because it is just a point-to-point encryption
mechanism and all of this complexity has to be addressed at every hop.
I think as a security community we'd be a lot better off putting our
efforts into encouraging end-to-end encryption with S/MIME or
PGP/MIME.
tim
Powered by blists - more mailing lists