Skip to content
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

Possibly using the wrong .SessionTicketsDisabled field #4029

Closed
MarcoPolo opened this issue Aug 14, 2023 · 1 comment · Fixed by #4030
Closed

Possibly using the wrong .SessionTicketsDisabled field #4029

MarcoPolo opened this issue Aug 14, 2023 · 1 comment · Fixed by #4030
Labels

Comments

@MarcoPolo
Copy link
Collaborator

It seems like we're only using the .SessionTicketsDisabled field from the initial tls.Config, but we should perhaps be using the field from the tls.Config we get for a specific client if we have tls.Config.GetConfigForClient set. This would allow the server to support session tickets generally, but disable them for certain clients.

That said, I'm not sure if that's actually useful though. So it might also be okay if this wasn't supported.

I took a quick look at what would be required to change this, and I'm not sure it would be easy. The tls.Config for a specific client seems internal to crypto/tls.

@marten-seemann
Copy link
Member

You're right. The only "clean" option would be wrapping GetConfigForClient and keeping track of which config is actually in use, which would add a lot of complexity.
This check should probably be performed inside the standard library, and I've opened golang/go#62032 for that.

For now, quic-go can do an error assertion, so this error doesn't end up closing the connection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants