Subject: HTTP without being HTTPS all the time

From: Mike Belshe <[email-masked]>
Date: Thu, 19 Jul 2012 10:31:38 -0700

On the heels of our discussion about "should TLS be mandatory", comes this
article from Adam Langley.

It's worth a read.

Many on this list have advocated that you don't need to secure everything,
just the login pages (common practice with HTTP today).  Read this article
and then ask yourself if that is really true.

http://www.imperialviolet.org/2012/07/19/hope9talk.html

Mixed modes of sometimes-secure-and-sometimes-not-secure open a slew of
attacks that are only solved if you're all TLS all the time.  If someone
has a better solution, let me know; I don't know of one.

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 20:49:24 +0200

Hi Mike,

> has a better solution, let me know; I don't know of one.

Thanks for the link.

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.

But this is not http vs https, it's orthogonal, in fact it's https only vs
mixed http/https. The article is clearly aimed at https-enabled sites, and
does not mean that all sites need https (it even says the opposite BTW).

Regards,
Willy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Jul 2012 15:46:39 -0400

Adam is speaking about the use of HTTP in Web browsing. There is no
question that TLS should always be on for Web browsing.

If you want to write a draft that specifies a set of required security
standards for secure Web browsing it would be very useful and I would
support TLS being a requirement for secure Web browsing (among quite a
few others). Such a standard could be really useful for use in RFPs
for outsourcing Web hosting and it does not need to be tied to HTTP
2.0 at all.

What is being discussed here is HTTP and the HTTP world is much larger
than Web Browsing. In particular there is a whole world of Web
Services where we use other security layers because those give us the
security properties we want while TLS does not. In particular there is
the WS-* stack and JSON encryption and Signature being developed right
now.

I do not want to continue this discussion here because:

1) The chair has asked us not to
2) It is a rat hole
3) The people making this proposal don't seem to want to listen when
it is pointed out that privacy and confidentiality are different
issues in the security world and that the distinction matters a lot.

On Thu, Jul 19, 2012 at 1:31 PM, Mike Belshe <[email-masked]> wrote:
> attacks that are only solved if you're all TLS all the time.  If someone has
> a better solution, let me know; I don't know of one.
>
> Mike
>

-- 
Website: http://hallambaker.com/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 20:01:35 +0000

>only some pages of a site secured is dangerous. Either the site is clear or

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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 20:04:50 +0000

In message <CAMm+LwjHypCp+Y+Qfb=[email-masked]>

>question that TLS should always be on for Web browsing.

Do you really need a bunch of card-carrying pornographers to join the
WG before you understand that it's not going to happen for 30-50% of
the web-browsing traffic ?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 20:28:58 +0000

In message <[email-masked]>, Willy Tarreau writes:

>The risk of loading insecure
>JS code during the HTTP phase which sets known cookies for the HTTPS
>phase for instance exists.

Only because cookies should never be used that way.  The only safe
cookies are signed identifying nonces, used to look up client/session
state in a database table on the server-side.

Storing information in cookies is plain wrong no matter what you are
trying to do security wise.

>for moderately complex sites, better be either all clear or all secure.

Dual-mode the way I described, seems much used in "regular"
web-commerce:  You don't need protection until you're willing to
fork over money.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 22:23:49 +0200

> That's a perfectly fair & sensible way to avoid spending resources

You got one point here. I'm used to banking environments where this
behaviour is not desirable at all. However, the points made by Adam
are perfectly valid in your example. The risk of loading insecure
JS code during the HTTP phase which sets known cookies for the HTTPS
phase for instance exists.

In 1999 I was suggesting that only the POST of a login page was made
HTTPS. Then I realized that the page handling the form had to be
secured too, and I was OK with this for a long time, until I discovered
the mess some developers are facing when trying to support multiple
browsers (including old ones), resulting in overly complex cookie or
JS policies which commonly leads to cookies slipping between secure/
non-secure or loading http contents from https. In the end, for
moderately complex sites, better be either all clear or all secure.

Note that in your example, you can have a dedicated https host for the
login phase, if you have an SSO relying on a token exchanged as a URI
parameter using a redirect, there is no problem. And I agree it's
sometimes the only solution for some of the environments where our
respective products are used together to push pixels at wire speed.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 22:54:23 +0200

