Rewrite Identifying HTTPS Servers

[mnot]

Fixes #404.

[davidben]

Thanks for looking at this! This is certainly an improvement over the current text, but it doesn't quite fix #404. The section before it (https.origin) also talks about verification and includes this text, which was pointed out in the original report:

For a host that is a domain name, the client must include that name in the TLS server_name extension (if used) and must verify that the name also appears as either the CN field of the certificate subject or as a dNSName in the subjectAltName field of the certificate (see [RFC6125]).

Given it was already redundant before the PR and is now redundant with the citation, maybe we can just delete that too...

(Annoyingly, GitHub doesn't allow attaching review comments to text far away from the diff.)

[davidben]

(Commenting here since GitHub doesn't let me staple a comment that high.)

The "https" scheme associates authority based on the ability
of a server to use a private key associated with a certificate that
the client considers to be trustworthy for the identified host.
If a server presents a certificate that verifiably applies to the host,
along with proof that it controls the corresponding private key, then a
client will accept a secured connection to that server as being
authoritative for all origins with the same scheme and host.

The second sentence seems wrong. The client may well not accept a secured connection if, say, the server didn't have a common TLS cipher suite. The client also doesn't consider it authoritative for all origins in HTTP/1.1. More importantly, a certificate merely applying to a host is insufficient. Both sides need to agree on which identities are being asserted. This inherently depends on the protocol semantics.

To make this concrete, I've seen HTTP/1.1 servers that do not enforce the Content-Length header from CGI scripts matches the response body length. That breaks HTTP/1.1's fragile framing and allows the CGI script to inject responses into subsequent HTTP requests on that connection. Is that a security flaw? Without cross-name pooling, arguably not, at least by the Web's security model. The server is sloppy and should fix this, but the CGI script is only attacking its own origin. With cross-name pooling, this is now a security flaw.

HTTP/2 allowing cross-name pooling was implicitly a change in server requirements. It means the HTTP/2 frontend speaks on behalf of all origins and thus must not allow one origin to interfere with another. (Fortunately, HTTP/2's framing is much more robust than HTTP/1.1, so this is easy to achieve.) Even then, the protocol still defines when the multiplexing frontend is speaking on behalf of one origin or another (streams).

We should at least drop the second sentence, as it's simply false, and then we leave the protocol-independent stuff as more describing guidelines/requirements rather than a concrete process. (So the key phrase in the first sentence is "based on".) Perhaps then:

<t>
   The "https" scheme associates authority based on the ability
   of a server to use a private key associated with a certificate that
   the client considers to be trustworthy for the identified host.
   The client relies upon a chain of trust, conveyed from some
   trust anchor (which is usually prearranged or configured), through a
   chain of certificates (e.g., <xref target="RFC5280"/>) to a final
   certificate that allows a private key to authenticate an "https" origin.
   The handshake and certificate validation in
   <xref target="https.initiation"/> describe how that final certificate can
   be used to initiate a secured connection.
</t>

Dunno if the intention with the HTTP/1.1 and HTTP/2 sentences is to be normative or just provide some examples. I thought the point of this document was to extract the protocol-independent parts of HTTP.

[royfielding]

We should at least drop the second sentence, as it's simply false, and then we leave the protocol-independent stuff as more describing guidelines/requirements rather than a concrete process. (So the key phrase in the first sentence is "based on".)

I probably fixed this in 74524e6

[royfielding]

Also fixes #263

[royfielding]

I think this is ready to commit, but will wait for @mnot to check again.