envoy
envoy copied to clipboard
envoyproxy
[WIP] transportsocket: add interface to improve reusable tls session
Commit Message: For https://github.com/envoyproxy/envoy/issues/33512
Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional API Considerations:]
There probably needs to be a way to delete sessions when the associated Host is removed (by EDS update, etc).
Tracking the life of host is hard. If we can relax a bit, saying, upstream host is one of the potential tags instead of the owner, we can avoid coupling with host member changes.
Another advantage of not binding the life time of host, beyond original host cluster, is to resolve the hot spot issue. In this condition, if a fixed size cache is provided, it would be natural to provide more sessions for the hot host.
I am not against the idea of adding a per host session cache solution However, I wish we can have a shared by cluster solution first. WDYT?
Why would you want to keep the tls session if a host is garbage collected by OriginalDst? It seems best to discard it when that happens.
Some sessions are marked as "single-use". When that's the case, a per-worker cache would make a lot more sense. In other cases, a shared cache may be better, although it'll have more contention.
Why would you want to keep the tls session if a host is garbage collected by OriginalDst? It seems best to discard it when that happens.
Some sessions are marked as "single-use". When that's the case, a per-worker cache would make a lot more sense. In other cases, a shared cache may be better, although it'll have more contention.
In some configuration, host should not own the ssl_session (aka ticket) because can be shared across various of remote host.
This case can be something at Envoy with "downstream TLS " setting static session_ticket_keys
If this is set, removing sessions with host removing would be a lose
Regarding single use, I read that TLS 1.3 session is only single use, but in my experiment I see session reuse is always reused.
It can be easily reproduced by setting envoy as TCP proxy, downstream plain text and upstream TLS. and the tcp client to this envoy is establishing connection in sequence.
By single-use definition the reuse rate should be < 50% but what I see is only first session is fresh new. And all the following is reused.
Regarding single use, I read that TLS 1.3 session is only single use, but in my experiment I see session reuse is always reused.
It can be easily reproduced by setting envoy as TCP proxy, downstream plain text and upstream TLS. and the tcp client to this envoy is establishing connection in sequence.
By single-use definition the reuse rate should be < 50% but what I see is only first session is fresh new. And all the following is reused.
I believe the flow for TLS 1.3 is that the session is reused, and the server sends the client a new session immediately, so the next connection can also remove with the new single-use ticket.
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!