Need a way for TLS server name to differ from authority

[wd]

trafficstars

I'm trying to get rid of the default host header but failed, the command I used grpcurl -v -H 'Host: test.abc.com' lb.abc.com:443 list.

Is this a bug or intended?

[jhump]

@wd, I think you want the -authority header.

[wd]

  -authority string
        The authoritative name of the remote server. This value is passed as the
        value of the ":authority" pseudo-header in the HTTP/2 protocol. When TLS
        is used, this will also be used as the server name when verifying the
        server's certificate. It defaults to the address that is provided in the
        positional arguments.

I need to make TLS handshake with the domain lb.abc.com. And get contents from the VirtualServer with ServerName in Nginx set to test.abc.com. The TLS cert is for lb.abc.com, so the -authority didn't work.

Failed to dial target host "lb.abc.com:443": remote error: tls: handshake failure

[jhump]

There is a separate -servername argument that was originally intended for this -- so you could set the server name to lb.abc.com and the authority to test.abc.com.

However, for security reasons grpcurl no longer allows them to be different. But, given a real-world case where they need to be different, we could possibly resurrect that support.

[wd]

yeah, I have tested that, grpcurl is not supported to set them both.

Cannot specify different values for -servername and -authority.
Try 'grpcurl -help' for more details.

[hanyouqing]

Hi @jhump , any progress on this issue?

[jhump]

@hanyouqing, no progress.

For one, this is not possible using the gRPC runtime for Go -- the ability to use different hostnames for the TLS servername vs. the authority was removed in https://github.com/grpc/grpc-go/pull/4817. So the extra validation of command-line args in grpcurl was added shortly thereafter in #130. I don't expect there is any intent in the gRPC team to change this behavior. Working around this limitation would likely be non-trivial. It is likely possible to make it work with some shenanigans and both a custom dialer and custom transport credentials.

For two, as of last July, I am no longer a maintainer/committer for FullStory open-source projects. I still watch the repo and try to answer questions, but I haven't made any material contributions in some time and don't really plan to either. (Maybe someone else at FullStory could be persuaded to look into this?)

FWIW, the Connect runtime for Go would likely be better for grpcurl to use eventually, instead of the official gRPC runtime. Not only does it support gRPC (in addition to Connect and gRPC-Web protocols), it is also much simpler and leaner, leveraging net/http instead of a bunch of custom transport code, and thus allows doing stuff like requested in this issue without wild and involved work-arounds.

[dragonsinth]

@wd @hanyouqing I think the most sane option is to configure your servers to do something reasonable. In the example cited, grpcurl -v --authority=test.abc.com lb.abc.com:443 list, you would want your server to:

a) examine the TLS handshake header and provide an appropriate test.abc.com cert b) understand how to route test.abc.com to the appropriate handler

This is just kinda basic sane HTTPS setup, and it's hard to see the value in grpcurl doing something super strange to support an oddball test setup.

If you're unable change your setup, I recommend you either use -insecure to ignore the TLS verification error, or else build your own binary from source, and right around creds = credentials.NewTLS(tlsConf), add something like:

tlsConf.VerifyPeerCertificate = func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {
	// TODO: custom TLS verification
	return nil
}