Positive indicator of server understanding

[martinthomson]

I'm not sure how this can be turned into something useful, but this seems pretty bad:

1. An HTTP/1.1 server doesn't check the scheme, but permits authority form requests for both http and https equally. Scheme is instead inferred from the presence/absence of TLS in the stack.
2. Attacker sends an Alt-Svc header field to clients referencing the https endpoint on that server. This can come from any resource on the http endpoint, so it might not require any MitM attack.
3. Clients now make http requests to the secure endpoint and now the content from the https origin is entered into the http origin.

Do we want to require an explicit indication from HTTP/1.1 servers so that clients can
be assured that this error did not occur?

This should not be a problem for HTTP/2.

[enygren]

I'd been under the assumption that http-scheme-over-TLS would only be allowed over HTTP/2? We should make this crystal clear. For example, if Alt-Svc "h2" is used to move http up to TLS then if the TLS fails to negotiate HTTP/2 then the client must fall-back to HTTP/1.1 over clearntext.
Similarly, it should be crystal clear that https scheme must never be allowed over cleartext (h2c or http/1.1).

Does this cover the issues above here?

[mnot]

Patrick and I have discussed this before, both on and off list IIRC. Yes, it's a problem for HTTP/1.

At a minimum, we need security considerations for this. A mechanism for HTTP/1 would be nice, but I'm not sure it's realistic; we'd need some indication of positive support from the server.

[mnot]

Discussed in Honolulu; document in security considerations.

[reschke]

Proposed text?

[martinthomson]

There is text in the opp-sec draft that might be used. I see no good reason to create a circular dependency, so maybe just copy (and reword) it.

[mnot]

@martinthomson can you point @reschke in the right direction?

[martinthomson]

http://httpwg.github.io/http-extensions/encryption.html#confusion-regarding-request-scheme

Many existing HTTP/1.1 implementations use the presence or absence of TLS in the stack to determine whether requests are for http or https resources. This is necessary in many cases because the most common form of an HTTP/1.1 request does not carry an explicit indication of the URI scheme.

HTTP/1.1 MUST NOT be used for opportunistically secured requests.

I think that this document can alter the last statement. I can't think of a good way to generically phrase the statement, but maybe:

Alternative Services MUST NOT be advertised for a protocol that is not designed to carry the scheme. In particular, HTTP/1.1 over TLS cannot carry safely requests for http resources.