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

Support session tickets on client, RFC 5077 #14425

euroelessar opened this Issue Feb 14, 2018 · 4 comments


None yet
5 participants
Copy link

euroelessar commented Feb 14, 2018

Please answer these questions before submitting your issue.

Should this be an issue in the gRPC issue tracker?

Create new issues for bugs and feature requests. An issue needs to be actionable. General gRPC discussions and usage questions belong to:

Please don't double post your questions in more locations; we are monitoring both channels, and the time spent de-duplicating questions is better spent answering more user questions.

What version of gRPC and what language are you using?

grpc-core 1.8.4, both python grpcio & proprietary rust binding on top of grpc-core

What operating system (Linux, Windows, …) and version?


What runtime / compiler are you using (e.g. python version or version of gcc)


What did you do?

  • Create single client pointed to server.
  • Restart server on different port.
  • After restart client reconnects to server.

What did you expect to see?

Client should resume previously established tls session using ticket issued by server.
It happens if client uses grpc-go library.

What did you see instead?

Client sends ClientHello to server with empty tls ticket extension, they have to go through full tls handshake again.

After further investigation it looks like grpc-core provides neither tickets support on client/server by default nor any means to configure it.

One of possible suggestions is to add the following interface & re-expose it from python and wire it up with boringssl session ticket support. The expectation is that user creates cache once & passes it to different channels via creation arguments.

#define GRPC_SSL_SESSION_CACHE_ARG "grpc.ssl_session_cache"

/** Increase reference counter for the session */
GRPCAPI void grpc_ssl_session_ref(grpc_ssl_session* session);
/** Decrease reference counter for the session */
GRPCAPI void grpc_ssl_session_unref(grpc_ssl_session* session);

/** SSL session cache for session tickets (RFC 5077).
 *  Implementation must be thread safe.
typedef struct grpc_ssl_session_cache {
     * Put is called by grpc-core to store session by the given key.
     * Caller owns the session, so cache implementation should call
     * `grpc_ssl_session_ref`.
    void (*put) (const char* key, grpc_ssl_session* session);
     * Get session for the given key from the cache (if any).
     * Caller owns returned session, so cache implementation should call
     * `grpc_ssl_session_ref` on session before returning one.
    grpc_ssl_session* (*get) (const char* key);
} grpc_ssl_session_cache;

Other ideas are welcome.

Anything else we should know about your project / environment?


This comment has been minimized.

Copy link

jiangtaoli2016 commented May 16, 2018

@nathanielmanistaatgoogle We need to get this moving forward. Assign to you. Let me know if you need help.


This comment has been minimized.

Copy link

nathanielmanistaatgoogle commented May 24, 2018

@jiangtaoli2016: it looks like this is happening in pull request 14879, which is currently blocked on a pretty big deal, and about which I hope to respond in the next day or two.


This comment has been minimized.

Copy link

nathanielmanistaatgoogle commented Jun 12, 2018

The upcoming 1.13 release will include pull request 14879. @euroelessar, @jiangtaoli2016: is there anything to be done for this issue other than wait for the 1.13 release?


This comment has been minimized.

Copy link

mehrdada commented Jul 26, 2018

Closing this bug as 1.13 is already released. Please reopen or file another issue if there's any work item still needs to be done in this area.

@mehrdada mehrdada closed this Jul 26, 2018

@lock lock bot locked as resolved and limited conversation to collaborators Oct 24, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.