SSL: workaround for saving big sessions from upstream servers #536
Conversation
|
For the record, this was previously discussed in |
|
For simplicity, we could just increase |
|
Rewrote by moving from stack to BSS. |
| @@ -1024,8 +1024,6 @@ ngx_http_upstream_save_round_robin_peer_session(ngx_peer_connection_t *pc, | |||
| ngx_log_debug1(NGX_LOG_DEBUG_HTTP, pc->log, 0, | |||
| "old session: %p", old_ssl_session); | |||
|
|
|||
| /* TODO: may block */ | |||
There was a problem hiding this comment.
There's no direct evidence as to what exactly could block here. I'd leave this as is, but removing the comment is also fine for me.
There was a problem hiding this comment.
That's why I used "appears to be".
Although I don't insist to remove the comment,
leaving it as as, without a knowledge for what it served makes no good as well.
See 3d2fd18, where ngx_ssl_free_session was previously surrounded inside locking comments.
All such transient buffers are converted to the single storage in BSS. In preparation to raise the limit.
Upstream SSL sessions may be of a noticeably larger size with tickets in TLSv1.2 and older versions, or with "stateless" tickets in TLSv1.3, if a client certificate is saved into the session. Further, certain stateless session resumption implemetations may store additional data. Such one is JDK, known to also include server certificates in session ticket data, which roughly doubles a decoded session size to slightly beyond the previous limit. While it's believed to be an issue on the JDK side, this change allows to save such sessions. Another, innocent case is using RSA certificates with 8192 key size.
0edb752 to
bd87d14
Compare
|
Addressed @arut comments, then commit logs slightly massaged. |
This makes it easier to understand why sessions may not be saved in shared memory due to size.
It appears to be a relic from prototype locking removed in b0b7b5a.
This series implements a workaround for JDK servers, and related commits.
For JDK internals, see SSLSessionImpl.java in openjdk/jdk@94e1d7530ff