On Fri, 26 Aug 2022 14:51:48 GMT, Xue-Lei Andrew Fan <xue...@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
