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

Randall Mason 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.
>>>
>>> --
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20111028/8ca8f4ed/attachment.html>


More information about the tahoe-dev mailing list