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

[Sean Coffey]

On Fri, 26 Aug 2022 14:51:48 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> 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.
>
>> ... on your "preference of client or server suites" data point question ....
> 
> It is not expected to break the connection by changing the preference even there are multiple key exchange algs.  There may be bugs, but did you see failures caused by preference in practice?   BTW, the information is logged when ServerHello failed, and it will not be logged if the process goes to key exchange handshake message point.
> 
>> They're all important data points before leading up the initial ServerHello response message. 
> 
> I agreed that there are all important data points.  I'm just not sure if it is the right approach to dump on ServerHello failure.

No - I haven't seen any such handshake failures as a result of the cipher suites preference. Just a theory.

OK - let's have a think about the what the best approach is for the logging frequency of such server-side data points. Perhaps another suggestion is to log such data for scenarios where the server issues a fatal alert during any part of the  handshake phase. Let me have a chat with Weibing and others and revert back.

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

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