-
Notifications
You must be signed in to change notification settings - Fork 574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find a way to use grpc-go >= 1.67.0
with ALPN
disabled
#9463
Find a way to use grpc-go >= 1.67.0
with ALPN
disabled
#9463
Comments
grpc-go >= 1.67.0
with ALPN
disabled.grpc-go >= 1.67.0
with ALPN
disabled
My first question - does Talos set up TLS wrong way so that it's not ALPN-enabled? We should fix it in the first place. |
@smira just stumbled upon this while working on another project. I found if you use GetConfigForClient you may not get the ALPN set properly. See cert-manager/istio-csr#422 |
Thank you, that should be the case for us, as we do live cert reload. |
Bump grpc library to 1.67.1 and ensure that we set proper HTTP/2 ALPN value. Closes siderolabs#9463 Depends on siderolabs/crypto#34 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Bump grpc library to 1.67.1 and ensure that we set proper HTTP/2 ALPN value. Closes siderolabs#9463 Depends on siderolabs/crypto#34 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
So this is actually interesting: basically all relevant code in Talos uses credentials.NewTLS which internally uses AppendH2ToNextProtos which ensures that we have "h2" in TLS config. Actually all clients and servers, use it. Except in our crypto library we indeed use GetConfigForClient which drops doesn't carry those changes to What is good, is that even before gRPC 1.67.0 the client would send the proper "h2" tag during negotiation. It should have warned us about incorrect ALPN settings even on v1.65.0 gRPC but I guess we are silencing that log somewhere. I also have no idea how that works in the first place, since Go TLS negotiateALPN should revert to http/1.1 if there is no proper ALPN. Edit: look like in |
Bump grpc library to 1.67.1 and ensure that we set proper HTTP/2 ALPN value. Closes siderolabs#9463 Depends on siderolabs/crypto#34 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Bump grpc library to 1.67.1 and ensure that we set proper HTTP/2 ALPN value. Closes siderolabs#9463 Depends on siderolabs/crypto#34 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Bump grpc library to 1.67.1 and ensure that we set proper HTTP/2 ALPN value. Closes siderolabs#9463 Depends on siderolabs/crypto#34 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Bump grpc library to 1.67.1 and ensure that we set proper HTTP/2 ALPN value. Closes siderolabs#9463 Depends on siderolabs/crypto#34 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Whatever way we end up with fixing it, we should have a way for 1.9 |
Bump grpc library to 1.67.1 and ensure that we set proper HTTP/2 ALPN value. Closes siderolabs#9463 Depends on siderolabs/crypto#34 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
So at the end of the day, Omni needs |
Fixes siderolabs#9463 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Fixes siderolabs#9463 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Fixes siderolabs#9463 Signed-off-by: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com> (cherry picked from commit 7ff1ced)
Starting with v1.67.0 Go gRPC implementation no longer work with TLS connections that don't support ALPN. There is a special header
GRPC_ENFORCE_ALPN_ENABLED
which, when set tofalse
, should disable this behavior. But setting it after the process started (even ininit
block) has no effect, because relevant variable initialization happens before any init blocks.The text was updated successfully, but these errors were encountered: