-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
quic: do not hard code "h3" APLN in EnvoyQuicProofSource #18935
Comments
I'm not surprised that quic::ProofSource doesn't have the ALPN, but I'm slightly surprised that it might need it. Can you say more about why we need ALPN from ProofSource as opposed to from, say, quic::QuicSession? |
EnvoyQuicProofSource does filter chain retrieval in order to get certs or private key to sign. And the FilterChainManager needs ALPN as part of the query. We might not have to expose ALPN directly in ProofSource, but something that can expose ALPN, i.e. QuicSession or a context object. |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions. |
need a non-stale label |
QUICHE interfaces in quic::ProofSource doesn't pass around ALPN negotiated by BoringSsl, but Envoy filter chain retrieval uses ALPN as part of the query. Right now, we hard-code h3 as the ALPN when we construct a ConnectionSocket for server session, but we should make the negotiated APLN available from QUICHE, and use it in Envoy glue code.
The text was updated successfully, but these errors were encountered: