All,

Some time ago I posted noting that it would be useful to have the SSLKEYLOGFILE 
environment variable supported by OpenSSL. I lost track of that request, and 
have since noticed that a patch that would have added support for that 
environment variable[0] was closed, with Rich asking for an alternative 
implementation based on an option flag.

I’d like to volunteer to resurrect this patch, but to do so I need to better 
understand the objections to the proposed interface. Quoting from the issue, 
Rich has said that having the SSLKEYLOGFILE environment variable set to dump 
session keys is “not safe”, and in particular that 'The risk that someone using 
this in production will get "tricked" into exposing session keys is too great.’ 
Rich’s alternative proposal is that we should add a compile-time flag 
(“OPENSSL_NO_KEYLOG”) that is set by default and would need to be unset to 
allow dumping of session keys, and then a context option (“SSL_OP_LOG_KEYS”) 
that must be enabled, before this environment variable would function as 
expected.

While I understand Rich’s concern, I’m not sure that this functionality 
requires such substantial handcuffing. The attack vector that I can see these 
requirements defending against is that an attacker may be able to inject the 
SSLKEYLOGFILE environment variable into the environment of a process running 
OpenSSL pointing at a file that is both writable by the OpenSSL process and 
readable by the attacker. It’s certainly not immediately apparent to me that 
this is an easily exploitable attack vector, though I’m definitely not an 
expert and I’m willing to be told that I’m wrong.

It is the case, however, that if OPENSSL_NO_KEYLOG is the default value of that 
compile-time flag, the utility of the SSLKEYLOGFILE environment variable drops 
almost entirely to zero. My rationale for wanting this is to make it easier to 
debug the application-layer protocol running inside a TLS tunnel, and if my 
users have to recompile and re-link their applications against a new OpenSSL 
*and* also pass additional context options in order to enable the logging I 
think that the amount of work required to support this environment variable is 
basically zero: it would be easier to simply intercept the BIO reads and writes 
to simply dump the application data than to ask my users to do all of that.

So what do the OpenSSL developers think? Do we need the compile flag, or is 
some lower bar sufficient?

Cory


[0]: https://github.com/openssl/openssl/pull/570
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to