RFR: 8357033: Reduce stateless session ticket size [v2]
Artur Barashev
abarashev at openjdk.org
Tue May 20 14:51:54 UTC 2025
On Tue, 20 May 2025 10:02:44 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:
>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Log error and return null no compress/decompress failure
>
> src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java line 421:
>
>> 419:
>> 420: SSLPossession pos = X509Authentication.createPossession(
>> 421: hc, certAlgs);
>
> Are you trying to select the same certificate that was used in the original handshake? That's an interesting approach. Are you confident that this will produce the same possession as the original handshake, assuming that the ClientHello is the same and the KeyManager certificates did not change?
>
> I think you only need the certAlg of the first certificate in the chain for createPossession.
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. When resuming client doesn't include `signature_algorithms` and `signature_algorithms_cert` extensions with ClientHello which affect how the original certificate was selected.
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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25310#discussion_r2098184133
More information about the security-dev
mailing list