RFR: 8044609: javax.net.debug options not working and documented as expected [v10]

[Bradford Wetmore]

On Mon, 25 Nov 2024 12:52:35 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLLogger.java line 159:
>> 
>>> 157:         }
>>> 158: 
>>> 159:         if (checkPoints.equals("ssl")) {
>> 
>> I always thought that the `ssl` options were additive.
>> 
>> The presence of `ssl` in the property outputs those debug statements which only have `ssl` defined.  The presence of additional options turns on additional debug info. i.e. The property `ssl,handshake` turns on both `ssl` and `ssl,handshake` statements.  `ssl,handshake,verbose` turns on `ssl`, `ssl,handshake`, and `ssl,handshake,verbose` statements.
>> 
>> I **think** this style would eliminate these special cases, and the code would just go to the `split`/options loop after the EMPTYALL check.
>
> No, the `ssl `option is designed to return all debug statements except those that are extra verbose (`data`, `packet`, `plaintext`). At least that's how the old (JDK 7) and newer TLSv1.3 stacks have been implemented. (with the exception of bug 8044609 which is being addressed here!)
> 
> The `record`, `handshake`, `keygen`, `session`, `defaultctx`, `sslctx`, `keymanager`, `trustmanager ` options have always struck me as odd. I reckon no one uses them. The only logic I can see with them is as filtering operations, since the `all `or `ssl `option is mandatory.
> 
> I think the filtering option (if we choose to keep them) is the only purpose we can have for these sub options. 
> 
> I can't imagine telling users to use `ssl` for some TLS debugging but turn on `record` or `handshake` or `keygen` or `session` or `defaultctx` or `sslctx` or `keymanager` or `trustmanager` options if you fancy other bits of TLS debugging.
> 
> Happy to address your CSR comments shortly. Let's agree on the implementation some more first. Nice suggestion on that EMPTYALL value. I'll get that change in shortly.

> I can't imagine telling users...if you fancy other bits of TLS debugging.

That's exactly what I thought it was previously.  Have a look at the usage examples in the JSSE Ref Guide, [...To view the hexadecimal dumps of each handshake message, and to print trust manager tracing...](https://docs.oracle.com/en/java/javase/23/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-31B7E142-B874-46E9-8DD0-4E18EC0EB2CF)

This is just like what is done in the JDK `java.security.debug` property in [Troubleshooting Security](https://docs.oracle.com/en/java/javase/23/security/troubleshooting-security.html#GUID-4F9F7BB5-5C9E-4888-9E28-3017EF746FA0)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18764#discussion_r1857521444