Subject: #144: Attacks from Same Host (OppSec)

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Mar 2016 16:27:45 +1100

<https://github.com/httpwg/http-extensions/issues/144>

Currently, the spec says:
	
"""
3. Server Authentication
[I-D.ietf-httpbis-alt-svc] requires that an alternative service only be used when it is strongly authenticated as the origin.

For the purposes of this specification, there are two ways to achieve this:

	• Using TLS with a certificate that validates as per [RFC2818], or
	• Using an alternative service with a hostname that is character-for-character identical to that of the origin.
The latter approach allows deployment without the use of valid certificates, to encourage deployment of opportunistic security. Therefore, in these cases the alternative service can provide any certificate, or even select TLS cipher suites that do not include authentication.
"""

I think what we're talking about here is changing it to something like:

"""
3. Server Authentication
[I-D.ietf-httpbis-alt-svc] Section 2.1requires that an alternative service only be used when there are "reasonable assurances" that it is under control of and valid for the whole origin

For the purposes of this specification, there are two ways to achieve this:

	• Using TLS with a certificate that validates as per [RFC2818], or
	• Confirming that both the origin and the alternative service support this specification by obtaining a 200 (OK) response for the "http-tls" well-known URI (section X).

The latter approach allows deployment without the use of valid certificates, to encourage deployment of opportunistic security. Therefore, in these cases the alternative service can provide any certificate, or even select TLS cipher suites that do not include authentication.

X. The "http-tls" well-known URI

[contents? format? extensibility? etc.]

"""

Questions:

1) Is this roughly what people had in mind?
2) Do we need to get a positive indication from both the origin and the alternative, or just the origin?
3) Do we need a more solid indication than a 200 OK? E.g., media type?
4) What should be in the well-known URI's representation, if anything?
5) Should we tie the validity period of the well-known URI to its cache freshness lifetime?

Cheers,

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 2 Mar 2016 16:44:48 +1100

> 1) Is this roughly what people had in mind?

Yes, this seems fine.

> 2) Do we need to get a positive indication from both the origin and the alternative, or just the origin?

If the alternative is actually an alternative, the .well-known
solution should produce files in both places.  So checking both won't
just especially.

> 3) Do we need a more solid indication than a 200 OK? E.g., media type?

200 OK seems a bit weak, but I think that it would suffice if we
didn't want to extend in any way.

Including the actual origin (or maybe origins) in the document would
prevent accidents, I think.

> 4) What should be in the well-known URI's representation, if anything?

I'm a fan of JSON for this sort of thing.

> 5) Should we tie the validity period of the well-known URI to its cache freshness lifetime?

I think not.  I'd prefer an explicit indication in the JSON itself.
An expired document will mean that the value might be refreshed more
often than the real validity period.

If we do this part right, we can ditch the new header field, which was
never that nice.

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 02 Mar 2016 17:03:08 +0000

| 3. Server Authentication
| 
| [I-D.ietf-httpbis-alt-svc] Section 2.1requires that an alternative
| service only be used when there are "reasonable assurances" that it is
| under control of and valid for the whole origin
| 
| For the purposes of this specification, there are two ways to achieve
| this:
| 
| • Using TLS with a certificate that validates as per [RFC2818], or
| • Confirming that both the origin and the alternative service support
| this specification by obtaining a 200 (OK) response for the "http-tls"
| well-known URI (section X).
| 
| The latter approach allows deployment without the use of valid
| certificates, to encourage deployment of opportunistic security.
| Therefore, in these cases the alternative service can provide any
| certificate, or even select TLS cipher suites that do not include
| authentication.

1) This seems not specify that alternative is same host than
  origin in case when valid certificate is not required

There fore "http-tls" well-known URI on _alternative_
must include origin -name (method, host, port)

2) If origin does not filter Alt-Svc: -headers, 
  http://origin/~attacker/  skript can still
  produce 
     Alt-Svc: h2=":8000"

 and if origin runs it own real alternative on port 81
 then it will have "http-tls" well-known URI

There fore "http-tls" well-known URI on _origin_
must include alternative (host and port).

Because it is alternative 
"http-tls" well-known URI on _origin_ and _alternative_
must be same.

Therefore "http-tls" well-known URI must include
origin -name and alternative (host and port).

