Prompted by Med's comment, I found this email (which I'd missed earlier). A few points on the substance. On Wed, May 7, 2025, at 01:49, Jean-Michel Combes via Datatracker wrote: > Regarding the substance, IMHO, it looks like the promotion of a nightmare for > any operational security guy :) My main fear is to see the use of such feature > in a “production system” because (1) the border between “test system” and > “production system” is not always as clear as expected (2) forgetting to switch > off such a feature when pushing the system into production may become an easy > mistake. Now, IMHO and except if I missed something, it should be less complex > from an operational security point of view (i.e., rights management) to > debug/analyze protocols in configuring TLS with “NULL ENCRYPTION” (i.e., > configuration rights) than logging/storing secrets (i.e., write rights, read > rights, export rights). There's a bunch of stuff in the draft that is aimed at preventing the operational nightmare. Or at least better manage the risks. As you say, this is what people are often most concerned about with this sort of capability. If it is enabled, then the logs are a significant risk to operational security. This is fundamentally different than "NULL" encryption, because disabling encryption makes everything visible to everyone. At least with a key log, you have the hope that the logged keys are kept away from random strangers on the internet. Recall that you need both the key log AND access to the TLS connection itself. That needs to be in real-time if you are mounting an attack that involves modifying stuff; or packet captures if you just want to look at the content (like with Wireshark). If you are concerned about this feature, constraints can be placed that ensure it is never accidentally enabled. Compiling the feature out is most common. Then there is the method of enabling, which in many cases requires the ability to set environment variables when launching a process. That is access at a level similar to LD_PRELOAD, which is a far more damaging capability, opsec-wise. There are various rules that can be put in place to prevent accidents, like code that checks for environment variables and crashes, with separate controls than the conditional compilation, requiring multiple failures to occur for bad code to reach active use in production. For example, in a lot of deployments, the filesystem of a host is not readily accessible. Far better protected than the stuff it sends to others. Obviously, your web server could be modified to put the files somewhere it is going to serve from, but that requires special effort to enable (something I've seen done deliberately, FWIW). Nothing perfect here, obviously, but there are tricks. Either way, I can't see how NULL encryption is ever better. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
