add NSS key log support

[artu-ole]

Describe the feature

Support logging of SSL/TLS session keys in NSS key log format for crt external communications.

Use Case

This is an essential feature for auditing and deeper troubleshooting of IoT device traffic.

Proposed Solution

Many applications support this behavior via SSLKEYLOGFILE environment variable, others have their own mechanisms, like an upstream s2n-tls library which accepts a callback function.

Other Information

I'm using aws-iot-device-sdk-java-v2 via aws-greengrass-nucleus project. I don't know all of the intricacies of the codebase, but downstream library handling tls does support NSS key logging (aws/s2n-tls#2584) I hope there's a simple way to hook into it without a need for a change in every project up the chain.

I might just be missing a way to punch through the java wrapper to provide the --key-log option to the underlying s2n-tls library, if so I'd be glad to hear the solution!
Downstream feature request aws-greengrass/aws-greengrass-nucleus#1571

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

SDK version used

1.17.2 via https://github.com/aws-greengrass/aws-greengrass-nucleus/blob/release_2.12.x/pom.xml

Environment details (OS name and version, etc.)

iot device with arm64 linux

[jmklix]

Thanks for opening this feature request, but this is something that we plan to never add to this sdk. This is because it could potentially add security holes. I'm sorry that we won't be able to add this feature, but please let us know if you have any other feature requests!

[artu-ole]

@jmklix @TwistedTwigleg @bretambrose @graebm @jpeddicord @timmattison
Thank you for your prompt response and consideration of the feature request. I appreciate the attention to security concerns, however, I would like to highlight that logging SSL/TLS session keys is a practice supported by many widely-used applications and libraries, including

1. Chrome https://github.com/chromium/chromium/blob/122.0.6261.5/net/ssl/ssl_key_logger.h#L17-L20
2. Firefox https://searchfox.org/mozilla-central/source/security/moz.build#92
3. cURL https://everything.curl.dev/usingcurl/tls/sslkeylogfile
4. BoringSSL https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html
5. OpenSSL https://www.openssl.org/docs/man3.2/man3/SSL_CTX_get_keylog_callback.html
6. s2n-tls tls: add NSS key log callback s2n-tls#2584
7. nodejs https://nodejs.org/api/tls.html#event-keylog
8. java https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/ReadDebug.html

These projects have integrated this feature successfully without compromising security.

Given the prevalence of this functionality in established and reputable tools, it may be worth revisiting the decision. The capability to log SSL/TLS session keys is often crucial for auditing and troubleshooting, particularly in IoT environments where the ability to analyze traffic at this level can greatly enhance the debugging process.
Thank you for your time and consideration. I look forward to any further discussions on this matter.

[jmklix]

Can you provide more details about your use case and how you intend to use this with the greengrass nucleus? I see that you opened the original feature request here

[artu-ole]

Certainly. First and foremost for us it would be for auditing and compliance. For organizations operating in regulated industries, such as healthcare, having the ability to log SSL/TLS session keys is crucial. It would enable gathering a comprehensive sample of encrypted communications, which can be audited to ensure compliance with industry standards and regulations in terms of working with sensitive data. Secondly, it would be about debugging and performance optimization. Having access to session keys would help identify bottlenecks or inefficiencies in message communication from and to IoT device software, enabling its optimization especially for metered connections and/or large quantities of server side microservices communicating with endpoint devices both ways.
Ideally, the implementation of the feature would restrict enabling it in production environment, i.e. it would be fine if it's a compile time flag(or whatever you deem the best) though I foresee that might pose an issue for deploying it with the greengrass nucleus.
Let me know if there's anything else I can provide my input on.