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

Jump to bottom

crypto/tls: GetCertificate called on resumed sessions #25352

Open
FiloSottile opened this issue May 11, 2018 · 1 comment
Open

crypto/tls: GetCertificate called on resumed sessions #25352

FiloSottile opened this issue May 11, 2018 · 1 comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@FiloSottile
Copy link
Contributor

GetCertificate is called just before checking the client session ticket. If the ticket is valid and the session is resumed, that call is probably pointless.

Off the top of my head, I can't remember why the server would need to know its own certificate in a resumed session, but there might be something I'm forgetting around renegotiation. Look into it, and if possible move the GetCertificate call after checkForResumption.
@FiloSottile FiloSottile added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 11, 2018
@FiloSottile FiloSottile added this to the Go1.12 milestone May 11, 2018
@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@FiloSottile FiloSottile modified the milestones: Go1.14, Unplanned Oct 1, 2019
@FiloSottile FiloSottile mentioned this issue Oct 1, 2019
Closed
@rolandshoemaker
Copy link
Member

TLS 1.3 already has this behavior.

In TLS 1.2 during resumption there is a check that the ciphersuite from the resumed session is still acceptable. That check relies on the certificate private key type in order to determine if the suite uses an acceptable key exchange.

Presumably since the key exchange has already happened as long as the cipher is otherwise acceptable it's fine to just ignore whether it contains an acceptable key exchange since the shared secret has already been established and we don't need the cert key for another kex.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
3 participants
@andybons @FiloSottile @rolandshoemaker