[tahoe-dev] SSL samurai attack migration ninjas, film at 11
clashthebunny at gmail.com
Fri Oct 28 20:03:49 UTC 2011
most - Encrypted and authenticated
least - Encrypted and unauthenticated
middle - Unencrypted and unauthenticated
I would say that a false sense of security is worse than a real sense of
insecurity. Most people are black and white thinkers and if they are
constantly told "look for https", you give them a false sense of security.
On Oct 28, 2011 10:48 PM, "Shawn Willden" <shawn at willden.org> wrote:
> 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
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tahoe-dev