[tahoe-dev] SSL samurai attack migration ninjas, film at 11
shawn at willden.org
Fri Oct 28 19:47:49 UTC 2011
Yes, yes, but that doesn't explain why browsers treat encrypted but
unauthenticated connections as *less* secure that connections that are
unencrypted *and* unauthenticated.
If you were asked to rank the security of the following:
Encrypted and authenticated
Encrypted and unauthenticated
Unencrypted and unauthenticated
How would you order them? How do browsers order them?
On Fri, Oct 28, 2011 at 1:19 PM, Randall Mason <clashthebunny at gmail.com>wrote:
> 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.
>> tahoe-dev mailing list
>> tahoe-dev at tahoe-lafs.org
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tahoe-dev