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

[Xue-Lei Andrew Fan]

On Thu, 25 Aug 2022 20:00:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Even the cipher suites are the same between client and server, it may still fail with "no common in cipher suites" error.  The cause of the bug is not only about "no common in cipher suites" between client and server, but also about the cases that the server cannot negotiate any of the common cipher suites because of other facts.  If the cause is only about ""no common in cipher suites", I don't think we need a fix as the message has been tell the story.
>> 
>> It is not objected that cipher suite should not be logged.  The question raised here is about when and how to log the cipher suite, and how to make the log easier to read and easier to debug.
>
> @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!

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

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