Set $ssl_session_reused to "t" for session ticket reuse and set $ssl_session_id with session tickets

[Neil Craig]

Hi

I've got an NGINX setup which offers TLS session tickets which work just fine but i only found that out after a bit of digging because my access logging which logs $ssl_session_reused and $ssl_session_id showed nothing for either value and thus I thought session tickets were not working.

So, i'd like to ask if it's possible to perhaps extend/set as follows under session tickets:
$ssl_session_reused to "t" when session tickets are in use
$ssl_session_id to the session ticket ID

This would enable me and others to log (etc.) session ticket usage, otherwise it's a bit of blind faith.

It'd also be really nice to note in the docs (​http://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables) the current info is for the 1st gen server-side TLS sessions as i think it's perhaps a bit too implicit currently.

Cheers
Neil

[Maxim Dounin]

When using session tickets, there is such thing as "session ticket id" - tickets are just encrypted data. Session ID as available after a session is resumed using a ticket is an ID generated by the client, see ​RFC 5077:

   When presenting a ticket, the client MAY generate and include a
   Session ID in the TLS ClientHello.  If the server accepts the ticket
   and the Session ID is not empty, then it MUST respond with the same
   Session ID present in the ClientHello.  This allows the client to
   easily differentiate when the server is resuming a session from when
   it is falling back to a full handshake.  Since the client generates a
   Session ID, the server MUST NOT rely upon the Session ID having a
   particular value when validating the ticket.  If a ticket is
   presented by the client, the server MUST NOT attempt to use the
   Session ID in the ClientHello for stateful session resumption.
   Alternatively, the client MAY include an empty Session ID in the
   ClientHello.  In this case, the client ignores the Session ID sent in
   the ServerHello and determines if the server is resuming a session by
   the subsequent handshake messages.

As this ID is generated by a client when presenting a ticket, it is not available during first connection. Note that it may also not be available during subsequent connections, or be different in different connections.

In either case $ssl_session_reused will correctly show if session is reused or not (either using session cache or session tickets).

You can easily check if session tickets work using openssl s_client, e.g.:

$ openssl s_client -connect 127.0.0.1:8443 -reconnect
CONNECTED(00000003)
...
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 54 d2 3e 3b 32 c5 cd 1c-91 d8 4d 7a 7c 9d 24 f8   T.>;2.....Mz|.$.
    0010 - 4b 78 0c 3d 3f 20 ac aa-44 bb a7 ee 89 19 1f a7   Kx.=? ..D.......
...
drop connection and then reconnect
CONNECTED(00000003)
...
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 54 d2 3e 3b 32 c5 cd 1c-91 d8 4d 7a 7c 9d 24 f8   T.>;2.....Mz|.$.
    0010 - 4b 78 0c 3d 3f 20 ac aa-44 bb a7 ee 89 19 1f a7   Kx.=? ..D.......
...

It may make sense to introduce additional information to make it possible to find out if a session was reused using session tickets or session cache (and additional value in the $ssl_session_reused variables looks like a good solution). But an API to do this, SSL_SESSION_has_ticket(), is only available in OpenSSL 1.1.0, which is not yet released. And finding this in at least some previous versions would not be possible with OPENSSL_NO_SSL_INTERN defined.

[Neil Craig]

Apologies for the delay in response, i was assuming i'd get an email.

WRT session ID, i'd seen that in the openssl s_client output - understood.

WRT session_reuse - it would be massively helpful to have an indicator in the $ssl_session_reuse var as we'll have a large number of NGINX servers and thus checking them via openssl or similar is not practical in a trivial manner, also it would be extremely useful as a reporting metric in access logs (i am logging this value already). Perhaps it'd be possible to add this conditionally on the underlying SSL lib supporting it?

Cheers

[Neil Craig]

Hi again

Just wondered if the above might be worth looking at now that NGINX compiles against openssl 1.1.

Cheers