Hello, We deal with a regression in JSSE regarding resumption tickets with high lifetime. In older versions with Java 11 the customer claimed a FTP Server was reachable, with Java 21 the connections are rejected. Looking at the debug log of the new version, we can see a session resumption ticket was discarded, and in the followup the ftp#s data connection had a new belonged to a fresh session - and some FTP Servers dont like this.
So while looking into the source, I had a few questions: a) why do we discard those tickets at all, instead of just clamping their age to the 7d. Max ticket lifetime. According to the RFC the lifetime field is only a hint and both side are free to not use them after some time. In fact the Field was even named a „hint“ (in TLS 1.2) https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java#L654 b) I am not sure why there is a second Test for the lifetime of the Cache Ticket, I mean if it Never accepts those longlived Tickets, why does it need to remove them. Is that second Test maybe supposed to be an expire test, instead? https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java#L666 https://www.rfc-editor.org/rfc/rfc5077#section-5.6 C) the traced ticket had a lifetime hint of MAX_INT: NewSessionTicket": { "ticket_lifetime" : "2,147,483,647", … This sounds to me like a deliberate choice of the server implementation, if it wants to signal „lets see how Long I am valid, try it anyway“. Clamping only in this case would help Interop already (but I dont see a reason to limit it to this value.) Since we could not yet get our hands on a working trace, we are not sure where the regression is (that MAX_TICKET_LIFETIME seems to be introduced before the 11 Version and therefore is not the direct reason), has someone an idea, or observed this as well? Gruß Bernd — https://bernd.eckenfels.net
