Subject: [HASMAT] wrt port numbers - comment 51 bug 495115 (bugzilla.mozilla.org)

From: =JeffH <[email-masked]>
Date: Fri, 16 Jul 2010 12:20:23 -0700

Comment 51    Kai Engert <[email-masked]>      2010-07-13 17:23:36 PDT
https://bugzilla.mozilla.org/show_bug.cgi?id=495115#c51

One more detail which I don't see addressed in the spec yet: port numbers!

IMHO the primary key should not be "host", but "host:port".
Also, what happens if the server choses to issue an redirect to a non-standard
port number?

The current code is hard-coded to always construct STS-host uris to the default
port (-1 = 443).

The current code will fail if a STS-host choses to redirect to

https://www.host.com:444

The current code will do funky things if there are two separate http servers
running on the same host, e.g.

- http://host.com/ (default 80)
and
- http://host.com:8080

This configuration is often used on web servers, where the default port is the
actual server, and the additional port is a web-site-maintenance interface.

Let's say www.site.com is using port 80 for the public web and is used to
redirect to 443.

www.site.com is behind a firewall and won't allow connections to ports other
than 80 and 443 from the outside world.

www.site.com has a plain http maintenance interface on port 8080.

I think with the current code, it's impossible to connect to
http://www.site.com:8080, because our http engine will always catch that
request and redirect to https://www.site.com:443/

If you want to keep it simple, and only address the standard configuration, my
proposal is:

- restrict the redirection to http requests that go to port 80

---
end

---

From: Adam Barth <[email-masked]>
Date: Fri, 16 Jul 2010 17:29:54 -0700

Here's the response I gave on the bug:

[[
With respect to port numbers, I think that's not well covered in the spec.  The
way it works in chrome is that the STS state is for the whole host (this is
important to protect secure cookies, which are shared by the whole host).  For
the redirect behavior: port numbers are preserved except port 80 is changed to
port 443 because 80 is the default port for http.
]]

> - restrict the redirection to http requests that go to port 80

That's not a good idea.  It's an importnat security property that the
browser never issues an HTTP request for hosts with STS enabled.  The
reasons for this are somewhat subtle and revolve around deficiencies
in the cookie protocol.  Essentially, because cookies do not have
integrity, you want to rule out the possibility of an active network
attacker responding to such requests with a Set-Cookie header.

Another way of thinking about the situation is as follows:

1) An STS server is promising never to use HTTP or send broken certificates.
2) If we're trying to issue an HTTP request to example.com:8080, then
that's not what example.com wants and we shouldn't do it.

Adam

On Fri, Jul 16, 2010 at 12:20 PM, =JeffH <[email-masked]> wrote:
> _______________________________________________
> HASMAT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hasmat
>

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Sat, 17 Jul 2010 09:42:23 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Adam Barth

> That's not a good idea.  It's an importnat security property that the browser
> never issues an HTTP request for hosts with STS enabled.  The reasons for
> this are somewhat subtle and revolve around deficiencies in the cookie
> protocol.  Essentially, because cookies do not have integrity, you want to rule
> out the possibility of an active network attacker responding to such requests
> with a Set-Cookie header.

It isn't just cookies though. We want to protect against all (most?) downgrade attacks essentially.  We want to stop all spoofed responses, MITM attacks, etc.  During the initial connection there is obviously a problem of sending cookies unencrypted, but you also leak what URL you are visiting, and open yourself up to spoofed responses.  
--
Andy

---

From: Adam Barth <[email-masked]>
Date: Sat, 17 Jul 2010 08:46:44 -0700

> It isn't just cookies though. We want to protect against all (most?) downgrade attacks essentially.  We want to stop all spoofed responses, MITM attacks, etc.  During the initial connection there i…

That's a good point.  Keeping the redirect internal does help keep the
URL confidential.

Adam

---

From: Devdatta Akhawe <[email-masked]>
Date: Sat, 17 Jul 2010 17:34:04 +0100

> attacker responding to such requests with a Set-Cookie header.

It seems to me that this should be fixed by STS. Would something like
'once STS is enabled a STS server shouldn't allow HTTP to set secure
cookies' (in better language) be enough? I am not really sure what are
the attacks you are referring to.

Also not clear to me whether this falls in STS charter.

~devdatta

---

From: Adam Barth <[email-masked]>
Date: Sat, 17 Jul 2010 09:38:08 -0700

> the attacks you are referring to.

That's already true because the browser never issues HTTP requests to
an STS host and therefore can never receive an HTTP response
containing a Set-Cookie header.

