RE: Slightly off topic - summary of problems with SSL from dotCrime Manifesto

 

> [mailto:public-wsc-wg-request@w3.org] On Behalf Of Close, Tyler J.
> Sent: Thursday, December 14, 2006 1:22 PM

> Hi Phillip, 
> 
> Hallam-Baker, Phillip wrote:
> > In particular the user should not be warned about administrative 
> > security defects. This might sound counterintuitive. What 
> is the point 
> > of having security if the user is not told when it fails? 
> But in the 
> > Web today the majority of Web sites have no security at all. Adding 
> > security measures should never reduce the quality of the user 
> > experience.
> >
> > Instead of warning the user that the site certificate is 
> invalid the 
> > browser should display the site in the same manner as any other 
> > insecure page. That is the browser should not display the padlock 
> > icon.
> 
> I very much wish the above approach were technically 
> feasible; unfortunately, there are some complications. The 
> problem is that the initial GET request potentially contains 
> a lot of sensitive information that should not be revealed to 
> the server if the server is an imposter.

But the GET request would hit the server anyway if https was not used.

Perhaps the rubric should be that a warning is displayed if the user types in https:// but not if they simply navigate to a link or the upgrade takes place transparently.


> For example, consider the URL
> https://www.example.com/?jsessionid=ASDFASDFASDF, where there 
> exists a www.example.com web site with a valid CA certified 
> certificate. Consider the case where the user's browser 
> connects to the Internet through a rogue wireless access 
> point and so is directed to a spoof of the www.example.com 
> web site which presents a self-signed certificate. If the 
> browser proceeds with the GET request anyways, the spoof site 
> will receive the user's URL encoded sesssion id, as well as 
> any cookies set up by the real www.example.com web site. At 
> that point, the phishing attack has succeeded.

I am not sure I follow the attack but I think that a large part of the problem here comes from the phrase 'wireless network'.

What this would mean is a change to the application implementation of the cookie storage so that cookies retrieved over a secure connection are linked to the SSL certificate used. 

I agree that there is an issue but I am pretty sure it is an existing one that needs fixing anyway.

Regardless my thesis is that the user is king and that the browser providers are there to serve her.


> So unfortunately, I think the current browser behaviour of 
> making an HTTPS web site with an invalid, or self-signed, 
> certificate less usable than an HTTP web site is inescapable. 
> It's terribly counter-intuitive and works against the 
> deployment of SSL, but I don't see how to fix it without 
> making protocol changes. The one saving grace is the advent 
> of domain-validated certificates, which reduce the cost of 
> deploying SSL.

True and they provide an excellent stopgap for DNSSEC.

Received on Thursday, 14 December 2006 20:11:46 UTC