Subject: [websec] HSTS -- what about ports?

From: Daniel Veditz <[email-masked]>
Date: Sat, 20 Nov 2010 22:29:48 -0800

The HSTS spec needs to be more clear about how to handle multiple
servers running on different ports on the same host. I think, by
referring to host name matching only, that the intent of the spec is
that a server running on any port can set HSTS behavior for every
other port on that host. If this is correct it might be clearer to
rename "HSTS Server" to "HSTS Host" and to somewhere in the spec
mention explicitly that the port is ignored when matching host names.

An alternate behavior would be that a server running on port X only
specifies the behavior for that port, with a special case for the
default ports 80/443 because they go unspecified. This would make
sense from a security POV only if cookies were port-specific (with
again a special case for the unspecified default ports), but I don't
believe any browser implements cookies in that way. Handling HSTS in
a port-specific manner also complicates the meaning of
includeSubDomains.

-Dan

---

From: Kai Engert <[email-masked]>
Date: Mon, 22 Nov 2010 17:28:47 +0100

On 21.11.2010 07:29, Daniel Veditz wrote:
> other port on that host.

This is correct in my understanding.

> If this is correct it might be clearer to

About 4 months ago, when I reviewed the Firefox implementation, I asked 
similar questions on this list.
It was said, the https-strictness should apply to whole hosts.

The summary was:

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

Kai

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 22 Nov 2010 09:52:34 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Daniel Veditz
> Sent: Saturday, November 20, 2010 10:30 PM
> To: [email-masked]
> Subject: [websec] HSTS -- what about ports?
> 
> The HSTS spec needs to be more clear about how to handle multiple servers
> running on different ports on the same host. I think, by referring to host
> name matching only, that the intent of the spec is that a server running on
> any port can set HSTS behavior for every other port on that host. If this is
> correct it might be clearer to rename "HSTS Server" to "HSTS Host" and to
> somewhere in the spec mention explicitly that the port is ignored when
> matching host names.

Agreed. This is on Jeff's to-do list per a separate email conversation I had with him yesterday.

> 
> An alternate behavior would be that a server running on port X only specifies
> the behavior for that port, with a special case for the default ports 80/443
> because they go unspecified. This would make sense from a security POV
> only if cookies were port-specific (with again a special case for the
> unspecified default ports), but I don't believe any browser implements
> cookies in that way. Handling HSTS in a port-specific manner also complicates
> the meaning of includeSubDomains.

You're correct.  This topic just got re-started again yesterday, and I wrote a little something about it here:

http://securityretentive.blogspot.com/2010/11/quick-clarification-on-hsts-http-strict.html

Essentially cookie leakage is the problem, and since they aren't scoped to ports, we must interpret HSTS for *all* ports.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Nov 2010 14:24:03 -0500

I think we should ask the question of what degree of fidelity we can expect
to achieve trying to control layer 5 objects (ports) at layer 7.

The HTTP approach is a hack. It is a necessary hack but it is still a hack.
And as such we have to accept that we probably have to limit what we attempt
to achieve.

In the context of Web browser security there is a real possibility that port
numbers represent a downgrade attack possibility.

http://paypal.com/wlewohefoiwhefoihw

looks a lot like:

http://paypal.com:81/wlewohefoiwhefoihw

The place where I might want to apply different security policy according to
port numbers would be in the context of Web Services.

That is a very different problem space and at this point I don't think
anyone is proposing to apply HSTS there.

So I think that HSTS should apply to all ports within the specified domains
but that it should NOT apply to Web services at this point.

On Mon, Nov 22, 2010 at 11:52 AM, Steingruebl, Andy <
[email-masked]> wrote:

> specifies
> Essentially cookie leakage is the problem, and since they aren't scoped to
> ports, we must interpret HSTS for *all* ports.
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

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

---

From: Adam Barth <[email-masked]>
Date: Mon, 22 Nov 2010 17:22:40 -0800

> but that it should NOT apply to Web services at this point.

What does it mean, concretely, for HSTS not to apply to web services?
For example, is api.flickr.com a web service?  Is graph.facebook.com?

Adam

---

From: Marsh Ray <[email-masked]>
Date: Mon, 22 Nov 2010 20:17:25 -0600

On 11/22/2010 07:22 PM, Adam Barth wrote:
> On Mon, Nov 22, 2010 at 11:24 AM, Phillip Hallam-Baker<[email-masked]>  wrote:

Good question.

