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

[Xue-Lei Andrew Fan]

On Thu, 25 Aug 2022 21:03:35 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> @XueleiFan  - I think it's fair to say that the current "no cipher suites in common" exception message is misleading for some scenarios. If not misleading, it's ambiguous. You could be dealing with a simple scenario where the server socket simply has no enabled cipher suites to match those coming in from the ClientHello. In the more complex scenario, something else has caused the fatal issues like a key exchange issue in TLSv1.2.  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.
>> 
>> 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. 
>> 
>> If you feel strongly about printing debug data for each TLSServerSocket handshake, (including the extra data points that you've suggested) then please shout now. I do feel it'll add considerably to log size on busy TLS Servers.
>
> @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.

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

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