I’m trying to modify one of auth modules for nginx and I need to get
content
of either ssl_session_id or any other ssl_* variables with uniq client
id to
identify connection. But I’ve got a problems with accessing to this
variables from lua.
For testing purposes I’m using self-signed ssl cert.
ngx.log(ngx.DEBUG, “session_id=”, ngx.var.ssl_session_id) prints “nil”
in
the logs. How can I get access to this variable?
lua script is called with access_by_lua directive.
Thanks in advance!
P.S. If I do “set $test_session_id $ssl_session_id;” in config,
test_session_id var is also empty.
On Wed, Nov 26, 2014 at 8:29 AM, VladimirSmirnov wrote:
For testing purposes I’m using self-signed ssl cert.
ngx.log(ngx.DEBUG, “session_id=”, ngx.var.ssl_session_id) prints “nil” in
the logs. How can I get access to this variable?
It’s very likely that your client sends TLS session tickets (in
addition to session IDs) and server-side OpenSSL prefers the former
(and ignores the latter, if any). I can reproduce the nil value when
my SSL client sends the TLS session tickets.
One quick way for testing non-empty $ssl_session_id values is to temporarily make your nginx https server support the SSLv3 protocol only (so as to disable TLS session tickets at all). This can be
achieved by adding the following line to your corresponding server {}
block:
ssl_protocols SSLv3;
And then your example produces the expected debugging log message like
this:
Well, this is just a hacky way to quickly test this thing. Do not use
SSLv3 exclusively in production! TLS session tickets are way more
effective (and cheaper) than SSL session IDs (if available).
BTW, for such ngx_lua questions, please post to the openresty-en
mailing list in the future instead. See OpenResty® - Open source for details. That way you may get
responses faster and get more responses than posting here.
On Thu, Nov 27, 2014 at 12:07 AM, VladimirSmirnov wrote:
P.S. As pointed by resty.session author, I’ve disabled ssl_session_ticket
and now I’m receiving ssl_session_id even with TLS enabled. But I’m not sure
that it’s best way to deal with this problem.
No, you don’t really want this. To quote my warning in my previous
email:
“Well, this is just a hacky way to quickly test this thing. Do not use
SSLv3 exclusively in production! TLS session tickets are way more
effective (and cheaper) than SSL session IDs (if available).”
Disabling session tickets to force sessions IDs is a complete loss.
The session tickets are almost always preferred.
P.S.S. I’ve used this mail-listing, because it’s not Lua-related problem.
The openresty-en mailing list is not a Lua-specific list
Face the same problem, empty $ssl_session_id variable.
If ssl_session_ticket off, $ssl_session_id always contain ID.
How can I identify client connection if no ssl session id available?
I would also know answer for this. It is kinda either:
server and client store session id
or
client sends tickets that contains info how to continue without
server
storing anything
So with tickets you don’t have session id. I’m not sure could there
still
be some kind of identifier be counted from tickets that could be used as
a
identifier for multiple round trips, but I think not (?).
Yes, it sucks a little bit. With session_id we had nice way to identify
client built-in the protocol, with tickets it seems we don’t.
P.S. As pointed by resty.session author, I’ve disabled
ssl_session_ticket
and now I’m receiving ssl_session_id even with TLS enabled. But I’m not
sure
that it’s best way to deal with this problem.
P.S.S. I’ve used this mail-listing, because it’s not Lua-related
problem.
