I had the same issue. The issue was a security one https://nvd.nist.gov/vuln/detail/CVE-2019-11840 which required a breaking change to fix so their options where leave everyone vulnerable but could compile or break anyone that uses this code and fix it. I think they made the right choice.
Also golang.org/x/crypto is not a core library so doesn't actually fall under the compatibility guarantee but they seem to try their best not to break it.
Neither of those things applied though; I had x/crypto vendored, so it didn't change it's code either and the CVE is unrelated to the actual code that broke (I used blake2b) and again; it was vendored, so my code wouldn't break but be vulnerable.
The easiest way to accomplish that is definitely with //go:linkname
You can use a comment of the format '//go:linkname [localname] [method]' to link some function as another one. Notably, this includes unexported private methods in the go runtime and stdlib.
I've seen code in the wild that uses this to grab go's map hash algorithm, get monotonic time, and other things.
The go authors have used this hack themselves in the stdlib often enough because the runtime doesn't expose some knob, and rather than thinking that perhaps other developers may want that knob too, they instead use such hacks, but they also don't support said hacks (because how could you, obviously keeping all private functions stable forever is silly and impossible)
Had the great firewall of china block one of the sites I was building for a customer once many years ago. It could only do it for http and not https so assuming it reads the request from the client works out its a http request to an unauthorized IP and sends the reset packet. You cant read the payload for https so didn't know to send the rst packet i'm assuming. Took a while and some playing with wireshark to work out what was going wrong.
Spoke to someone in the Datacenter we where hosting in and they got us adding to some goverment whitelist and it all started working again.
I guess if it worked at the IP level it wouldn't matter whether or not the transport was encrypted. I'd wager how it worked was by sniffing the Host header in the request, and as this was "many years ago" most likely predated Server Name Indication in TLS so encryption was enough to thwart a host-based blocking approach. Now of course with SNI the host is in clear text in the ClientHello (unless using TLS 1.3 ESNI) so the GFC could still block using hostnames even with TLS.
They have the money and resources to create a competing compiler that does it's own ABI and fixes things in the language. If they could get a 5 - 10 % increase in performance would people move ?
nginx is not shipped by RHEL so you are probably pulling from epel. you can also pull the latest stable version directly from nginx's repo http://nginx.org/en/linux_packages.html#RHEL-CentOS which has supported http2 since RHEL 7.4 when they released alpn support in openssl.
you can also install the latest version of apache from red hats software collections repo that supports http2 but it throws everything into /opt/rh/rh-httpd24/ which is a bit weird.
Also golang.org/x/crypto is not a core library so doesn't actually fall under the compatibility guarantee but they seem to try their best not to break it.