RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys

[Bernd Eckenfels]

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-retn at openjdk.java.net> im Auftrag von raell at web.de <raell at web.de>
Gesendet: Tuesday, March 23, 2021 6:36:06 PM
An: security-dev at openjdk.java.net <security-dev at 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" <mullan at openjdk.java.net>
An: security-dev at 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+SalusaSecondus at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210323/56c0b9e6/attachment-0001.htm>