mostly-harmless

It's tricky, to the point that I made a little playground to explore it. https://github.com/FiloSottile/mostly-harmless/tree/main/dep... The example.com/mod2 go.mod does not in fact affect version resolution, because it's not even fetched. However, it affects the example.com/mod1 go.mod, and the example.com/mod1 go.mod affects version resolution. This doesn't help with the problem you are describing, but it still has value from a security point of view, because example.com/mod2 truly doesn't matter except to the extent that was already checked into example.com/mod1, which you do need to trust. If you try to "go build" or "go test" something in example.com/mod2, you actually do get an error since Go 1.17, as if it was not in your dependency tree at all. You need to "go get" it like any new dependency.

Sniffing the SNI from the underlying TCP connection is the proper way to do this. a couple examples I know of(only know go ones of the top of my head): https://github.com/fabiolb/fabio/blob/master/proxy/tcp/tls_c... https://github.com/FiloSottile/mostly-harmless/blob/main/tal... > I don't like doing that but the only other way is to "roll my own crypto" which I understand is a bad thing. You would not be rolling your own cryptographic primitive, or combining existing ones in strange and speculative ways. This is what most people, most of the time mean when they admonish against rolling your own crypto. All you'd have to do is parse the ClientHello to retrieve the SNI. you're in a memory safe language, so parsing bugs result in a crash, not a buffer overflow. I'd say you're on pretty firm ground.