Now comments about format of "http-tls" well-known URI
except that it should be something what can
not be silently truncated.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 02 Mar 2016 17:15:02 +0000

Kari Hurtta <[email-masked]>: (Wed Mar  2 19:02:46 2016)
> must include origin -name (method, host, port)

I note that perhaps that part 1) is handled with
421 Misdirected Request HTTP Status Code

But I think that it is still good idea include
origin to "http-tls" well-known URI.

> must include alternative (host and port).

Of course filtering Alt-Svc: on user suplied 
scripts handles this.

But I think that it s still good idea include
alternative host / port to "http-tls" well-known URI.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 02 Mar 2016 19:12:18 +0000

( commenting myself ... )

> must include origin -name (method, host, port)

'method' should be "http" because "https" already
requires valid certificate.

But maybe browser may want check well-known URI
for https -method on some cases. That is not
required, but browser may do extra checks.

( And anyway defination of origin includes
 method. )

Certificate does not tell method and port,
only name (and it may be *.example.com).

Perhaps other checks are like "certificate
for alternative must be equal strong as 
for original".

( Domain Validated, Organization Validated,
 Extended Validated

 is wildcard used on certificate name?

 what is signing algorithm?

 have certificate same validation
 chain?

 and then negatiated TLS parameters
)

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Mar 2016 10:18:52 +1100

> On 2 Mar 2016, at 4:44 PM, Martin Thomson <[email-masked]> wrote:
> 

parse error

> prevent accidents, I think.

A JSON file containing an object like this:

HTTP/x 200 OK
Content-Type: application/json
{
  'origin': 'https://foo.example.com:443'
}

would answer a few questions here, I think...

> often than the real validity period.

What's the benefit here? It just seems like an opportunity to have a mismatch between the real validity period and how long it lives in intermediary caches, etc.

> If we do this part right, we can ditch the new header field, which was

+1

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Mar 2016 11:15:53 +1100

>> solution should produce files in both places.  So checking both won't

...clucking autocorrect.  I mean to say that checking both won't hurt
especially.  It might slow switchover times, but alt-svc was never
going to fast because it doesn't need to be.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Mar 2016 13:54:55 +1100

OK, I've taken a stab at this here:
  https://github.com/httpwg/http-extensions/commit/c7324f4804f

Martin, I just left the HTTP-TLS stuff in for now; Martin, do you want to try to integrate it into the well-known stuff?

Cheers,

> On 3 Mar 2016, at 11:15 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Mar 2016 14:55:47 +1100

>   https://github.com/httpwg/http-extensions/commit/c7324f4804f

That looks like what we discussed.

> Martin, I just left the HTTP-TLS stuff in for now; Martin, do you want to try to integrate it into the well-known stuff?

See https://github.com/httpwg/http-extensions/pull/151

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Mar 2016 16:27:28 +1100

OK, I merged this and did some editorial adjustments, see:
  https://github.com/httpwg/http-extensions/compare/ab374d6...master?name=master&short_path=fd50b7c#diff-fd50b7c5883e57d650fa3ac7f47c12f9

Martin, one question -- right now, it's written in such a way that 'commit' is effectively an optional feature (for servers *and* clients). Was that your intent, and if so should it be made more explicit? Right now, it's a bit confusing because you use both "requiring" and "clients can" regarding this feature.

If folks are OK with all of that, I think we can close #67, #144 and #145:
  https://github.com/httpwg/http-extensions/issues?q=is%3Aopen+is%3Aissue+label%3Aopp-sec

The only thing remaining then is Kari's suggestion that the .well-known file also include the alternatives, to mitigate the case when an attacker has 1) the ability to inject response headers, 2) the ability to listen on a port on the same host, and 3) doesn't have the ability to modify .well-known (AKA "shared hosting w/ shell access").

Thoughts?

> On 8 Mar 2016, at 2:55 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 13 Mar 2016 17:49:21 +0000

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0394.html

| The only thing remaining then is Kari's suggestion that the .well-known 
| file also include the alternatives, to mitigate the case when an attacker 
| has 1) the ability to inject response headers, 2) the ability to listen 
| on a port on the same host, and 3) doesn't have the ability to modify 
| .well-known (AKA "shared hosting w/ shell access").

