Don't mix secure and insecure schemes on a connection

[enygren]

Using HTTP and HTTPS schemes on a single OppSec connection seems like asking for trouble, especially as the latter would be authenticated and the former might not. We should explicitly prohibit this (clients MUST NOT) and servers SHOULD presumably respond with a 4xx (421?) if mixing of schemes is detected. The exact vulnerabilities or ways to exploit are unclear, but mixing authenticated and unauthenticated (or secure and insecure) communications over a single TLS channel seems dangerous.

It may be reasonable to allow a server to advertise mixing HTTP and HTTPS under a strongly authenticated /.well-known/http-opportunistic (similar to commit), but mixing schemes shouldn't be the default.

[enygren]

From @martinthomson on http-gw:

This is reasonable. A boolean mixed-scheme member that has to be
true seems appropriate. It's cheap enough to warrant doing.

[mnot]

How about:

Because of the risk of server confusion about individual requests' schemes (see [ref to security considerations]), clients MUST NOT mix "https" and "http" requests on the same connection unless the http-opportunistic response's origin object [ref to http-opp section] has a "mixed-scheme" member whose value is "true".

... with an example, incorporated into "Interaction with "https" URIs".

?

[martinthomson]

LGTM