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

[Randall Mason]

So the key to this discussion is that https provides two things.  First is
encryption.  That my data is only seen by me and the server I'm talking to.
This is the part that you two are talking about.  The second thing that it
does is provide identity.  That I not only know that only the person I'm
talking to is the server, but also who owns and controls the server.  This
is the part that browsers are warning you about.  I don't care as much about
encrypting my credit card as who can decrypt that information.  With self
signed certs, you need some sort of web of trust.
On Oct 28, 2011 9:40 PM, "Shawn Willden" <shawn at willden.org> wrote:

> On Fri, Oct 28, 2011 at 12:21 PM, Kevin Reid <kpreid at switchb.org> wrote:
>
>> I don't know what the browser vendors are thinking, but I can make some
>> stuff up.
>>
>
> That's always my approach when I don't know the answer :-)
>
>
>> 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...
>>
>
> I don't think "accurately displaying the URL" is important.  In the last
> few years browsers have started altering displayed URLs in all sorts of
> ways, including dropping the protocol prefix entirely in many cases.  I just
> checked and neither Firefox nor Google Chrome display http://.  Further,
> while Chrome does display https:// on SSL-enabled sites (and highlight it
> in green), FF doesn't display https:// either.
>
> Displaying the URL accurately isn't relevant to 95% (99%?) of users of the
> web.  The remainder can always figure out what they need to.
>
>
>> 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.
>
>
> Among all the ways a misconfigured web server could cause problems, I think
> this is pretty low on the list.
>
> --
> Shawn
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20111028/cacabda2/attachment-0001.html>