( I mentioned this earlier, but not to: HTTP WG <[email-masked]> )

Yes, I like that browser can defend against this attack also.
Mike Bishop described that attack:

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0064.html

| http://users.example.com is a shared server which hosts user home
| pages.  Eve places a config file in her wwwpages directory to add an
| Alt-Svc header to pages served out of http://users.example.com/~eve
| announcing an alternative service for http://users.example.com on port
| 23412.  Bob is using an Alt-Svc-capable browser.  After Bob has
| visited http://users.example.com/~eve, he visits
| http://users.example.com/~alice.  His browser, obeying Eve's Alt-Svc
| header, accesses the alternative service on port 23412, where Eve is
| running a forward proxy that replaces all pages except her own with
| dancing hamsters.

I also have home page on my hosting provider like
 http://home.hosting.provider/~account/

(where 'account' is user id used on shell access. )

My hosting provider ssh access (that is how pages are modified.)

There also seems to have over 5000 other accounts,
so there is probably quite many home pages like that.

These are Apache Per-user web directories
https://httpd.apache.org/docs/2.4/howto/public_html.html

I suspect that shell access is not be as rare than you
imagine. At least search for "web host provider with 
shell access" tells that this feature is provided.

I do not know if these accounts on these providers
share same origin (aka http://home.hosting.provider/~account/ or
http://home.hosting.provider/account/).

This is fine when http://home.hosting.provider/.well-known/http-opportunistic
does not exists.

Also I have sites http://account.hosting.provider/,
https://account.hosting.provider/ and http://www.elmme-mailer.org/
but these does not share same origin with other accounts on here.
So on these sites sharing is not a problem.

And documentation on my hosting provider says that
users can run application servers which listen ports between
30000–40000.

This is allowed but not not recommended – Using of FastCGI or CGI
is recommended.

If hosting provider wants provide Opportunistic Security for HTTP 
for http://home.hosting.provider/, it needs add

http://home.hosting.provider/.well-known/http-opportunistic

with content

{
 "origins": [ "http://home.hosting.provider/" ]
}

But now any of 5000 users can also run listener on home.hosting.provider
and inject

Alt-Svc: h2=":30000"

header field on his pages http://home.hosting.provider/~username/ when 
using CGI.

home.hosting.provider can defend this with filtering Alt-Svc:
from UserDir -pages generated with CGI or FastCGI

Alternatively home.hosting.provider can defend this attack with NOT 
publishing http://home.hosting.provider/.well-known/http-opportunistic
but instead using valid certificate (RFC for "HTTP Alternative Services").

There exists wildcard certificate for *.hosting.provider -name.

But then home.hosting.provider can not use "commit" either because 
that requires http://home.hosting.provider/.well-known/http-opportunistic

But there is little what browser can use to defend against that attack:

1) Browser can just ignore Alt-Svc: if there is not valid certificate
2) Browser can ignore Alt-Svc: if there is ~ on URL
3) Browser can ignore Alt-Svc which gives port > 1023
4) Browser can ignore Alt-Svc for all other paths except 
  '/' , '/.well-known/…' and '*' (OPTIONS)

But these 2) and 3) does give much guarantee to browser.

Then browser is just ignoring Alt-Svc: if there is not valid certificate
so no "Opportunistic Security for HTTP" -support, just support for
"HTTP Alternative Services". 

Perhaps option 4) makes sense for browser (i.e. look that 
/.well-known/http-opportunistic ALSO returns same 
Alt-Svc: -header field). However this is not actually specified.
This is effectively also same than that .well-known also 
lists alternatives. And this does not work if several 
alternatives are rotated on Alt-Svc: -header field.

Browser is easier to defend for this attack (and support
Opportunistic Security for HTTP") if there is
"alternatives" member in the http-opportunistic 
well-known resource.

That "alternatives" member lists valid alternatives which 
are allowed for given in Alt-Svc: -header filed.
I do not have suggested exact syntax for this member. 

Alternatively browser can defend for this attack
if there is "valid-ports" member in the http-opportunistic 
well-known resource. This is enough when origin and alternative 
service’s hostnames are the same.

This is perhaps over-engineering here:

Alternatively browser can defend for this attack
if "origins" member in the http-opportunistic is
not list of strings but if "origins" is
a object where member names are origins
and member values are either list of
alternatives or list of valid-ports.

That is: every origin lists which are alternatives
for it. But I think that this is too complicated:

HTTP/1.1 200 OK
Connection: close

{
 "origins": { "http://example.com": [ 88 ],
              "http://www.example.com:81":  87 ] },
 "commit": 86400
}

