RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3]

[Sean Coffey]

On Fri, 26 Aug 2022 04:31:59 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> @coffeys Before we go further, I think we'd better have a look if the information added could help for debugging.  I'm not sure of that now.
>> 
>>> With the new debug data, we have some extra data points like the ciphersuites actually enabled, the preference of client or server suites etc. Coupled with the ClientHello data, I think it helps piece together a better idea of the server side scenario.
>> 
>> If I understand correctly, the preference of client or server suites should not impact the success of handshaking.  Did you see examples otherwise in practice?   What's the purpose by adding this information for failed handshaking?
>> 
>> The client authentication type is also logged for failed server hello handshake message.  What's the purpose for the adding?  Did you see server hello failure that caused by client authentication type in practice?
>> 
>> With server debug log enabled, there have already been a lot debug information, especially for verberos debug mode.  Is it a really concern to you to dump server enabled cipher suites, just as the dump of ClientHello message?  Yes, it make debug logger worse for a busy server, but the impact may be 1/10K?
>> 
>> I have to run for now, and will try to reply more for your comments.  Thanks!
>
>> I've no strong preference on how often we print this debug data on server end. To cut back on log verbosity, perhaps on fatal/failing handshake scenarios is all that's required.
> 
> Does the switch on/off the "verbose", "data" or "record" debug option help to reduce the log verbosity?
> 
> In general, I'm not sure how on failing handshake scenarios could help to make the debug better.  Thinking about the failure of the ServerHello in this case, it could be related to ClientHello, named groups/key exchange algorithms, signature algorithms, key store, certificate signature, certificate key algorithms, certificate key length, etc.  If these information does not dump when the ClientHello is good, I'm not sure if the developer understand better about what could be the cause from the server cipher suite preference, client authentication types and server enabled cipher suites.  Well, we can dump everything in the printServerSocketConfig() method, but do we know everything in the context of printServerSocketConfig and is it easy to maintain the things in the method.  I'm not sure of that.

I think many engineers use the `-Djavax.net.debug=all` option for TLS debugging at moment. `-Djavax.net.debug=ssl` is pretty much broke. There's an open bug for that IIRC.

I revisited the ServerHello produce() code for TLSv12/TLSv13 to see if this approach was making sense. In general, I think it's a good addition to the debug logs. They're all important data points before leading up the initial ServerHello response message. Yes, further fatal errors are possible on the ServerSocket after that but the exception messages are more focussed for those scenarios IMO. Yes - it won't always give the user the full picture but it certainly gives more data about the enc the server socket is being created in.

on your "preference of client or server suites" data point question... fair point - it shouldn't be a major factor in establishing a TLS connection. What about the scenario where a server has multiple key exchange algs available ? wouldn't that boolean help deduce why one key exchange was preferred over another when a hand shake might have failed ?  It's a useful data point to help diagnose why such a failure occurred IMO. No harm at least.

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

PR: https://git.openjdk.org/jdk/pull/9731