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

[Shawn Willden]

How do you have a false sense of security if the browser displays the two
bottom levels exactly the same, as in, the user has no way to tell the
difference without digging into page info?

Note what I already mentioned about Firefox -- you can't "look for https"
because it's not even displayed.  What you should look for is the lock icon,
which clearly should not be displayed for self-signed certs.

On Fri, Oct 28, 2011 at 2:03 PM, Randall Mason <clashthebunny at gmail.com>wrote:

> 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.
>>>>
>>>> --
>>>> Shawn
>>>>
>>>> _______________________________________________
>>>> tahoe-dev mailing list
>>>> tahoe-dev at tahoe-lafs.org
>>>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>>>
>>>>
>>> _______________________________________________
>>> tahoe-dev mailing list
>>> tahoe-dev at tahoe-lafs.org
>>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>>
>>>
>>
>>
>> --
>> Shawn
>>
>> _______________________________________________
>> tahoe-dev mailing list
>> tahoe-dev at tahoe-lafs.org
>> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>>
>>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>


-- 
Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20111028/c694252c/attachment-0001.html>