bugtraq - Re: Web Tool Announcement: ismymailsecure.com

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 linux-cve-announce 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