#144: Attacks from Same Host (OppSec)

| 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

Received on Wednesday, 2 March 2016 21:36:15 UTC