[tahoe-dev] SSL samurai attack migration ninjas, film at 11
Shawn Willden
shawn at willden.org
Fri Oct 28 18:40:30 UTC 2011
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20111028/e6dede78/attachment.html>
More information about the tahoe-dev
mailing list