RFR: 8350830: Values converted incorrectly when reading TLS session tickets

[Hendrik Schick]

On Wed, 9 Apr 2025 03:28:40 GMT, Nibedita Jena <duke at openjdk.org> wrote:

> Session resumption without server side state was added under [JDK-8211018](https://bugs.openjdk.org/browse/JDK-8211018).
> While it is TLSv1.2 session resumption, the client hello message is being parsed in SSLSessionImpl for each extensions.
> 
> Customer has reported handshake failure and is reproducible locally with exception NegativeArraySizeExceptions when there is ServerNameIndication with size > 127.
> According to RFC 3546, the host_name limit allowed is 255.
> With a sample testcase when the host_name length is > 127, exception is thrown:
> javax.net.ssl|DEBUG|71|Thread-1|2025-04-06 17:13:07.278 UTC|ClientHello.java:825|Negotiated protocol version: TLSv1.2
> javax.net.ssl|WARNING|71|Thread-1|2025-04-06 17:13:07.281 UTC|SSLSocketImpl.java:1672|handling exception (
> "throwable" : {
>   java.lang.NegativeArraySizeException: -1
>         at java.base/sun.security.ssl.SSLSessionImpl.<init>(SSLSessionImpl.java:399)
>         at java.base/sun.security.ssl.SessionTicketExtension$T12CHSessionTicketConsumer.consume(SessionTicketExtension.java:468)
> 
> e.g.
> int l = buf.get();
> b = new byte[l];  <-------------------- NegativeArraySizeException thrown here when > 127
> 
> For TLSv1.3, its not an issue until length > 255.
> 
> According to RFC 5077, PSK identity length allowed is <0..2^16-1> and so its value conversion being taken care of under this change.
> Master secret is allowed for 48 bytes - master_secret[48], shouldnt be an issue.

test/jdk/sun/security/ssl/SSLSessionImpl/ResumeClientTLS12withSNI.java line 389:

> 387:         final byte[] sessionId = engine.getSession().getId();
> 388:         // compare and verify if they are same
> 389:         if (java.util.Arrays.equals(expected, sessionId)) {

import java.util.Arrays ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24535#discussion_r2034442819