> state in a database table on the server-side.

I'm precisely speaking of these ones, as they are the only I care about.
The common principle is cookie injection :
  - attacker connects to the site and gets a session cookie
  - victim connects to the site and gets another session cookie
  - victim also loads attacker-controlled JS
  - JS replaces the victim's session cookie with attacker's cookie
  - user logs in using the attacker's cookie
  - since the attacker stil has the cookie, he can access to the client's
    account

Note that there is a solution against this : have the server rebuild a new
session cookie for every change in privilege levels and every time some
form of credentials are used. I haven't seen many sites do this unfortunately,
and even worse, some PHP-based sites accept to rebuild a new session using
a user-fed PHPSESSID cookie !

> trying to do security wise.

Well, it was precisely what they were designed for initially. We could
see it differently : abusing cookies to transport user preferences is
wrong because with it comes motivation to port them wherever you can,
while they should never leave the context where they were generated.

> web-commerce:  You don't need protection until you're willing to

A lot of web sites switch to another site for the payment (bank, paypal
or even another host). I find this the safest method when you don't need
the site to be https. That way you keep an http-only site and don't have
to bother with the risk of mixing http/https information.

Willy

---

From: Mike Belshe <[email-masked]>
Date: Thu, 19 Jul 2012 14:29:50 -0700

> question that TLS should always be on for Web browsing.

Oh!

I'd be happy with this compromise.

Mike

> has

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 19 Jul 2012 14:38:58 -0700

+1

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Jul 2012 15:48:42 -0600

On 7/19/12 3:29 PM, Mike Belshe wrote:
> 
> 
> On Thu, Jul 19, 2012 at 12:46 PM, Phillip Hallam-Baker <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

At the protocol level, there is no such thing as web browsing vs. web
services, there's just HTTP. Jeff Hodges likes to talk about web
applications. [1] Sure, you want your banking app to be TLS-protected
with HSTS and so on. For visiting your friend's website of cat pictures,
not so much. They're both "web browsing", but the use cases are totally
different. Why would we treat them the same? And how are they
fundamentally different from web services?

Peter

[1] https://datatracker.ietf.org/doc/draft-hodges-websec-framework-reqs/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 22:30:24 +0000

>The common principle is cookie injection :
[...]

>Note that there is a solution against this : [...]

The solution I propose is that the user-agent builds a session-identifier
nonce which should not even be accessible or visible to the javascript
or other content, since it is exactly what it says: a session-id.

I think that would also solve the problem.

>A lot of web sites switch to another site for the payment [...]

Yes, but I'm also seeing sites that switch to HTTPS the moment
you put something in your shopping cart.

Either way, I don't buy the "everything will be better with HTTPS
all the time", for the simple reason that 30-50% of the HTTP
traffic will stay on HTTP/1.0 if we do so.

---

From: Adam Barth <[email-masked]>
Date: Thu, 19 Jul 2012 17:24:37 -0700

On Thu, Jul 19, 2012 at 2:48 PM, Peter Saint-Andre <[email-masked]> wrote:
> different. Why would we treat them the same?

Mostly because of economies of scale.  We could build entirely
different browsers, protocols, and technologies for banking and for
cat pictures, but there's a lot of value in using the same primitives
for both.  There's a cost in the sense that neither gets exactly the
stack they would have built for themselves, but the benefits of using
commodity infrastructure outweigh those costs.

> And how are they fundamentally different from web services?

Mostly in that they're accessed via web browsers and browser vendors
compete on offering the best security.  It's one of the top things
users care about in choosing a browser, along with speed and
compatibility.

Adam

---

From: Werner Baumann <[email-masked]>
Date: Fri, 20 Jul 2012 09:36:39 +0200

Am Thu, 19 Jul 2012 20:01:35 +0000
schrieb "Poul-Henning Kamp" <[email-masked]>:

> >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.
> 

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).

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).

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

---

From: Henry Story <[email-masked]>
Date: Fri, 20 Jul 2012 09:53:20 +0200

>> That's a perfectly fair & sensible way to avoid spending resources

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.  

> not restricted to HTTP-sites they may be in HTTPS-sites as well (and

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. 

> user. No way around. Technical means can only assist (and should

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. 

> consequent and offer a link on their HTTP-site as well.

Social Web Architect
http://bblfish.net/