(( And then it makes sense to move "commit" also 
  to be per-origin:

{
 "origins": { "http://example.com": {
      "valid-ports":  [ 88 ],
      "commit": 86400 },
     "http://www.example.com:81": {
	"valid-ports":  [ 87 ],
      "commit": 86400 },
  }
}

This is too complex.  So just keep it simple:

{
 "origins": ["http://example.com", "http://www.example.com:81"],
 "commit": 86400,
 "valid-ports": [ 88, 87 ]
}

or "alternatives" instead of "valid-ports".

))

There is no so many different browsers, so I think 
that makes sense them defend against this attack (if 
they support "Opportunistic Security for HTTP").

Getting origins / sites correct is harder, I think.
It is quite easy to add Alt-Svc: header field
to some places but harder to filter Alt-Svc: 
header field from all unwanted outputs. 

/ Kari Hurtta

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 Mar 2016 17:30:04 +0000

My biggest issue was that saying Alt-Svc filtering was the answer imposed a new requirement on existing servers that haven't seen the spec. The well-known URI could simply signal that the server is aware of the specification and blocks user generated Alt-Svc headers.

-----Original Message-----
From: Kari Hurtta [mailto:[email-masked]] 
Sent: Sunday, March 13, 2016 10:49 AM
To: HTTP WG <[email-masked]>
Cc: Kari Hurtta <[email-masked]>; Martin Thomson <[email-masked]>; Mark Nottingham <[email-masked]>; Mike Bishop <[email-masked]>
Subject: Re: [Moderator Action] #144: Attacks from Same Host (OppSec)

| The only thing remaining then is Kari's suggestion that the 
| .well-known file also include the alternatives, to mitigate the case 
| when an attacker has 1) the ability to inject response headers, 2) the 
| ability to listen on a port on the same host, and 3) doesn't have the 
| ability to modify .well-known (AKA "shared hosting w/ shell access").

I also have home page on my hosting provider like  http://home.hosting.provider/~account/

There also seems to have over 5000 other accounts, so there is probably quite many home pages like that.

These are Apache Per-user web directories https://httpd.apache.org/docs/2.4/howto/public_html.html

I suspect that shell access is not be as rare than you imagine. At least search for "web host provider with shell access" tells that this feature is provided.

I do not know if these accounts on these providers share same origin (aka http://home.hosting.provider/~account/ or http://home.hosting.provider/account/).

Also I have sites http://account.hosting.provider/, https://account.hosting.provider/ and http://www.elmme-mailer.org/ but these does not share same origin with other accounts on here.
So on these sites sharing is not a problem.

And documentation on my hosting provider says that users can run application servers which listen ports between 30000–40000.

This is allowed but not not recommended – Using of FastCGI or CGI is recommended.

If hosting provider wants provide Opportunistic Security for HTTP for http://home.hosting.provider/, it needs add

with content

{
 "origins": [ "http://home.hosting.provider/" ] }

But now any of 5000 users can also run listener on home.hosting.provider and inject

Alt-Svc: h2=":30000"

header field on his pages http://home.hosting.provider/~username/ when using CGI.

Alternatively home.hosting.provider can defend this attack with NOT publishing http://home.hosting.provider/.well-known/http-opportunistic
but instead using valid certificate (RFC for "HTTP Alternative Services").

But then home.hosting.provider can not use "commit" either because that requires http://home.hosting.provider/.well-known/http-opportunistic

HTTP/1.1 200 OK

{

{

{

))

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Mar 2016 12:05:31 +1100

It seems like there isn't a lot of interest in adding another mechanism to list the alternatives in the well known file. In particular, there hasn't been any implementer interest expressed.

I'm inclined to send it on to WGLC and see if anything comes up in the SecDir review (etc.) about this.

Closing #144.

> On 15 Mar 2016, at 4:30 AM, Mike Bishop <[email-masked]> wrote:
>