Opportunistic Security for HTTP


3. Server Authentication

|   For example, this request/response pair would constitute reasonable
|   assurances for the origin "http://www.example.com" for any
|   alternative service also on "www.example.com":
|   GET /.well-known/http-opportunistic HTTP/1.1
|   Host: www.example.com
|   HTTP/1.1 200 OK
|   Content-Type: application/json
|   Connection: close
|   {
|     "origins": ["http://example.com", "http://www.example.com:81"]
|   }

Origin "http://www.example.com" is mentioned on text,
Origin "http://www.example.com" is NOT mentioned on /.well-known/http-opportunistic.


8. Security Considerations

For "Attacks from the same host" this makes silent assumption that
/.well-known/http-opportunistic indicates that there is not injected
bad Alt-Svc: -headers.

In other words Alt-Svc: -headers are assumed to be filtered 
out from attackers (shared hosting), but that assumption is not
spelled out on draft.


I disagree resolution of "Attacks from the same host".

My long explanation is on

  Re: [Moderator Action] #144: Attacks from Same Host (OppSec)
  Message-Id: <20160313174847.DD97B389F@welho-filter4.welho.com> 

Effectively browser's (or http client's) method to defend this 
attack is still that browser ignores alternative service 
if port >= 1024

If /.well-known/http-opportunistic does not include lists
alternatives or list of valid ports where alternative service
is supposed to be located, that ignoring port >= 1024 is best 
guess what browser can do.


Patrick McManus wrote:

| I'm actually glad the port number nonsense got called out. It didn't have
| real value and its the kind of window dressing only a committee could love
| (I say lovingly, as member of said committee.).

I'm not sure about that because draft-ietf-httpbis-http2-encryption does not
provide other defenses for browser.

I originally suggested that:

| How about requiring that alternative service are also listed on
| /.well-known/alternative-services
| Pre-Alt-Svc servers do not provide /.well-known/alternative-services
| and eve can not provide /.well-known/alternative-services on
| original service.
| I think that this stops that attack if http client also checks
| /.well-known/alternative-services when alternative service
| does not provide strong auth. This of course adds additional delay
| before alternative service is used.

Current draft does not provide for client means to do check with 
/.well-known/http-opportunistic resource. Therefore port number
check is still on table.


5.1. Opportunistic Commitment

|   An origin can reduce the risk of attacks on opportunistically secured
|   connections by committing to provide an secured, authenticated
|   alternative service.  This is done by including the optional "commit"
|   member in the http-opportunistic well-known resource (see Section 6).

This does not make possible to specify "commit" without saying same time that 
there is also reasonable assurance for alternative services for on same host
which does not provide strong authentication.

There should be possible to give "commit" for authenticated alternatives
WITHOUT giving also reasonable assurances for non-authenticated alternatives
(on same host that origin).

/.well-known/http-opportunistic SHOULD include separate indication
that for reasonable assurances. My suggestion for that parameter is same than 
for "Attacks from the same host".


My suggestion for 

 3. Server Authentication

|   When the client has a valid http-opportunistic response for an
|   origin, it MAY consider there to be reasonable assurances when:
|   o  The origin and alternative service's hostnames are the same when
|      compared in a case-insensitive fashion, and
|   o  The chosen alternative service returns the same response as above.
+   o  The "valid-ports" member of the root object on the http-opportunistic 
+      response has a value of an array of numbers, one of which is same
+      value than alternative service's port number.

  6. The "http-opportunistic" well-known URI

-   This specification defines one additional, optional member of the
-   root object, "commit" in Section 5.  Unrecognised members MUST be
-   ignored.


+   This specification defines two additional, optional members of the
+   root object, "commit" in Section 5 and "valid-ports" in Section 3.  
+   Unrecognized members MUST be ignored.

That "valid-ports" member makes explicit which port numbers are under
origin's control. So there not need make assumption like port numbers 
<= 1024 are safe.

This also makes clear for which purpose /.well-known/http-opportunistic is.
There is either "commit" or "valid-ports" member on http-opportunistic 
response. (It is unlikely that both on same time makes sense. )

Because this also requires that origin and alternative service's hostnames 
are same, listing port numbers effectively lists alternative
services (except that protocol is not mentioned, "h2" is only 
protocol which fulfills requirements). 

That list of port number or alternative services on http-opportunistic 
response does not indicate that alternative service is provided on these
ports, only that alternative services may be provided on these ports
without valid certificate. This does not replace Alt-Svc: -header field.


5.1. Opportunistic Commitment

3. Server Authentication requires that

| The chosen alternative service returns the same response as above.

Should there be same requirement before "commit" is accepted ?
Now that is not required for commit.

/ Kari Hurtta

Received on Tuesday, 22 March 2016 13:26:39 UTC