On Fri, 19 Mar 2021 12:45:43 GMT, Sean Mullan <[email protected]> wrote:
>> @XueleiFan I'd really like to move this forward but I'm uncertain what >> changes you want me to make. This extra debugging information will be very >> valuable to those of us debugging Java TLS connections. > > I am also not comfortable adding this feature to the JDK, especially since > every build of the JDK would by default have this feature enabled. Logging > sensitive information to log files is not good security practice (there are > many references I could cite). I also think it would be too easy to > accidentally leave the system property enabled or forget to remove the file. I think that there might be some confusion around the sensitivity of the data being logged. The security impact of this data is almost identical to passing `-Djavax.net.debug=plaintext,packet` to the JVM. This existing setting logs all plaintext (as well as wire-data) to STDERR. The new feature I'm proposing just lets a second application decrypt the wire-data to access the plaintext, which results in the same level of exposed data. (As an improvement over the existing feature, it outputs the data in a standardized format so that it is easier to analyze rather than being in a Java-specific format and co-mingled with all other STDERR output.) Similar to the existing feature, the data logged only impacts the exact connections that it is enabled for. (These are ephemeral session-specific secrets). I hope that this helps to ease some concerns and help explain why this exact feature is present in so many existing applications (including OpenSSL, BoringSSL, WolfSSL, s2n, Mozilla, and Chrome, among others). If you would like to try it with your current Chrome browser, just add ` --ssl-key-log-file=/path/to/chrome_keys.txt` to the command-line. For Firefox, I believe you need to set the `SSLKEYLOGFILE` environment variable to the name of the log-file. ------------- PR: https://git.openjdk.java.net/jdk/pull/2896
