Lighttpd

is the only way to disable the tickets:
ssl.openssl.ssl-conf-cmd = ("Options" => "-SessionTicket") ?

Hi,

the commit with == 0 start does not solve these issues.

I did some debugging and it seems that the time is changed to past or future the tokens become invalid and no new token will be generated if the time of last geneation is not expired.

This leads to the problems I have seen. Since no new ticket is generated until the time is expired or ticket becomes valid again.

Regarding RFC 5077 https://datatracker.ietf.org/doc/html/rfc5077

Section 3.2
https://datatracker.ietf.org/doc/html/rfc5077#section-3.2

"If the server fails to verify the ticket, then it falls back to
performing a full handshake. If the ticket is accepted by the server
but the handshake fails, the client SHOULD delete the ticket."

But lighttpd does not fall back to default behaviour (handshaking).

Am I totally wrong or is this really a bug?

If you only tested with one cherry-picked commit, then you did not do as I asked, which was to test with lighttpd git master.

I repeat what I posted above:

Please test with lighttpd git master. https://git.lighttpd.net/lighttpd/lighttpd1.4.git/

The TLS library should fall back to perform a full handshake if the server fails to verify the ticket. Note well that I wrote "TLS library" and I did not write "lighttpd". lighttpd registers a callback and provides an appropriate return value to openssl, depending on whether or not lighttpd has a valid session ticket encryption key to decode the ticket provided by the client. lighttpd might be configured with session ticket encryption keys synchronized across servers, and so must use "real-time" instead of monotonic clock for session ticket encryption key expiry.

Does disabling session tickets "fix" the issue for you?

lighttpd supports multiple TLS modules (lighttpd TLS docs). You should test using lighttpd git master and one of mod_gnutls or mod_mbedtls, in addition to mod_openssl.

lighttpd TLS modules periodically check every 64 seconds (0x3f) to see if session tickets have expired or stapling files need to be refreshed.

If your clock jumps a large amount (e.g. > 1 day), then session ticket encryption keys generated by lighttpd may be expired for up to 64 seconds until lighttpd will notice and will generate new session ticket encryption keys. In the meantime (up to 64 seconds), the TLS library should fall back to a full handshake.

.

Aside: Note that if your clock jumps a large amount, that is a you problem, not a lighttpd problem. lighttpd does attempt to recover, but it would be better if you restarted appropriate system services when you trigger a large clock jump. See also the discussion in #3075. Embedded devices are systems, and the words "embedded device" does not constitute a valid excuse for suggesting that time keeping is someone else's problem. Time-keeping on your system is your problem, not lighttpd's problem. lighttpd uses the system time, as do other system services/daemons.

Thanks for the response.

Does disabling session tickets "fix" the issue for you?

I also observed what you describe so if time is set to future it takes 64 seconds until the communication is working again.
If the time is tuned into the past the conenction is "lost" until the ticket becomes valid again or a new one is generated (<8h).

We will continue to use lighttpd without Session Tickets for now, but we will look into it deeper with the upcoming releases.

Thanks for Support

What version of openssl libraries are you using? As of 1 Jan 2020, only openssl 1.1.1 and later continue to receive security patches from openssl.org

We are using openssl 1.1.1k

If the time is tuned into the past

I think the correct phrasing is "If time is corrupted and moves backwards by a large amount".

Perhaps you should consider keeping the system time to UTC, and allowing the user to set TZ for display to the user. Those are different things.

.

As I posted above, you should test with lighttpd mod_gnutls or mod_mbedtls in addition to mod_openssl. I have not reproduced your corrupt system. My system works with Firefox client, lighttpd (git master), and openssl 1.1.1k when I force there to be no valid session ticket encryption keys. Even when there are no valid session ticket encryption keys, openssl libraries should fallback to full handshake. Your client might be stuck. After you change the time, open a new Chrome browser on a different machine, and try connecting.

In the future, I might include detection for broken systems which jump time backwards by large amounts. The following (untested) patch should trigger session ticket encryption key regeneration when time moves backwards > 28800 seconds, detected during lighttpd periodic checks (once every 64 seconds)

--- a/src/mod_openssl.c
+++ b/src/mod_openssl.c
@@ -440,6 +440,11 @@ mod_openssl_session_ticket_key_file (const char *fn)
 static void
 mod_openssl_session_ticket_key_check (const plugin_data *p, const time_t cur_ts)
 {
+    static time_t detect_retrograde_ts;
+    if (detect_retrograde_ts > cur_ts && detect_retrograde_ts - cur_ts > 28800)
+        stek_rotate_ts = 0;
+    detect_retrograde_ts = cur_ts;
+
     int rotate = 0;
     if (p->ssl_stek_file) {
         struct stat st;