Using HTTP/2 Cleartext for a server in Go 1.24

https://www.clarityboss.com/blog/go-http2-cleartext-h2c-cloud-run

by dan_sbl • 2 months ago

111 15 2 months ago

clarityboss.com

nickcw• 2 months ago

I just merged a commit for exactly this in rclone

https://github.com/rclone/rclone/commit/ad8a108453f3ce983fb6...

It is interesting to dig into why.

There was a security vulnerability in golang.org/x/net/http2/h2c which meant govulncheck warned about it in the CI.

So I updated it and got a warning from the linter that the h2c sub package was deprecated in the latest version, so I removed it.

That is a lot of great tooling working to make things more secure in the Go ecosystem.

It does make work for maintainers though, and the Cambrian explosion of AI discovered security vulnerabilities has been particularly trying!

latchkey• 2 months ago

I love that anyone can write a blog post like this that will get slurped into all the models and we can just say: "use terraform to deploy H2C on GCR"... and it will know exactly what to do.

gear54rus• 2 months ago

which would be pretend doing it, make 1000 mistakes then say "you're absolutely right" after you point to it's fuckups

Npovview• 2 months ago

To use a Analogy, AI is acting like pip install library in this case. Do you really want to do performative acts of Sisyphus or are more interested in end result?

mdavidn• 2 months ago

Note that AWS ALB does not support h2c. When the client and server do, ALB will dutifully forward the h2c header and fail to handle the upgraded response.

xyzzy_plugh• 2 months ago

Has HTTP/2 performance improved as of Go 1.24? Last I checked forcing HTTP/1.1 everywhere was a massive improvement in throughout and latency for a very busy distributed system.

jeffbee• 2 months ago

It has a bit, but there are fundamental issues. Given the way the Go runtime wants to deal with reading and writing sockets, HTTP/2 requires 2 extra goroutines per connection, and the bouncing around over channels that this implies. This might not be a law of physics but there isn't another obvious way to do it in Go.

In the past when I wanted a really fast Go service using HTTP/2 I put the HTTP server in a C++ subprocess that handled the sockets and communicated with the Go application over a pipe. That was nice and fast, avoided the congestive collapse that Go suffers with too many runnable goroutines.

tgv• 2 months ago

Any idea at what point that happens, or how much too many is?

superkuh• 2 months ago

This is excellent news for human persons. Protocol implementations that only allow TLS are not very robust without human maintenence for more than a few years. That said, the human person use cases for HTTP/2 are pretty limited. Generally HTTP/1.1 is a better choice.

miladyincontrol• 2 months ago

I'd much rather http2/3 with an expired cert over cleartext anyday.

LtWorf3• 2 months ago

Could I interest you in installing my root certificate on your machine?

ssfak• 2 months ago

Related: https://http1mustdie.com/

LtWorf3• 2 months ago

Except you can do http1 requests in bash easily and many http3 libraries are bad anyway so you don't get the advantages of using it.

I wanted to do something fast using http3 but it ended up being way faster using ad-hoc code I wrote using http1. It would be even faster if I did it with http3 but hand writing for that protocol is a nightmare so here we are…

edit: downvoting me will not change the reality.

tenuousemphasis• 2 months ago

Ok, none of that makes HTTP/1.1 any more secure.

Using HTTP/2 Cleartext for a server in Go 1.24

Related Stories