What's a "web" for that matter?  Is there an RFC which defines this term?
In http://tools.ietf.org/id/draft-hodges-strict-transport-sec-02.html
the term "web" is used multiple times, sometimes capitalized like a 
proper noun, sometimes not.

Perhaps the distinction Phillip is getting at is that some clients are 
purely programmatic, e.g., a software update system which periodically 
polls for new updates by exchanging XML messages over HTTP or HTTPS. Or 
an international exchange trading system for, say, IPv4 address space.

Do these scenarios present different considerations than a user viewing 
plain HTML pages with Firefox? For example, are programmatic clients 
more likely to use nonstandard ports?

My guess is that there are some significant differences, but the 
distinction is blurry in practice. After all, the server app is free to 
not return the HSTS header if it's not what he intends to convey to his 
clients, and client libraries are likely to have a means of overriding 
it if it causes trouble.

They're usually started with an https: URL from program configuration, 
so perhaps we don't need to solve the problem of a user who may just 
type "examplebank.com" into the UA's address bar. Programmatic clients 
may not even implement the logic to follow redirects, which may cut down 
on that attack vector (maybe not - I haven't thought it through).

- Marsh

---

From: Adam Barth <[email-masked]>
Date: Mon, 22 Nov 2010 18:21:05 -0800

On Mon, Nov 22, 2010 at 6:17 PM, Marsh Ray <[email-masked]> wrote:
> the term "web" is used multiple times, sometimes capitalized like a proper
> noun, sometimes not.
>
> purely programmatic, e.g., a software update system which periodically polls
> for new updates by exchanging XML messages over HTTP or HTTPS. Or an
> international exchange trading system for, say, IPv4 address space.
>
> plain HTML pages with Firefox? For example, are programmatic clients more
> likely to use nonstandard ports?
>
> My guess is that there are some significant differences, but the distinction
> is blurry in practice. After all, the server app is free to not return the
> HSTS header if it's not what he intends to convey to his clients, and client
> libraries are likely to have a means of overriding it if it causes trouble.
>
> They're usually started with an https: URL from program configuration, so
> perhaps we don't need to solve the problem of a user who may just type
> "examplebank.com" into the UA's address bar. Programmatic clients may not
> even implement the logic to follow redirects, which may cut down on that
> attack vector (maybe not - I haven't thought it through).

It seems like those User Agents can choose not to implement HSTS if
they don't find it valuable.

Adam

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Nov 2010 22:19:31 -0500

I am a little skeptical of the scope issues if we have a mixture of Web
Services and Web browsers in a domain and some are meant to be always
secure, others not.

So I think that any domain that decides to deploy HSTS is going to have to
accept that they are signing up for supporting the TLS options specified on
everything.

But I can't see this as being an approach I would like to rely on for Web
Services security if there are hundreds of Web Services at a site.

---

From: Adam Barth <[email-masked]>
Date: Mon, 22 Nov 2010 19:24:35 -0800

That seems like a choice that folks who host those web services can
make when they decide whether or not to use HSTS.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Nov 2010 15:16:16 +1100

> they don't find it valuable.

Indeed; this includes most existing UAs ;)

--
Mark Nottingham   http://www.mnot.net/

---

From: Marsh Ray <[email-masked]>
Date: Mon, 22 Nov 2010 23:57:12 -0600

On 11/22/2010 09:19 PM, Phillip Hallam-Baker wrote:
>
> So I think that any domain that decides to deploy HSTS is going to have
> to accept that they are signing up for supporting the TLS options
> specified on everything.

Where "everything" = "served from that hostname"

> But I can't see this as being an approach I would like to rely on for
> Web Services security if there are hundreds of Web Services at a site.

The composite identifier scheme:host:port is already the key to the 
whole security model. There are no useful security boundaries within a 
hostname:port (except possibly GET vs. POST if everything is coded right).

With HSTS, by definition, all content for that hostname is served over 
TCP port 443. So the port is now static, and just the specific DNS 
hostname is the key identifier for the site security.

This is actually _more_ fine-grained than the security boundaries given 
by other parts of the system. In particular, the server of pretty much 
_any_ hostname *.example.com gets to jack around with the cookies sent 
to _every_ hostname *.example.com (and even to example.com itself).

Top-level domains for which a registrar assigns domains with two dots in 
them (example.co.uk) have to be enumerated thoroughly in browser 
software. Any omissions may represent a security vulnerability.
http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1

Not only are there no solid security boundaries within a given hostname, 
there really aren't any under a domain name either!

All those "hundreds of Web Services" running at a site are effectively 
no more secure than the least secure of them all (with regards to 
cookies at least). It may only take an XSS weakness in one of them to 
compromise the security of all of them. Note that even plain HTTP 
connections can set cookies which are sent to the server with HTTPS 
requests.

Such a site needs HSTS more than anyone!

- Marsh

---

From: Adam Barth <[email-masked]>
Date: Mon, 22 Nov 2010 22:10:30 -0800

On Mon, Nov 22, 2010 at 9:57 PM, Marsh Ray <[email-masked]> wrote:
> With HSTS, by definition, all content for that hostname is served over TCP
> port 443. So the port is now static, and just the specific DNS hostname is
> the key identifier for the site security.

That is not correct.  You can serve content on a HSTS server on any
port except port 80.

> This is actually _more_ fine-grained than the security boundaries given by
> other parts of the system. In particular, the server of pretty much _any_
> hostname *.example.com gets to jack around with the cookies sent to _every_
> hostname *.example.com (and even to example.com itself).

This is a design flaw with cookies and is not reflective of how the
rest of the web security model works.

> All those "hundreds of Web Services" running at a site are effectively no
> more secure than the least secure of them all (with regards to cookies at
> least). It may only take an XSS weakness in one of them to compromise the
> security of all of them. Note that even plain HTTP connections can set
> cookies which are sent to the server with HTTPS requests.

XSS can only affect user agents that process HTML and related
technologies.  If the user agents for these web services are more like
a Python script issuing HTTP requests using OAuth token, I'm not sure
your analysis applies.

> Such a site needs HSTS more than anyone!

That's not entirely clear to me.

Adam

---

From: Marsh Ray <[email-masked]>
Date: Tue, 23 Nov 2010 01:22:50 -0600

On 11/23/2010 12:10 AM, Adam Barth wrote:
> On Mon, Nov 22, 2010 at 9:57 PM, Marsh Ray<[email-masked]>
> wrote:
>> With HSTS, by definition, all content for that hostname is served
>> over TCP port 443. So the port is now static, and just the specific
>> DNS hostname is the key identifier for the site security.
>

Hmmm. I'd read this part:

> All insecure ("http") connections to a HSTS Server are redirected by
> the HSTS Server to be secure connections ("https").

It said "http" and I figured it meant "http:" the HTTP protocol 
specifier, not just port 80 in particular. *searches* I don't find the 
number "80" in the document. Is there some wording that makes that 
intent clear?

But you're saying that if twitter.com went HSTS, even a browser which 
did consider twitter.com a "Known HSTS Server" should still be willing 
to load pages from http://twitter.com:31337/ ?

Please correct me if I'm mistaken with any of this, but couldn't an 
attacker simply send the browser a 302 redirect to Location: 
http://twitter.com:31337/ and see all the twitter.com cookies in flight? 
(none of them are marked secure) An active attacker could also proxy the 
user's request to the real https://twitter.com/ and see the actual response.

Isn't this the kind of thing HSTS is supposed to stop?

>> This is actually _more_ fine-grained than the security boundaries
>> given by other parts of the system. In particular, the server of
>> pretty much _any_ hostname *.example.com gets to jack around with
>> the cookies sent to _every_ hostname *.example.com (and even to
>> example.com itself).
>

Nevertheless, it's what we have for the foreseeable future.

>> All those "hundreds of Web Services" running at a site are
>> effectively no more secure than the least secure of them all (with
>> regards to cookies at least). It may only take an XSS weakness in
>> one of them to compromise the security of all of them. Note that
>> even plain HTTP connections can set cookies which are sent to the
>> server with HTTPS requests.
>
> technologies.  If the user agents for these web services are more
> like a Python script issuing HTTP requests using OAuth token, I'm not
> sure your analysis applies.

For example say that an attacker can convince a web service app to 
reflect back something the browser will interpret as script. He may be 
able to send the browser a redirect to that web service request URL. 
When the browser fetches the URL it's willing to supply any cached 
authentication credentials it has available, even a client cert. Now 
attacker has script running in the browser, though perhaps under a web 
service origin. Nevertheless, this script can generalize the 
document.domain to domain names that are suffixes of the web service 
hostname, set cookies at that level, and use iframes and xmlhttprequests 
to make nearly-arbitrary requests (with the credentials of the 
legitimate user).

- Marsh

---

From: Adam Barth <[email-masked]>
Date: Tue, 23 Nov 2010 00:06:17 -0800

On Mon, Nov 22, 2010 at 11:22 PM, Marsh Ray <[email-masked]> wrote:
> It said "http" and I figured it meant "http:" the HTTP protocol specifier,
> not just port 80 in particular. *searches* I don't find the number "80" in
> the document. Is there some wording that makes that intent clear?

Yeah, this is being discussed in another thread on this list.  Andy
posted a clarification on his blog recent:

> But you're saying that if twitter.com went HSTS, even a browser which did
> consider twitter.com a "Known HSTS Server" should still be willing to load
> pages from http://twitter.com:31337/ ?

Nope, but it would be willing to load https://twitter.com:31337/
(i.e., the "http" replaced with "https").

> Please correct me if I'm mistaken with any of this, but couldn't an attacker
> simply send the browser a 302 redirect to Location:

Indeed.

> Nevertheless, it's what we have for the foreseeable future.

At least for folks who use cookies.

> For example say that an attacker can convince a web service app to reflect
> back something the browser will interpret as script. He may be able to send
> the browser a redirect to that web service request URL. When the browser
> fetches the URL it's willing to supply any cached authentication credentials
> it has available, even a client cert.

You're assuming a very specific authentication framework.  Why would
my Python script running on EC2 share credentials with any web
browser?  How would my script's OAuth access tokens be shared with a
web browser even if they were running on the same machine?

> Now attacker has script running in the
> browser, though perhaps under a web service origin.

Which is likely useless.

> Nevertheless, this
> script can generalize the document.domain to domain names that are suffixes
> of the web service hostname, set cookies at that level, and use iframes and
> xmlhttprequests to make nearly-arbitrary requests (with the credentials of
> the legitimate user).

You're assuming the web service host name has any concept of a
"legitimate user."

Adam

---

From: Marsh Ray <[email-masked]>
Date: Tue, 23 Nov 2010 11:03:55 -0600

On 11/23/2010 02:06 AM, Adam Barth wrote:
> On Mon, Nov 22, 2010 at 11:22 PM, Marsh Ray<[email-masked]>  wrote:

OK, I think I get it now. I took that to include plain HTTP.

> (i.e., the "http" replaced with "https").

So what's the reasoning behind forbidding https://twitter.com:80/ ? 
(other than not wanting img src links to be able to send line noise to 
HTTP servers).

> At least for folks who use cookies.

Is there a practical alternative to cookies for web session management?
TLS session IDs? URL rewriting?

> web browser even if they were running on the same machine?

Hmm.. I didn't say anything about OAuth. Perhaps you are the one with 
the specific authentication framework in mind? :-)

