Hello, I agree with the need for such a facility.
Instead, or in addition to a key log a session handshake listener with access to the handshake result (and the master key) would also be useful for auditing, renegotiation limiting and key logging. It can even be used for things like priming introspecting firewalls. There is not yet a good official platform API with access to that kind of information (and proxying client Hello packages to get the offered ciphers is really ugly). With the API an Adapter which can write NSS Keylogs can be provided by users and you don’t have to worry about having debug logging Code expose secrets. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev <security-dev-r...@openjdk.java.net> im Auftrag von ra...@web.de <ra...@web.de> Gesendet: Tuesday, March 23, 2021 6:36:06 PM An: security-dev@openjdk.java.net <security-dev@openjdk.java.net> Betreff: Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys Hi all, I very much appreciate @SalusaSecondus' idea for providing a key logger. For, when working with networks, it's quite natural to analyze message flow with help of wireshark. In TLS 1.3 this isn't possible without a key log because most parts of the handshake messages are encrypted. So, if both, client and server, are Java apps, it isn't possible to trace the message flow with wireshark. That's a great disadvantage. To give an example: I'm running a https client based on SSLEngine and an AsynchronousSocketChannel. The entries in the log provided by javax.net.debug=ssl arise from SSLEngine, but the messages itself are sent by the channel. So it is not possible to check what messages are actually sent over the network (I could have made a programming error in using the data provided by the SSLEngine or something could go wrong within the channel). Therefore, being able to produce a key log on the Java client side and to observe the messages and their content in wireshark, would be very helpful. Concerning the security issue: Of course, holding keys is always a risk. But if one stores the output of javax.net.debug in a file, then an attacker who has access to the system could read decrypted messages as well. But, of course, the implementation of a key logger in Java has to ensure that no key log is produced by default but only if it is explicitly enabled (similar to javax.net.debug). I would be very glad if there would be a chance to implement @SalusaSecondus' proposal in some way because a key logger would be really helpful for doing networking with Java. Regards, Ralph Gesendet: Freitag, 19. März 2021 um 13:48 Uhr Von: "Sean Mullan" <mul...@openjdk.java.net> An: security-dev@openjdk.java.net Betreff: Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys On Thu, 18 Mar 2021 21:26:28 GMT, SalusaSecondus <github.com+829871+salusasecon...@openjdk.org> wrote: >> It is not good practice to leave secret information in debug log. Also, it >> may be not a good practice to introduce new logger format, including file >> and NSS format, into the SSLLogger. Someone also may want to introduce log >> format for MSS or XSS as well. Instead, please consider to make use of the >> features of Java Logger if you want to write the log to files, or use any >> special format. > > @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. ------------- PR: https://git.openjdk.java.net/jdk/pull/2896