golang and http2

[Albert Tedja]

I am reading Golang's support for HTTP2, and it seems it is only enabled by default if you use https

https://go-review.googlesource.com/c/go/+/15828

My questions are:
1. Does this mean I have to use ListenAndServeTLS() to enable http2 and if not, it will fallback to HTTP1.1?
2. Can I explicitly enable HTTP1.1 with https?
3. Can I explicitly enable HTTP2 without https?
I am asking because I might need to have a LB, or reverse proxy like nginx, in front of the app that's handling the SSL handshake.
If this is how my servers are set up, and HTTP2 is only enabled if TLS is enabled, does this mean I am stuck with HTTP1.1 unless I copy the certificate to all of instances?

[howar...@gmail.com]

See

https://github.com/golang/go/issues/14141 - for discussion of the issue; and 

https://github.com/hkwi/h2c for a way to use the in stdlib-but-not-linked-together support for h2c (http/2 over non-TLS).

Howard

[Albert Tedja]

Thank you for the links.

I am still somewhat disappointed that the http/2 protocol would enforce a certain configuration. I understand the necessity of secure connections, but that's should be left as an option to the developers.

If browsers want to strictly use TLS, that's fine because it's consumer facing, but at least Go should enable http/2 over non-TLS. We are engineers here, we should know the difference.

[Anmol Sethi]

It’s really easy to do, see https://github.com/nhooyr/lily/blob/fb72112455ade17f36ed773d87902bb5eefe051e/lily.go#L82-L109

The only disadvantage is that you will not have graceful shutdown.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/sa1-7tqJFaI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josh Humphries]

One serious potential issue is that the URL scheme is still "http" (or "https") for both. With TLS, the client and server can negotiate an on-the-wire protocol using ALPN. This allows client and server to decide on HTTP 1.1 or http/2 based on what they support.

But over plain-text, there is no such protocol negotiation phase. So the client must assume HTTP 1.1 (because not all servers yet support HTTP/2). There is an upgrade mechanism, whereby a client can start an HTTP 1.1 request and include special headers to request upgrading to HTTP/2 on the same connection (see the spec for more details). (I am not sure if Go HTTP servers actually support this update mechanism, though.)

But without a protocol negotiation step or upgrade request, it is unsafe for a client to assume HTTP/2. You have to know what you are doing, and thus it requires you to be more explicit in both client and server code to make it work.

----
Josh Humphries
jh...@bluegosling.com

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Sanjay]

I suggest just using a self-signed cert for your LB<->appserver and disabling cert-checking in your LB. Should be relatively straightforward; you can even have your appserver generate a cert on startup, so there's less messing around with files required.

It'll give you http2, and also cheaply protects you from passive eavesdropping.

If you don't trust your network (e.g. your traffic is going over the internet), you can setup a private CA to also protect you from active eavesdroppers and/or tamperers; cfssl makes this relatively straightforward, you just need to create some JSON files. See https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/ for copy-pastable examples.

My friend and I have used the exact same JSON from that blogpost in a very similar circumstance to the one you describe, and it was maybe 20 minutes of messing around before we had private/public keys for LB and appserver (plus a CA for each side, so that we could support multiple replicas of an instance without them sharing a cert) .