Yeah, I think we will see more inadvertent logging than malicious, just as we have seen passwords mistakenly deposited in logs for approximately as long as we have had both logs and passwords.
One challenge with SSLKEYLOG is that there’s no way without very system-specific inspection to detect whether it’s on or off (as compared to “supposed to be on or off, as we intended to deploy”). It would certainly be a bigger specification, but I think it would be nice if there were some marker in the TLS handshake that indicated that SSLKEYLOG was in effect. It would be even nicer if that marker were visible to observers who don’t have the keys, so that packet-inspection sorts of rules could detect and alert on it, but TLS is generally moving in the other direction in terms of having things outside the encryption envelope. Mike On Sun, Aug 4, 2024 at 10:41 AM Amir Omidi <amir= 40aaomidi....@dmarc.ietf.org> wrote: > It doesn’t necessarily need to be malicious. With how much of software > deployment being massive YAML files with tons of environment variables, > mistakenly including this won’t be that difficult. > > On Sun, Aug 4, 2024 at 07:00 Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> On Sat, Aug 03, 2024 at 02:38:29PM -0700, Christian Huitema wrote: >> > >> > The security considerations of >> > https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ are pretty >> > clear, but the discussion pointed out that environment variables can be >> > installed without knowledge of most users. More protection is needed. >> > Examples are explicit run time options, such as asking the user to set a >> > special configuration flag to enable the feature, and compile time >> > protections, which would only enable that configuration flag in special >> > versions of the application. >> >> Any attacker that can tamper with environment variables is in position >> to do way way worse things than enabling SSLKEYLOG. Possibly even worse >> than an attacker capable of replacing the whole application with a >> troijan! >> >> >> >> >> -Ilari >> >> _______________________________________________ >> 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
