litespeedtech/openlitespeed

Does an expired session ticket key file just get renewed if unchanged?

sumezulike opened this issue · 2 comments

Hi, the below code seems to suggest that the same session ticket encryption key is just used for another ticket lifetime if the file was not changed in the meantime, which is not at all good for forward security.
Is there another mechanism to disable stale keys that I am missing?

if (st.st_mtime < pShmData->m_tmLastAccess)
{
pCur->expireSec += (m_iLifetime >> 1);
m_pKeyStore->unlock();
LS_DBG("[SSLTicket] File was not modified");
return LS_OK;
}

On a related note, the docs seem to be missing the sslSessionTicketKeyFile configuration completely, is that option meant to be deprecated?

Best regards

EDIT:

To expand a bit, SslTicket::ticketCb calls SslTicket::checkShmExpire if the current key needs renewal, with the same condition as SslTicket::onTimer above.
checkShmExpire replaces the current key if it is expired, but since onTimer will always add to the lifetime of the key, that just means it doesn't get rotated?
That behavior might be worth documenting.
It might also be more secure to disable session tickets until a fresh one is provided, like s2n does or replace it with a random one like mbedTLS.

If session ticket file is used, maybe due to a cluster sharing the traffic, it is the responsibility of the user to update/sync the session ticket file, it cannot be renewed automatically.
If use the built-in SHM session ticket, it is rotated automatically, the timestamp only updates when the key has been updated. At lest, the code is intended to do that. If you found otherwise, please elaborate.
https://www.openssl.org/docs/man1.0.2/man3/RAND_bytes.html is cryptographically strong pseudo-random bytes, do not see any need to change.

Hi, thanks for the response!
I was only referring to files, I didn't look at the built-in keys.
I was just reading the code to find out how key rotation would be handled for session ticket key files, since I couldn't find that in the docs.
Might be an oversight on my end, in that case I'd be grateful about a link to the relevant page.
Either way, your response answers the question I had, thank you.