lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 25 Aug 2010 11:02:38 -0700
From: Tim <>
To: Holger Rabbach <>
Cc: Kari Hurtta <>,
Subject: Re: Web Tool Announcement:

> > 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 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


Powered by blists - more mailing lists