RE: same connection, different hosts

Invalid cert vs. "...a wildcard cert"?  If the cert was actually for any site, no real CA would have issued it.  If the cert was for wildcard subdomains, then why would a real server need to be configured to present a more specific cert (invalid or not)?  But that gets into the ideal of uniform configuration....

As for coalescing, RFC 6066 says that you SHOULD NOT do this; based on that, the language in HTTP/2 was weakened from a SHOULD to a MAY.  421 was added as a mechanism for servers to inform clients that they don't support it.  (In practice, clients may have to be a little more flexible -- downlevel versions of Windows won't support it, but return 400.  I hear Apache also doesn't support it, but returns something different?  Less need to be flexible if you only coalesce for HTTP/2.)

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, May 27, 2015 9:33 AM
To: Stefan Eissing
Cc: HTTP Working Group
Subject: Re: same connection, different hosts

On 27 May 2015 at 06:03, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> However, for several reasons, the server might wish to answer such requests with a 421. With the expectation that the client opens/reuses another connection, using the relevant authority in the SNI on that connection. Do client implementors/spec wizard agree that this is a reasonable expectation?

That is correct.  421 is specifically intended for this case and others like it.

> Opposite to that behavior is a server that does not really care what SNI on a connection was specified and will happily dispatch requests based on stream authority to its virtual servers. Especially servers with wildcard certificates will probably behave like that. This can lead to the client seeing different certificates for the same web resource, depending which connection it already had open when starting a request. Without precaution, it might even get resources from different connections with different certificates for a specific browsing session, e.g. web page.

That's already commonplace.  Different certificates for connections to what appears to be the same host happen all the time with clustered servers, depending on the nature of the server provisioning, of course.

> A user of mod_h2 was confused since one of his test sites with an 
> invalid cert became perfectly browsable as he had a wildcard cert on 
> another vhost and had navigated there first…

That sounds perfectly normal.

> Is this an issue? What would be the advice for client implementations / server configurations here? Apart from „don’t do that“, of course. I could imagine that some people who want to anti-shard their sites when using HTTP/2 might stumble into such situations.

I could recommend that servers have a uniform configuration, but I know that's unrealistic.  What's more likely is that you will need a way to test that a cluster is uniformly reachable, which is a different sort of problem.  There, you need to ensure that each and every node in the cluster has a valid certificate for the authority (or set of authorities) that it can serve.

Received on Wednesday, 27 May 2015 18:09:12 UTC