Re: HTTP without being HTTPS all the time

On 20 Jul 2012, at 09:36, Werner Baumann wrote:

> Am Thu, 19 Jul 2012 20:01:35 +0000
> schrieb "Poul-Henning Kamp" <phk@phk.freebsd.dk>:
> 
>> In message <20120719184924.GM16208@1wt.eu>, Willy Tarreau writes:
>> 
>>> As usual, Adam gave a nice description there, and I'm sure many of
>>> us are aware of the issues he describes. I'm among those who
>>> consider that having only some pages of a site secured is dangerous.
>>> Either the site is clear or it's not.
>> 
>> What about sites that are HTTP until you log in, then switch to
>> HTTPS ?
>> 
>> That's a perfectly fair & sensible way to avoid spending resources
>> on non-paying visitors.
>> 

Not at all. If you have part of your site that is on http, those parts
of your site could be man in the middle attacked, so that once you reach
click on the login button, you end up on a different - though similarly
named site, or simply the login procedure has been altered. Without HTTPs
you cannot guarantee the integrity of what you receive. You don't even know
you are receiving it from the right site initially.  

> 
> Looking at Adam's example: the problem is not mixing of HTTP and HTTPS.
> The error happens when the user follows a non-trustworthy link and then
> believes it to be secure because its HTTPS. These dangerous links are
> not restricted to HTTP-sites they may be in HTTPS-sites as well (and
> other places).

yes, because the HTTP site could be man in the middled and so the person
end up on an httpS site that is run by a different agent. And indeed just
looking at the HTTPS icon is not enough. You may indeed be correctly 
connected to the thief's web site. If you think you were still on the original
site then you are mistaken. 

> 
> There is only one way to defend against this: the *user* must verify,
> and be able to verify, that the HTTPS-url is the one she wants. The
> first step in user security is always the informed decision by the
> user. No way around. Technical means can only assist (and should
> assist and not confuse).

In fact you cannot find purely technical solutions to this. You need to find 
techno-social ones, that allow trust to be extended and confirmed by many 
different actors, where each user can choose the set of trust agents he wishes
to be guided by.

I recently put forward some ideas on how one can find technico-social solutions
to this using WebID and LinkedData

"WebID and eCommerce"
http://bblfish.net/blog/2012/04/30/

This goes beyond the scope of this WG, but that does not mean that it is not 
of interest to it. 

> 
> The current state of helping the user to make informed decisions is
> very bad. The infamous dialog on unverifyable certificates is just one
> example. Telling users they are secure because it is HTTPS or all-HTTPS
> wil make things worse.
> 
> Regarding banking: my bank advices me to type the HTTPS-url of the
> login page by hand. I think this is good advice. But they are not
> consequent and offer a link on their HTTP-site as well.
> 
> Werner
> 

Social Web Architect
http://bblfish.net/

Received on Friday, 20 July 2012 07:53:57 UTC