[tahoe-dev] SSL samurai attack migration ninjas, film at 11

[James A. Donald]

On 2011-10-29 4:21 AM, Kevin Reid wrote:
> On Oct 28, 2011, at 14:05, Shawn Willden wrote:
>
>> OT:  Does anyone else think it's crazy that web browsers flash huge red warning signs when they see a self-signed cert, as though that's a clear indication of some sort of attack being attempted, which is almost never the case?
>>
>> It's always seemed to me than an appropriate browser response to a self-signed cert is to accept it and use it to establish an encrypted session, but not to display the lock icon or anything else that would make the user think this page is especially secure.  For bonus points, browsers could implement ssh-style notification of server key changes.
>>
>> But the sort of big scary warnings browsers now display makes no sense to me.
>
>
> I don't know what the browser vendors are thinking, but I can make some stuff up.
>
>
> Argument #1:
>
>    Premise 1: "https:" means it's secure, to the user.
>
>    Premise 2: HTTPS security rests on the CAs providing certificates
>               for DNS names.
>
>    Conclusion: If a certificate is not signed-by-a-CA-etc. then the user
>                thinks they are secure but aren't; therefore warn them.
>
> Not showing indicators of security to the user solves this problem, but if you hide "https:" then you're not accurately displaying the URL...

Show https, but show the name on the certificate and the padlock icon 
if, and only if, the certificate is signed by a CA.

> Argument #2:
>
>    If the author of a *link* wrote "https:" then they expect that link
>    to securely designate the intended target; if there is a certificate
>    problem then the link is not succeeding at that job and proceeding
>    despite that would be a vulnerability.
 >
 > For this concern, changing the UI doesn't help: the only thing that
 > would be better than trustworthy CAs would be including key
 > fingerprints in the links.

Exactly so.  We need the ability to include key fingerprints in the links.

Allow the author of the link to designate the hash of the certificate 
root.  <a href="http://example.com, 
root="p4XzhuKAp/fp7Jbu18VHmf5Qod6twbgKCsLGgJe3hr">

This prevents state level attacks.