Very interesting article, although if the message displayed to the end-user really was left at "You are using an unsupported environment variable: SSLKEYLOGFILE..." that would be truly awful UX with some potentially disastrous consequences.
Why? What "disastrous" consequences are you envisioning from a message like that? Note that the rest of the message (the part you omitted) explains in plain English what the part you quoted means to the average user.
Ok, dumb question. If apparently any kind of technique to intercept an HTTPS stream makes security experts frown, how are you actually supposed to inspect them if you have a legitimate reason? (e.g. monitoring unusual behavior of your own system)
Or is the security best-practice to just trust any app not to upload my contact list?
The SSLKEYLOGFILE approach is a good one; the warning being considered for Chrome just makes it clear when it’s in use.
(Not that you could detect it by inspecting decrypted HTTPS if a closed-source app really wanted to secretly upload your contact list. In that sense, security best practice is minimal app permissions and reproducible builds.)
To my understanding, this exports the session keys of an active TLC connection. Those are temporary keys that were created during the handshake of a particular TLS connection and are only valid for this particular connection.
So, if this data is picked up immediately by a network sniffer, it can decrypt the currently active TLS connection. However, the keys will not allow anyone to decrypt any past or future connections.
Again, these are _secret_ keys. That's why the word SECRET n capital letters appears in that output at the end. Symmetric cryptography is used to actually transport data, and so it uses secret keys. These are agreed between client and server for each session and by getting a copy of them you can read (and in principle modify) the data as it passes between them. A private key would be a key that only one party knows.
The notification is a reminder that this is an unsupported configuration of the browser software, useful for developers but not really intended for your garbage "Anti-virus" software to try to hook into. Just remove/ disable the AV?
I just want to state that some kind of clear-text inspection of content is and should be absolutely expected for security and DLP purposes in an enterprise environment. If TLS is going to become un-MITM-able, then we need to do it on the host.
Which is the desired result, right? Key escrow forces you to be explicit about who you're allowing to decrypt your traffic rather than letting it be everyone by default.
Time to check again, Wireshark can consume TLS 1.3 keys from a client or server to decrypt the session using the environment variable described here. I'm not actually sure which version you need, maybe 2.6 or later?
I thought it was funny. I didn't see it as trying to remove gender as much as talk about how rubbish the practice is (antivirus programs are huge attack vectors, and I assumed the author was calling the anti-virus a Monster).
Chill out. If you start to find offense in everything. you're not going to have a happy life.
If there were “woman in the middle” attacks, and people gender-neutralfied it to “witch in the middle”, there would be an uproar.
Yes, male witches are a thing, though it is a rare usage of the term (vs warlock), just like monsters are usually portrayed as male. Also, some women self-identify as witches for religious reasons. I still suspect there would be an uproar.
There are many problems with using a MITM proxy, however. The primary problem is that it’s very very hard to ensure that it behaves exactly as the browser does and that it does not introduce security vulnerabilities.
FUD. Why should we want "behaves exactly as the browser does", when browsers (in fact, mostly Google's) are in fact turning against their users?
While browser vendors are wary of any sort of interception of HTTPS traffic
Especially Google's, because that's one of the ways you can still block ads and modify pages to have them displayed as the user(-agent) wants, while it continues to slowly remove abilities from browser extensions.
Similarly, the MITM might not support the most secure versions of protocols supported by the browser and the server (e.g. TLS/1.3)
AFAIK there is no general protocol insecurity with TLS <= 1.2, unlike SSL3. There's also no reason for MITM proxies to not start using 1.3 too once it becomes more common, which I'm pretty sure will happen.
this approach is generally preferable to MITM proxies.
...because it provides no way to modify the content, i.e. being able to do things like block ads, inject stylesheets, and generally behave as the user wants.
IMHO the whole "security" thing has turned into a power-grab for companies to enforce their control over users, which is the most disturbing part. We want security, but also control, which is not the "security" they want.
(This comment was posted from a browser that does not support even SSL 2.0, but is using TLS 1.2 via a proxy... and I know that 1.3 will be coming sometime in the future. When that happens, everything that goes through it can also start using 1.3.)
Edit: yay, instant downvotes! I hope you enjoy being herded by Google, because that's where the future is heading if we don't oppose.
> FUD. Why should we want "behaves exactly as the browser does", when browsers (in fact, mostly Google's) are in fact turning against their users?
Issue of scope. Chrome isn't selectively insecure.
>AFAIK there is no general protocol insecurity with TLS <= 1.2, unlike SSL3. There's also no reason for MITM proxies to not start using 1.3 too once it becomes more common, which I'm pretty sure will happen.
Browsers are very particular about how they communicate certificate validation failures. This is generally obscured by the MITM proxy, as is the certificate itself.
Making MITM easy will inevitably lead to people running badly made proxies, especially if such a proxy is installed to the system as adware, the same reason both Chrome and Firefox wouldn't allow random unsigned extensions.
I'd honestly be surprised if any of them do HSTS properly.
>IMHO the whole "security" thing has turned into a power-grab for companies to enforce their control over users, which is the most disturbing part. We want security, but also control, which is not the "security" they want.
You can run dev builds - usually even the official ones - to turn most of those security features off. They're intended for your average non-power user.
>Edit: yay, instant downvotes! I hope you enjoy being herded by Google, because that's where the future is heading if we don't oppose.
That's what you get for making an argument about browser vendors about Google and conflating it with Chrome issues in a different scope.
> FUD. Why should we want "behaves exactly as the browser does", when browsers (in fact, mostly Google's) are in fact turning against their users?
To avoid introducing vulnerabilities, the way lots of antivirus MITMs do, for example. Like it says in the rest of your quote.
> Especially Google's, because that's one of the ways you can still block ads and modify pages to have them displayed as the user(-agent) wants, while it continues to slowly remove abilities from browser extensions.
Blocking ads by MITM? Yikes. Extensions are very much a better tool for that. The idea that browser vendors are going to slowly cripple them so that they’re no longer an effective blocking tool is… wrong. But anyone who was on Chrome can use Firefox anyway.
> IMHO the whole "security" thing has turned into a power-grab for companies to enforce their control over users, which is the most disturbing part. We want security, but also control, which is not the "security" they want.
FUD.
> Edit: yay, instant downvotes! I hope you enjoy being herded by Google, because that's where the future is heading if we don't oppose.
Yes, "security" push from corporations has been a joke for years already. I guess they see that people buy it, push it even farther and lock down everything they can under that excuse.
But we can still survive it, Google is afraid of something and keeps a usable browser open source. And if things go south it won't be hard for a browser fork to implement a proper feature to allow interception of network requests before encryption and responses after decryption with another program, while disabling anti-features.
What kind of browser are you using that doesn't support any remotely recent version of TLS? IE6? That sounds like a major security risk, even ignoring what versions of TLS it does or doesn't support.
[+] [-] 2T1Qka0rEiPr|6 years ago|reply
[+] [-] Ajedi32|6 years ago|reply
[+] [-] xg15|6 years ago|reply
Or is the security best-practice to just trust any app not to upload my contact list?
[+] [-] minitech|6 years ago|reply
(Not that you could detect it by inspecting decrypted HTTPS if a closed-source app really wanted to secretly upload your contact list. In that sense, security best practice is minimal app permissions and reproducible builds.)
[+] [-] a1369209993|6 years ago|reply
By shoving your middlebox somewhere anatomically improbable.
> monitoring unusual behavior of your own system
Anything that tries to connect to the internet for a reason that you didn't both understand and ask for in advance is malware.
> Or is the security best-practice to just trust any app not to upload my contact list?
Yes. That is it exactly.
[+] [-] andrerm|6 years ago|reply
How is this question any different from FBIs encryption backdoor?
I see everybody here defending this but I truly don't understand. How is different from encryption backdoor on the browser?
[+] [-] silverfox17|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] Rudi9719|6 years ago|reply
IE on that notification is there a button to deny the stream?
[+] [-] xg15|6 years ago|reply
So, if this data is picked up immediately by a network sniffer, it can decrypt the currently active TLS connection. However, the keys will not allow anyone to decrypt any past or future connections.
[+] [-] tialaramex|6 years ago|reply
Again, these are _secret_ keys. That's why the word SECRET n capital letters appears in that output at the end. Symmetric cryptography is used to actually transport data, and so it uses secret keys. These are agreed between client and server for each session and by getting a copy of them you can read (and in principle modify) the data as it passes between them. A private key would be a key that only one party knows.
The notification is a reminder that this is an unsupported configuration of the browser software, useful for developers but not really intended for your garbage "Anti-virus" software to try to hook into. Just remove/ disable the AV?
[+] [-] topranks|6 years ago|reply
If you are root on the local system (as all AV is,) then ultimately you can collect these keys, the only question is how much work you may have to do.
[+] [-] jackewiehose|6 years ago|reply
I don't think normal software should need to take account of every way anti-viruses might abuse features.
[+] [-] drewg123|6 years ago|reply
[+] [-] gempir|6 years ago|reply
Idk for what that is useful besides Virus Scanners, but personally I would like my browser to make its own key and never leak it or accept new ones.
[+] [-] unethical_ban|6 years ago|reply
[+] [-] exabrial|6 years ago|reply
[+] [-] Spivak|6 years ago|reply
[+] [-] commandlinefan|6 years ago|reply
[+] [-] tialaramex|6 years ago|reply
[+] [-] drewg123|6 years ago|reply
I'm using it right now, in fact, as I work on adding TLS 1.3 support to FreeBSD's kernel TLS
[+] [-] ignoramous|6 years ago|reply
[+] [-] imvetri|6 years ago|reply
Could it be a coincidence or both are related?
[+] [-] egdod|6 years ago|reply
That’s not what it stands for. There’s nothing sexist about using an acronym the same way everyone else does.
[+] [-] burkaman|6 years ago|reply
I think it's equally understandable, and monster is objectively a more fun word. Seems like not a big deal?
[+] [-] djsumdog|6 years ago|reply
Chill out. If you start to find offense in everything. you're not going to have a happy life.
[+] [-] robocat|6 years ago|reply
Personally, I suspect you are missing humour, and being over-sensitive, and making an incorrect assumption that it had anything to do with being PC.
[+] [-] Rudi9719|6 years ago|reply
[+] [-] hedora|6 years ago|reply
If there were “woman in the middle” attacks, and people gender-neutralfied it to “witch in the middle”, there would be an uproar.
Yes, male witches are a thing, though it is a rare usage of the term (vs warlock), just like monsters are usually portrayed as male. Also, some women self-identify as witches for religious reasons. I still suspect there would be an uproar.
[+] [-] sagebird|6 years ago|reply
[+] [-] Sephr|6 years ago|reply
[+] [-] userbinator|6 years ago|reply
FUD. Why should we want "behaves exactly as the browser does", when browsers (in fact, mostly Google's) are in fact turning against their users?
While browser vendors are wary of any sort of interception of HTTPS traffic
Especially Google's, because that's one of the ways you can still block ads and modify pages to have them displayed as the user(-agent) wants, while it continues to slowly remove abilities from browser extensions.
Similarly, the MITM might not support the most secure versions of protocols supported by the browser and the server (e.g. TLS/1.3)
AFAIK there is no general protocol insecurity with TLS <= 1.2, unlike SSL3. There's also no reason for MITM proxies to not start using 1.3 too once it becomes more common, which I'm pretty sure will happen.
this approach is generally preferable to MITM proxies.
...because it provides no way to modify the content, i.e. being able to do things like block ads, inject stylesheets, and generally behave as the user wants.
IMHO the whole "security" thing has turned into a power-grab for companies to enforce their control over users, which is the most disturbing part. We want security, but also control, which is not the "security" they want.
(This comment was posted from a browser that does not support even SSL 2.0, but is using TLS 1.2 via a proxy... and I know that 1.3 will be coming sometime in the future. When that happens, everything that goes through it can also start using 1.3.)
Edit: yay, instant downvotes! I hope you enjoy being herded by Google, because that's where the future is heading if we don't oppose.
[+] [-] sascha_sl|6 years ago|reply
Issue of scope. Chrome isn't selectively insecure.
>AFAIK there is no general protocol insecurity with TLS <= 1.2, unlike SSL3. There's also no reason for MITM proxies to not start using 1.3 too once it becomes more common, which I'm pretty sure will happen.
Browsers are very particular about how they communicate certificate validation failures. This is generally obscured by the MITM proxy, as is the certificate itself. Making MITM easy will inevitably lead to people running badly made proxies, especially if such a proxy is installed to the system as adware, the same reason both Chrome and Firefox wouldn't allow random unsigned extensions.
I'd honestly be surprised if any of them do HSTS properly.
>IMHO the whole "security" thing has turned into a power-grab for companies to enforce their control over users, which is the most disturbing part. We want security, but also control, which is not the "security" they want.
You can run dev builds - usually even the official ones - to turn most of those security features off. They're intended for your average non-power user.
>Edit: yay, instant downvotes! I hope you enjoy being herded by Google, because that's where the future is heading if we don't oppose.
That's what you get for making an argument about browser vendors about Google and conflating it with Chrome issues in a different scope.
[+] [-] minitech|6 years ago|reply
To avoid introducing vulnerabilities, the way lots of antivirus MITMs do, for example. Like it says in the rest of your quote.
> Especially Google's, because that's one of the ways you can still block ads and modify pages to have them displayed as the user(-agent) wants, while it continues to slowly remove abilities from browser extensions.
Blocking ads by MITM? Yikes. Extensions are very much a better tool for that. The idea that browser vendors are going to slowly cripple them so that they’re no longer an effective blocking tool is… wrong. But anyone who was on Chrome can use Firefox anyway.
> IMHO the whole "security" thing has turned into a power-grab for companies to enforce their control over users, which is the most disturbing part. We want security, but also control, which is not the "security" they want.
FUD.
> Edit: yay, instant downvotes! I hope you enjoy being herded by Google, because that's where the future is heading if we don't oppose.
Don’t.
[+] [-] jakub_g|6 years ago|reply
[+] [-] zzzcpan|6 years ago|reply
But we can still survive it, Google is afraid of something and keeps a usable browser open source. And if things go south it won't be hard for a browser fork to implement a proper feature to allow interception of network requests before encryption and responses after decryption with another program, while disabling anti-features.
[+] [-] zzma|6 years ago|reply
It turns out that most of the MITM products have questionable / insecure TLS stacks [1] and can introduce insecurity to user web traffic.
[1] https://zanema.com/papers/ndss17_interception.pdf
[+] [-] Ajedi32|6 years ago|reply
[+] [-] vasilia|6 years ago|reply
https://bugzilla.mozilla.org/show_bug.cgi?id=1529830 That's why. When you developing HTTP/load balancers it's a good way to test browser in the same environment.
[+] [-] dspillett|6 years ago|reply
Yet. That we know of.
> yay, instant downvotes! I hope you enjoy being herded by Google
Yay! Complaining about downvotes! I hope you enjoy more downvotes.