Subject: SNI requirement for H2

From: Nicholas Hurley <[email-masked]>
Date: Fri, 3 Apr 2015 11:37:38 -0700

All,

While looking at https://github.com/molnarg/node-http2/issues/69 I came to
the realization that it appears we have (unintentionally) made it
impossible to speak h2 when connecting directly to an IP address (as in, IP
address typed into URL bar as opposed to hostname typed into URL bar) and
remain compliant with both the h2 spec and RFC 6066. 6066 specifies that
SNI is not to be sent for an IP literal, while h2 requires SNI. You can see
the conflict.

In node-http2, we have decided to relax the SNI requirement, and still
speak h2 to clients that don't give us any SNI, under the assumption that
this (IP in URL bar, or equivalent) is the case we are hitting. I had also
filed a bug against Firefox to stop advertising h2 in the cases where we
won't send SNI, but am rethinking that idea, as it was pointed out (rightly
so) that a lot of test servers never have a hostname associated with them,
and not being able to talk h2 to test servers seems like a Bad Idea :)

FWIW, I checked Safari, Chrome, IE (11 on Windows 7), and Firefox. Both
Safari and Chrome send SNI regardless of IP or hostname, so they will not
run into this problem. IE and Firefox both send SNI only for hostnames (at
least in the configurations I tested), so they will hit this problem.
(Obvious caveat: non-Firefox browsers may have changed their behavior in
later versions than I have access to, so of course my testing may not hold
true in the future.)

I talked briefly to Martin offline, and he says we may be able to get a
clarification on this point in during AUTH48 to (my words, now, not his)
perhaps relax this restriction, or at least make it clear that you probably
don't need to require SNI in a testing situation, in order to avoid this
problem.

Thoughts?

---

From: Roberto Peon <[email-masked]>
Date: Fri, 3 Apr 2015 12:06:36 -0700

Does anyone recall why 6066 has no SNI for IP literals? (It could be an
empty SNI field or the SNI could indicate the IP literal)?
-=R

On Fri, Apr 3, 2015 at 11:37 AM, Nicholas Hurley <[email-masked]> wrote:

> All,
>
> While looking at https://github.com/molnarg/node-http2/issues/69 I came
> to the realization that it appears we have (unintentionally) made it

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 3 Apr 2015 21:25:31 +0200

> empty SNI field or the SNI could indicate the IP literal)?

I find it surprizing as well, given that NAT/reverse proxy is very common
in front of servers and that the address specified in the URL bar (hence in
the SNI if it were sent) would be authoritative and would not necessarily
match the one the server sees on the local socket.

Willy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Apr 2015 12:58:20 -0700

> match the one the server sees on the local socket.

I don't believe that anyone bothered to define it.  SNI was (and still
largely is) designed to solve the virtual hosting problem.  Clearly
you don't have that problem if you have an IP address.

As for using AUTH48, I think that all we need to do is add a "...if a
domain name is used." clause or something like that  The problem with
this is that it would require Specification Track Manager approval.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 3 Apr 2015 22:26:32 +0200

Hi Martin,

> you don't have that problem if you have an IP address.

You definitely can in fact eventhough that's not very common. I used to
work for a customer where all internal applications were referenced by
their IP address because for many years there was no DNS. And it's
perfectly valid to do virtual hosting with IP addresses as well, what
happens there is the following :

                 load balancer

                 +-------------+
     ----------> | 10.0.0.1:80 |
  clients        |             | ----------> 10.1.1.1:8000  (srv1)
     ----------> | 10.0.0.2:80 |
                 |             | ----------> 10.1.1.2:8000  (srv2)
     ----------> | 10.0.0.3:80 |
                 +-------------+

So the servers only see the "public" IP address in their host header
field (the 10.0.0.X ones) and route to the correct application thanks
to this.

I'm seeing well how that can be transposed to TLS using SNI. Maybe
the reason why it's not supported in this case is to avoid emitting
IP-based certs, I don't know. But the use case is valid even if rare,
and if there are workarounds (eg: declare hostnames in a DNS).

> domain name is used." clause or something like that

Yes, that would make sense to fix the issue reported by Nicholas.

> The problem with

I trust you on this, I don't know the process :-)

Cheers,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Apr 2015 17:31:48 -0700

On 3 April 2015 at 13:26, Willy Tarreau <[email-masked]> wrote:
> You definitely can in fact eventhough that's not very common.

Let's just say that it's not particularly interoperable.  Slapping IP
into an SNI slot, while that has been done, is not valid.  I'm not
aware of any SNI extension that would take an IP (I've recently had
cause to look into this because NSS has a bug if you attempt to use an
SNI extension).

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 5 Apr 2015 18:21:27 +1000

On 4 April 2015 at 05:37, Nicholas Hurley <[email-masked]> wrote:

> while h2 requires SNI

My reading of the spec is that h2 requires SNI to be supported, but I can't
see where it says that a server must reject a connection that does not
provide SNI?

We've only just implemented our SNI support in jetty and we certainly have
not tied it to h2 in anyway.   If your key store has multiple certificates,
then a provided SNI will be used to select which certificate to use and if
there are none matching the connection is refused.

This is entirely separate from our ALPN negotiation and I don't see where
the spec requires us to tie them together (actually with the java 8 impl of
SNI is was hard enough to tie the SNI name acceptance to the certificate
selection)!

So hopefully the clarification is just saying that required to support is
not the same as required to use.

cheers

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.