RFR: 8357033: Reduce stateless session ticket size [v2]

[Artur Barashev]

On Tue, 20 May 2025 16:28:42 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> If we use the same KeyStore and the same KeyManager then the certificate(s) will be the same most of the time but there is no guarantee of course:
>> 
>> 1. We can have different constraints in `java.security`
>> 2. Different `jdk.tls.server.SignatureSchemes` system property.
>> 
>> As far as I can tell local certificates are not being used by TLS layer after the handshake but they can be requested by application layers above such as HTTPS.
>> If having the same local certificate(s) for resuming the session is a requirement then I think we can add a few more bytes to the ticket as a certificate's fingerprint (`X509CertImpl.getFingerprint`) and then validate that fingerprint(s) against certificate(s) in the new possession. We then fall back to a full handshake if such validation fails.
>
>> As far as I can tell local certificates are not being used by TLS layer after the handshake but they can be requested by application layers above such as HTTPS.
> 
> Right, that matches my observations.
> 
>> If having the same local certificate(s) for resuming the session is a requirement then I think we can add a few more bytes to the ticket as a certificate's fingerprint (X509CertImpl.getFingerprint) and then validate that fingerprint(s) against certificate(s) in the new possession. We then fall back to a full handshake if such validation fails.
> 
> I'm not aware of any uses of the local certificates / local principal on the server side, but I'd err on the side of caution. The resumed session should either return the same certificates, or return an obviously wrong value (like null), so that users can detect unexpected values.
> 
> Checking the fingerprint and falling back to a full handshake sounds reasonable to me.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098922120