bryancall opened a new pull request, #13711:
URL: https://github.com/apache/trafficserver/pull/13711
## Problem
`SSLOriginSessionCache::insert_session()` silently drops any origin TLS
session whose
ASN.1 form exceeds `SSL_MAX_ORIG_SESSION_SIZE`, a fixed **4096** bytes. When
that
happens nothing is cached, so every connection to that origin pays a full
handshake.
The rejection is reported only under the `ssl.origin_session_cache` debug
tag — no
metric, no warning — which is why it is easy to miss entirely.
4096 sits *inside* the range real origins produce. A serialized session
carries the
origin's certificate and the session ticket the origin issued, so its size
is chosen by
the origin, not by us.
## Measurements
Taken from a production edge host:
| Origin sample | `i2d_SSL_SESSION` |
| --- | --- |
| 15 ordinary origins | 1758 – 4604 bytes (median 3620) |
| …of which already over 4096 | **2 of 15** |
| 3 mutual-TLS origins | **5463 bytes** each |
mTLS is reliably over the line: a stateless ticket has to encode the client
certificate
in order to resume the authenticated session, so the client cert lands
inside the
ticket. On that host the effect was total — **0 cache hits against 6,962,377
lookups**,
and `proxy.process.ssl.origin_session_reused` flat at zero.
## Change
Replace the fixed limit with
`proxy.config.ssl.origin_session_cache.max_session_size`,
default **8192**, bounded at **65536**.
The upper bound is load bearing rather than arbitrary: `insert_session()`
checks the
size immediately before calling `SSLSessionDup()`, whose portable path
`alloca()`s a
buffer of exactly that size. `SSLSessionDup()` has exactly one caller, so
bounding the
record bounds the allocation.
## How it got here
The limit arrived in #8330, when the cache stored sessions as ASN.1 inside a
fixed
`IOBufferData`. #8498 then replaced that storage with a
`shared_ptr<SSL_SESSION>` and
removed the buffer the limit was guarding — but the check stayed behind. It
has been
4096 in every branch since.
## Testing
New autest `tls_origin_session_reuse_large`, with an origin presenting a
4328-byte
certificate, which yields a 4720-byte session:
- at the new default — `reused session to origin`, no size rejection;
- with `max_session_size: 4096` — `size of 4720 exceeds the max of 4096` and
no reuse,
reproducing current behavior.
It cannot pass vacuously: the second case only passes if the session
genuinely exceeded
4096, and the first only if that same session was then cached.
Locally green: `tls_origin_session_reuse_large`, `tls_origin_session_reuse`,
`records_yaml`, `records_config_to_yaml`. Draft so CI can run the rest.
## Notes
- Worth backporting — this is a silent behavior fix, not a feature.
- Unrelated but noticed nearby: `HAVE_SSL_SESSION_DUP` is referenced only in
`SSLUtils.cc` and is never defined by the build in any branch, so
`SSL_SESSION_dup()`
is never used and the `i2d`/`alloca`/`d2i` path is always taken. Left
alone here;
happy to file it separately.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