More generally, there are tons of random semantics we could layer onto
the STS bit.  However, that leads to a complex feature that's hard for
sites to reason about and deploy.  Instead, it's better to stick with
a couple hard-working primitives, which is what the current design
aims for.

Adam

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Sat, 17 Jul 2010 13:35:53 -0600

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Barth
 >
> That's already true because the browser never issues HTTP requests to an
> STS host and therefore can never receive an HTTP response containing a Set-
> Cookie header.
> 
> More generally, there are tons of random semantics we could layer onto the
> STS bit.  However, that leads to a complex feature that's hard for sites to
> reason about and deploy.  Instead, it's better to stick with a couple hard-
> working primitives, which is what the current design aims for.

Ok, I feel like I'm making a day of contradicting Adam, but one of the points of the HASMAT work is to see what other policy directives we can come up with, and they bestway to turn some of that into policy mechanisms.  

Lots of things are currently out there scattered all over:

X-Frame-Options
CSP
STS
No-Sniff
And even headers to turn off XSS sanitization features in browsers for a given site.

What we're hoping to do through some of the HASMAT work is condense a lot of that into a more coherent policy mechanism, and add a few things  (and I'm just brainstorming here).  Ideally these policies could be controlled in one place and wouldn't have to get set for every response by a site, they could be centrally controlled and authoritative.

 - This site only sets "Secure" and "HTTPonly" cookies. Don't pay attention to the individual cookies, this policy statement is authoritative
 - This site is always UTF-8. Don't ever sniff content here.
 - This site should never be framed, or only framed under these conditions. 

--
Andy

---

From: Adam Barth <[email-masked]>
Date: Sat, 17 Jul 2010 13:17:17 -0700

>  - This site should never be framed, or only framed under these conditions.

Oh, I agree with that.  I guess what I meant was we'd be better off
having more dials to turn, each of which does something clear and
understandable, rather than having a big on/off switch that does
something complicated and mysterious.

For example, in the original ForceHTTPS proposal, we had "I don't want
mixed content" layered on as well.  We took that out because we
thought it made sense to be able to control that piece of policy
independently.

Adam

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Sat, 17 Jul 2010 20:36:13 -0600

> From: Adam Barth [mailto:[email-masked]]

> Oh, I agree with that.  I guess what I meant was we'd be better off having
> more dials to turn, each of which does something clear and understandable,
> rather than having a big on/off switch that does something complicated and
> mysterious.
> 
> mixed content" layered on as well.  We took that out because we thought it
> made sense to be able to control that piece of policy independently.

Funny - Jeff and I had that same discussion.  Because of differences in how each browser handles "mixed content" as well as how plugins and other RIA frameworks handle it, we decided it was too tricky to solve in the first go.  

- Andy

---

From: Kai Engert <[email-masked]>
Date: Mon, 19 Jul 2010 09:49:43 +0200

> that's not what example.com wants and we shouldn't do it.

Let me try to summarize your proposed behaviour:

    * plain http is forbidden for all ports on a known HSTS host
      (it's not possible to run any additional http services on a known
      HSTS host, because HSTS-compliant browsers are expected to never
      connect to it)
    * a browser is expected to catch http://host:80 requests and
      transfer them into https://host:443
    * http to any port other than 80 gets changed into https to the same
      port number, e.g. the browser must change requests to
      http://host:81 into requests for https://host:81

Is my understanding right?

Thanks,
Kai

---

From: Adam Barth <[email-masked]>
Date: Mon, 19 Jul 2010 02:08:00 -0700

On Mon, Jul 19, 2010 at 12:49 AM, Kai Engert <[email-masked]> wrote:
> plain http is forbidden for all ports on a known HSTS host
> (it's not possible to run any additional http services on a known HSTS host,
> because HSTS-compliant browsers are expected to never connect to it)
> a browser is expected to catch http://host:80 requests and transfer them
> into https://host:443
> http to any port other than 80 gets changed into https to the same port
> number, e.g. the browser must change requests to http://host:81 into
> requests for https://host:81
>

Yes, precisely.

Adam

---

From: Dan Winship <[email-masked]>
Date: Mon, 19 Jul 2010 08:56:05 -0400

> containing a Set-Cookie header.

It could still receive a relevant cookie from an HTTP response to a
*different* host though. (Eg, if secure.example.com is STS, an attacker
could still try to trick you into sending a request to
http://evil.example.com/, which could then set a cookie with
domain=example.com that may override a cookie set by secure.example.com.)

-- Dan