Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Positive indicator of server understanding #12

Closed
martinthomson opened this issue Jul 24, 2014 · 7 comments

Comments

Projects
None yet
4 participants
@martinthomson
Copy link
Contributor

commented Jul 24, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2014

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 mnot added design labels Jul 29, 2014

@mnot

This comment has been minimized.

Copy link
Member

commented Jul 29, 2014

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

This comment has been minimized.

Copy link
Member

commented Nov 11, 2014

Discussed in Honolulu; document in security considerations.

@mnot mnot added the editor-ready label Jan 21, 2015

@reschke

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2015

Proposed text?

@martinthomson

This comment has been minimized.

Copy link
Contributor Author

commented Jan 29, 2015

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

This comment has been minimized.

Copy link
Member

commented Feb 11, 2015

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

@martinthomson

This comment has been minimized.

Copy link
Contributor Author

commented Feb 11, 2015

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.

@reschke reschke self-assigned this May 1, 2015

reschke added a commit that referenced this issue May 1, 2015

@reschke reschke closed this May 1, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.