I bet the firewall and VPN guys on the list will back me up on this. For 
the great majority of customers I work with the overall goal is exactly 
that - to unify authentication to disparate systems to a single 
directory. Single sign on. Kerberos+LDAP, MS Active Directory. RADIUS, 
TACACS, etc. Out of the box, MSIE will transparently (i.e., without user 
intervention) do NTLM and Kerb auth if it thinks it's talking to the 
"intranet zone" (don't ask exactly what that means).

In most of these schemes, little or no information about the actual 
request being authenticated is bound into the auth. Credentials 
forwarding attack.

>> browser, though perhaps under a web service origin.

Hmmm, I wouldn't count on it.

> You're assuming the web service host name has any concept of a

Not necessarily. It could be the user's credentials on "twitter.com" 
site that's hijacked by script echoed from 
"unauthenticatedwebservice.twitter.com".

Still, I think there are quite a few web services out there which do 
have the concept of "legitimate user" and even authenticate against a 
common directory as other stuff worth attacking (the SSL VPN for 
example). Really though it's less about the Python script and more about 
whether or not the UA thinks it should authenticate using the user's 
stored credentials.

- Marsh

---

From: Adam Barth <[email-masked]>
Date: Tue, 23 Nov 2010 11:35:48 -0800

On Tue, Nov 23, 2010 at 9:03 AM, Marsh Ray <[email-masked]> wrote:
> So what's the reasoning behind forbidding https://twitter.com:80/ ? (other
> than not wanting img src links to be able to send line noise to HTTP
> servers).

Actually, that probably works if you use that URL explicitly.  I was
focused on how the URL re-writing works.  The reason we re-write
http://example.com to https://example.com (notice the port switch from
80 to 443) is because that's the behavior most folks want in the
common case.

Adam