Subject: same connection, different hosts

From: Stefan Eissing <[email-masked]>
Date: Wed, 27 May 2015 15:03:26 +0200

This is an interop question in relation to 421, section 9.1.2.

When a HTTP/2 server has several virtual hosts configured over TLS, there might be an overlap in the subject alternate names (be it by wildcards or not). AFAIK clients are trying to reuse existing connections by checking their subject names for a match. Since authority is specified for every stream, the server is able to identify the proper host to process the stream in.

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?

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.

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…

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.

Thanks,

  Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 May 2015 09:33:22 -0700

> 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…

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. Especiall…

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 th…

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.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 27 May 2015 18:08:42 +0000

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:[email-masked]] 
Sent: Wednesday, May 27, 2015 9:33 AM
To: Stefan Eissing
Cc: HTTP Working Group
Subject: Re: same connection, different hosts

> 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. Especiall…

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…

> 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 th…

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.

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 28 May 2015 12:12:45 +0200

Thanks for the answers. I agree that a mix of wildcard and specific cert is unlikely and to be avoided. I was trying to follow up on a issue reported by someone on such a config..

As to Apache, I am not aware of any checks being done between SNI and Host headers and would be surprised by that. vhost selection is clearly done on each request, be it TLS or plain. So far, I plan for mod_h2 to only answer 421 when a request on a HTTP/2 connection arrives for a vhost where the module was explicitly disabled. Otherwise I leave connection selection up to the client and server administrator then.

//Stefan

> Am 27.05.2015 um 20:08 schrieb Mike Bishop <[email-masked]>:
> 

<green/>bytes GmbH

---

From: Erik Nygren <[email-masked]>
Date: Fri, 29 May 2015 17:02:38 -0400

I have some concerns that in moving from a SHOULD NOT to a MAY, client
behaviors on connection sharing may be underspecified in ways that make it
very hard for server operators to avoid degenerate situations.  Sending
requests for arbitrary host headers down an HTTP/2 connection authenticated
with a wildcard certificate could be highly problematic in some cases, even
if the certificate matches.  At a minimum, I'd strongly hope/encourage
clients to only share connections if both hostnames DNS resolve to
overlapping IP addresses.  Otherwise you might end up talking to a server
that wasn't even fully configured for accepting traffic for a given
hostname or otherwise causing major problems for DNS-based load balancers.

One aspect that could also be better specified is what clients can/should
use for caching a 421 response.
For example, most of {IP, Port, SNI-Sent, Authority, ALPN-Negotiated}
should be used in the key for any caching of a 421 response.

On Wed, May 27, 2015 at 12:33 PM, Martin Thomson <[email-masked]>
> 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?

It does seem likely that a conservative behavior for servers may be to
return a 421 response
for any authority Host that doesn't  match the SNI name sent.  I'd hope
that clients would then renegotate a TLS connection
to an IP address that the Host actually resolves to while sending an SNI of
the Host they plan to use.

I was discussing with Mark that it may make sense to have an HTTP/2
extension
for a server to explicitly indicate which subset of the TLS certificate
hostnames are
acceptable to use over a given connection so that a client doesn't have to
try guessing.

It may also make sense for us to work on an Informational draft (or h2 wiki
page initially?) with operational
guidance on connection sharing.

        Erik

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 30 May 2015 17:57:10 +1200

> use for caching a 421 response.

That is defined in RFC 7234 section 4. HTTP/2 only seeks to replace RFC
7230 message framing.

> should be used in the key for any caching of a 421 response.

Adding non-HTTP details to the variant conditions makes it uncacheable.

* HTTP(S) messages have to be capable of travelling over more than one
TCP connection. IP and port are not an option.

* Response messages have to be able to transit over HTTP/1.0 and 1.1
hops where Authority SNI, and ALPN are possibly not available.

Amos

---

From: Glen Knowles <[email-masked]>
Date: Sat, 30 May 2015 16:18:57 -0700

I pretty much concluded that, based on the way our server infrastructure
works, we should set no-cache headers with all 421 responses.

This seems a reasonable option for any deployment where virtual servers
wander around behind different clusters of proxies. Sometimes it's an
optimization where you want to redirect requests for certain resources to
somewhere closer to the client or to a server that already has the
resources required cached locally.

In point of fact, I'm not sure there are any circumstances that you'd want
clients to cache a 421. Because clearly you've configured DNS such that
both hosts go to the same IP, therefore there must be (barring
misconfiguration) a new connection scenario where it's okay to send
requests for the 421 rejected host to the IP.

Perhaps there's an ALT-SVC case where caching 421's makes sense, I haven't
really thought about it.

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 01 Jun 2015 13:28:01 +1200

> requests for the 421 rejected host to the IP.

If you start looking closely at the wider HTTP/1 traffic system you will
find an enormous number of messages flowing around with Host: header
containing malformed, mismatching request-target, or otherwise plain
garbage values (ie "localhost:0" FFS).

Any of those are eligible for 421 and having it cacheable would vastly
reduce garbage bandwidth or loops of repeated requests.

The main use case I see though is ISP environments where for example,
https:// URLs are directed to a proxy with no HTTPS support built in.

Origin servers such as Apache where its possible to turn on TLS suport
and use it for example.com by then not possible to disable https:// URLs
for example.org being responded to with wrong certificates. 421 would
help prevent plaintext content going out over HTTPS. (yeah for some of
us its a legal requirement *not* to encrypt content).

Amos