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

Xue-Lei Andrew Fan xuelei at openjdk.org
Thu Aug 18 15:44:21 UTC 2022


On Thu, 18 Aug 2022 13:44:49 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 409:
>> 
>>> 407:             if (shc.sslConfig.preferLocalCipherSuites) {
>>> 408:                 preferred = shc.activeCipherSuites;
>>> 409:                 proposed = clientHello.cipherSuites;
>> 
>> Instead of wrapping all information in one block, I may prefer to break down and place them in the close place where is happens.
>> 
>> I may dump the debug log here for cipher suite preference and server activated cipher suites.
>
> Intend to log all of the collected information in one place. It is easy for the developer to see the configuration of the server socket. Previously when the handshake is failing, no information is available for the server socket in the log file.

So, do you want to make the log where the configuration happens?  Logging in one place cannot have the accuracy debug log where the problem happens, and cannot easy the analysis of the debug.  One just gets the configuration information, but did not get the code line numbers and processes why the information is not good.  We can have all log in one place for the TLS implementation, and tell the log reader to analysis the configuration by himself, but the style was not chosen because more debug information was expected to carry in the log.

>> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 416:
>> 
>>> 414: 
>>> 415:             List<CipherSuite> legacySuites = new LinkedList<>();
>>> 416:             boolean CSFound = false;
>> 
>> This variable may be not necessary if the debug log has been broken down into multiple place.
>
> There are two failing scenarios, one is "no common cipher suite" between the client and server and the other is the failure of key exchange after the server finds the shared cipher suites with the client. We are using the flag to give the developer a more specific error message.

I see, but could you make it without define a variable that is purely for debug?

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

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



More information about the security-dev mailing list