lists.openwall.net   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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 25 Aug 2010 16:56:48 -0400 (EDT)
From: Brian Behlendorf <brian@...lendorf.com>
To: Tim <tim-security@...tinelchicken.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Web Tool Announcement: ismymailsecure.com

On Wed, 25 Aug 2010, Tim wrote:
> 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.

That's the conclusion we came to in the NHIN Direct project 
(http://nhindirect.org/, secure messaging for the health IT industry) 
though server-server TLS with agreed-upon CAs (establishing "trust 
circles") are helpful.  What TLS didn't appear to allow is negotiation of 
CAs - which ones do I trust, which ones do you have signatures from, 
what's the intersection.  That would allow it to grow more intelligently 
than the "trust this long list of root CAs" model that web browsers use. 
In our case it's useful to also encrypt the server-server link, even if 
you are S/MIME encrypting the message content, because From/To/Subject 
data can be pretty sensitive.  Seeing encrypted SSL traffic between 
suttermentalhealth.com and healthvault.com is a lot less revealing than 
From: drbob@...termentalhealth.com To: brian@...lthvault.com Subject: Are 
you taking your meds?

 	Brian

Powered by blists - more mailing lists