auto-set ALPN when using GetConfigForClient

[howardjohn]

Use case(s) - what problem will this feature solve?

In grpc-go v67, the client will reject servers not advertising ALPN=h2.

Typically, gRPC will automatically set this on the tls.Config passed in on the serverside. However, when GetConfigForClient is used, it will not.

Proposed Solution

Make GetConfigForClient usage automatically set alpn=h2

Alternatives Considered

• Change application to explicitly set ALPN
• Deploy all clients with GRPC_ENFORCE_ALPN_ENABLED=false. This is not great since it will probably go away(?) and you don't always control the clients.

Additional Context

Previous issue, stale-closed: #5814. Likely not a priority since it didn't hurt most users until the client's started denying

Popular projects broken by this:

• fix: expose ALPN in TLS handshake cert-manager/istio-csr#422
• Find a way to use grpc-go >= 1.67.0 with ALPN disabled siderolabs/talos#9463

[purnesh42H]

@howardjohn could you clarify what did you expect and what did you see instead? We currently by default Enforce ALPN so clients and servers will now reject TLS connections that don't support ALPN. However, this can be disabled by setting the environment variable GRPC_ENFORCE_ALPN_ENABLED to false (case insensitive)

[howardjohn]

When i setup a gRPC server with something like &tls.Config{}, and pass this to gRPC, it automatically adds NextProtos=[]string{h2}. This means that ALPN works and will not be rejected.

If I instead pass &tls.Config{GetConfigForClient: func() { ... }, the tls.Config will be used directly from the result of the function, and NOT get the NextProtos set, meaning there will be no ALPN, and clients will reject things.

A server can workaround this by manually setting Nextprotos on the resulting tls.config, of course, but its something many projects are not doing since they didn't need to prior to 0.67.

[purnesh42H]

@howardjohn you are correct. We need to do the same modifications to config returned by GetConfigForClient as well

[arjan-bal]

The fix is expected be released as part of grpc-go v1.69 since we've already cut the branch for 1.68.