On Tue, 20 May 2025 10:02:44 GMT, Daniel Jeliński <djelin...@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
