Opened 7 years ago

Closed 7 years ago

#1338 closed defect (invalid)

ssl_session_cache get incorrect shm zone

Reported by: uvuv@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.12.x
Keywords: ssl Cc: yoyo@…
uname -a: Linux localhost.localdomain 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx/1.12.0 and all released

Description

ssl session of b.com will set to shm zone SA !!!!!!!!

conf:
server {
listen 443 ssl;
server_name *.a.com;
ssl_session_cache shared:SA:5m;
......
}

server {
listen 443 ssl;
server_name *.b.com;
ssl_session_cache shared:SB:5m;
......
}

fix1:
ngx_http_ssl_servername:

if (sscf->ssl.ctx) {
......
c->ssl->session_ctx = sscf->ssl.ctx;
}

or fix2:
ngx_ssl_new_session:
ngx_ssl_get_cached_session:
replace c->ssl->session_ctx by SSL_get_SSL_CTX(ssl_conn);

or both.

Change History (5)

comment:1 by uvuv@…, 7 years ago

also ngx_ssl_session_ticket_key_callback

comment:2 by Maxim Dounin, 7 years ago

Resolution: invalid
Status: newclosed

Session resumption happens in the context of the default server. This is how OpenSSL works, and there isn't much we can do about this.

Note well that the "fixes" suggested won't actually fix anything, but will break such configurations instead. See 97f102a13f33 and ticket #235 for additional details.

comment:3 by uvuv@…, 7 years ago

How to config different shm for servers.

new session callback called at SSL_ST_OK, and it after ngx_http_ssl_servername;
ngx_ssl_new_session get ssl context for the current server config, not the default config.
I don't use the origin ssl context is a good idea.

Version 4, edited 7 years ago by uvuv@… (previous) (next) (diff)

comment:4 by uvuv@…, 7 years ago

Resolution: invalid
Status: closedreopened

comment:5 by Maxim Dounin, 7 years ago

Resolution: invalid
Status: reopenedclosed

As already explained, session resumption happens in the context of the default server. The SNI callback (ngx_http_ssl_servername()) is called only after the session is either resumed or not. That is, if a default server uses cache A, and some SNI-based virtual host uses cache B, you will be able to store a session to B, but won't be able to resume this session - as cache A will be used during session resumption (because it happens before the SNI callback).

Accordingly, if for some reason you want to configure different session caches in different servers, you have to use real servers with different listen sockets (usually, servers listening on different IP addresses), and not just SNI-based virtual servers.

Note: See TracTickets for help on using tickets.