Google and Mozilla's message to AV and security firms: Stop trashing HTTPS
zdnet.com
zdnet.com
The web server is in a unique position to be able to detect interception where the browser can't, and then choose how to handle it (warn the client, log the event, whatever). If you want to test this feature, I welcome your bug reports!
For example:
{{if .IsMITM}}
<b>We have reason to believe your
connection is not private, even if
your browser thinks it is.</b>
{{end}}
redir {
if {mitm} is likely
/http-451-censorship.html
}
There are some exceptions, but TLS proxies generally don't touch the User-Agent HTTP header. Doing so runs the risk of breaking things at the application layer. TLS proxies probably don't care if they break things (hence the research) but a proxy that wants to hide (malware, censorship, etc.) would not want to risk breaking HTTP.
This method, for the time being, should effectively force TLS proxies (who want to hide) to preserve the qualities of the original TLS connection. Then if the connection is weak, the browser can at least warn the user. I'm not certain this is a permanent solution, but given the eternal turnaround time of corporate products, I suspect it will be useful for years to come.
The picture in the article states:
Avast 11.7: Advertises DES as a cipher (It's been vulnerable for more than a decade)
AVG and Bit Defender: Vulnerable to Logjam and POODLE
Kaspersky: Vulnerable to CRIME
Net Nanny, KinderGate, CYBERsitter, NOD32, Kaspersky Internet Security (Mac): Doesn't validate certificates.
As a more general issue, TLS interception is a problem. Widespread acceptance of TLS proxying violates the TLS contract, which is that all my communications between a website and my browser are safely encrypted.
I completely agree that the current state of affairs is gravely deficient :(
"The researchers urge antivirus vendors to stop intercepting HTTPS altogether, since the products already have access to the local filesystem, browser memory, and content loaded over HTTPS"
I wonder why they are resorting to TLS interception then. Is it just easier to intercept TLS then inspecting memory? Is it just a lack of perspective?
Similarly the "it's how we've always done it" defense because companies have used that approach for HTTP for so long they don't want to invest in a new approach now that HTTPS makes it much less viable.
As for consumer AV products, I have no idea how they defend that other than "let's have our tentacles in all the pies".
They can't (or actually don't) prevent loss of confidentiality.
Companies that run these MITM proxies are also protecting against deliberate extrusion of sensitive data.
They could just use a whitelist and replace all CAs on the computer with a (set of?) private CA(s) that allow the user to do work on information that requires such security.
Yes, it is possible to explicitly list all certificates you need, or you could simply use the same PK infrastructure as the rest of the world.
I bet 100 years ago it was considered unrealistic to tell white collar employees that they could not bring booze to the office. Today it is a firing offense in most jurisdictions.
After all, people are already aware there is a distinction between their professional personna and their private self. They know there are things you do under one identity but not under the other, and viceversa. Merely adding one tiny thing to the list will do little.
Sure, executives will push back. I bet they pushed back even harder when accountants told them that "No, you cannot put your stripclub bill into the corporate credit card; and I don't care if it was a business expense, either."
That's the meaning of being a professional: telling the higher-ups that there are hard rules (natural or otherwise) that don't give a flying-fuck about their social status. Doctors know it, lawyers know it, accountants know it, but for some reason IT people does not seem able to figure that out. Compensation aside, the social prestige that comes with each of those professions is directly proportional to their ability (and duty) to enforce those standards regardless of what their rich and powerful bosses think about it.
If you attempt to force your lawyer to violate ethics, and their document it and complain then no lawyer will work for you.
If you attempt to force a doctor to violate ethics, then not only will no doctor work for you, but you might actually get jail time.
They don't have it.
Sure. But they also can't be sharing sensitive data with third parties. And yet many AV/security products can upload samples for analysis.[0] Including Word documents.
0) https://www.av-comparatives.org/wp-content/uploads/2014/04/a...
So you're saying that providers just promise not to disclose? What if they screw up? Who's liable?
Let's say that I'm a freelance developer. Could I get an NDA? And if so, would it cost a lot?
So you need the legal fees to come up with the NDA and sufficient capital to be able to fund a lawsuit should the other party violate the NDA.
Finally, you need to be big enough that the other company is interested in signing an NDA for the business. For a solo developer, this is unlikely to be true.
So then, standalone GPs shouldn't be using AV software.
I've long been of the opinion that for most people anti-virus is ineffective snake oil that significantly compromises PC performance for very little security benefit.
Our multi-language build process downloads from Bintray, Maven, npm, Github, Cloudfront, S3 using curl, Maven, SBT, npm, apt, etc. To improve times and insulate against downtime, I MITM the CI servers with a caching proxy.
Two environment variables (http_proxy, https_proxy), and everything is cached, fast, and reliable.
(Not affiliated, just an extremely happy user)
I have to make sure each of the tools is setup to use it, and I have to move the source repos from code to Nexus config, and it doesn't help if anyone does something non-standard, e.g. last I checked installing Angular involved an ad-hoc Github download.
HTTPS_PROXY gets virtually everything in one go.
Assuming you meant you set those environment variables for your applications, then that wasn't mitm. It was application-level supported proxying.
Those are totally different things.
I set up a caching MITM TLS proxy (with a trusted cert on my CI server).
(Of course, this means that traffic between the client and the proxy is unencrypted, so if you do not trust that network, you will need to add a VPN or similar there.)
$ https_proxy=http://localhost:8888 curl -vo /dev/null https://example.org
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8888 (#0)
* Establish HTTP proxy tunnel to example.org:443
> CONNECT example.org:443 HTTP/1.1
> Host: example.org:443
> User-Agent: curl/7.35.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.0 200 Connection established
< Proxy-agent: tinyproxy/1.8.3
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
...
* Server certificate:
* subject: C=US; ST=California; L=Los Angeles; O=Internet Corporation for Assigned Names and Numbers; OU=Technology; CN=www.example.org
* start date: 2015-11-03 00:00:00 GMT
* expire date: 2018-11-28 12:00:00 GMT
* subjectAltName: example.org matched
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
...
Edit: You're only proxying the encrypted data and not trying to do a MITM, so this doesn't break TLS, but it doesn't do a MITM. I added this complaint as a more general statement at the top-level of comments.
On my network there are an order of magnitude more valid TLS MITMs happening than there are valid non-MITMed TLS connections.
https://www.chromium.org/Home/chromium-security/security-faq...
I can't remember what Firefox does in this situation
The real thing you seem to be upset about is that Chrome even allows you to MITM TLS connections at all at any level, whether or not the "actor" is your boss or a rogue adversary. It's debatable whether or not this is a good policy[1]. It's also a completely separate debate from whether HPKP is "neutered" or not.
[1] Realistically, it mostly doesn't matter what you think, because here's what will usually happen: Chrome doesn't allow MITM. Your business then enforces a network policy that bans Chrome from all devices. The alternative browser still allows MITM, and you still have to use them, and thus it still happens to you and everyone else. The end.
If Chrome enforced pinning with local roots, then the outcome would be:
1. Those sites simply become unaccessible 2. Those networks require you to use a different browser 3. Those networks deploy a modified version of the browser which disable that behavior 4. Websites avoid using HPKP in the first place because it may cause problems
or some combination. Those outcomes seem worse than Chrome obeying the desires of the network admins.
Is there some risk that malware or other bad actors could abuse this? Sure. But Chrome's devs considered that and decided any other number of bad things could be done with the same access.
https://jlospinoso.github.io/node/javascript/security/crypto...
The usual client-side JavaScript crypto caveats apply.
Could we fix this by isolating the browser more efficiently from the local workstation environment and thereby removing the need for this kind of security?
What if you would be executing the Internet browser in an environment where you would not need to care so much about the security. Like running the actual browser process in a completely separate environment, maybe located outside your intranet firewall and just streaming the UI via some simple-enough-to-be-secure mechanism to the desktop.
Also, it is only implemented in Firefox and Chrome; Microsoft doesn't support it in their browser or at the OS level.
I'm suprised it still exists, it seems like a juicy malware target, just like these poorly implemented SSL MitMs.
Another option is to check the certificate for any website; for instance, the one for this site should chain to "COMODO RSA Certification Authority", and for me shows the SHA1 signature BB:DD:64:6F:EB:11:0C:D5:EC:CF:57:D1:F7:52:AA:99:50:1B:44:FD.
Most of the web interceptor products break things in very interesting ways (as do ublock and ghostery), the difference being it's far easier to tweak a browser plugin. These AV companies should be browser plugins not a local reverse proxy.
But this is more a problem with the knee jerk HTTPS everywhere movement and a quick and dirty response than anything else. The browser and OS vendors don't provide high quality APIs for this purpose, so customers are stuck picking security products without an easy way to identify quality gaps.
Even in unregulated industries, most commercial enterprises should be doing TLS inspection -- i would argue that's it is irresponsible not to. How can you claim to protect customer data or respect customer privacy without looking at the data flowing out the front door?
Please do so. Please present a compelling argument for why, in the general case, it is irresponsible not to spy on your employees.
Now we can all debate the value of AV scanning in general (I'm on the probably-not-worth-it-and-way-too-risky side), but if we attribute any kind of value to AV scanning (it might help with wide-spread attacks at the cost of facilitating targeted attacks), then being able to peek into SSL tunnels is a requirement for it to provide any kind of its proposed value.
Depending on your users level of knowledge and your updating procedure, not running AV might indeed be considered irresponsible.
If your systems are somewhat unpatched and your users oblivious to threats, then you're much more likely to be owned by and wide-spread malvertising and email spam attack (both of which AV actually protect against) than you're likely to be the victim of a targeted attack (which AV actually makes easier to pull off) just by virtue of the former being much more common than the latter.
> How can you claim to protect customer data or respect customer privacy without looking at the data flowing out the front door?
Because others are customer service reps.
Because how do you do a job without the data required to do a job?
There's no squaring the circle here. You can not lay obligations on corporations to secure their stuff, but not permit them to have any tools that allow them to actually implement that security, and expect security to be the result. You can't assume that all employees of all companies everywhere that deal with sensitive information are solely staffed by angels, especially in light of the fact that the very fact that they deal with sensitive information can attract people who deceptively pose as employees long enough to get their hands on this information.
Murder and manslaughter are illegal!
not really HTTPS interception by AV programs and corporate proxies is common since the mid 90ies. What did happen because of the HTTPS everywhere movement is that this bad practice is finally coming to light and being scrutinised.
What we need is for AV programs and proxies to actually do proper certificate validation and to not downgrade security on the public end of the tunnel. If they can't do that, then we might actually be better off with them not existing than with the status quo.
Surely the real solution here if you insist is to not pretend that you've got real HTTPS but to block 80/443 altogether and make applications use a proxy.
There is an entire profession of network forensics and security analysis to make these determinations. A great deal of commercial products are available to assist and to some degree automate. It is not a 'solved problem', but it is as solved as anything else in security.
It sounds like you're saying that you believe HTTPS is a bad solution to (presumably) the problem of surveillance-friendly plaintext comms via browser. But I'd like to understand.
You also seem to be claiming that AV products are somehow a special category of security product, for which evaluation is especially difficult. I don't see it, and in fact, there's a handy chart in that post to help.
Companies that have audit requirements for these things are most likely going to need purpose-built tools for this; depending on AV crapware is a terrible idea.
And as for the notion that "most" enterprises should be shoulder-surfing their employees, well. I assume you also recommend all employees pass through a metal detector and have all thumb-drives and whatnot inspected on the way out? If not, why not?
Of course, system administrators could put further work into making sure that computers are not used maliciously, for example, by recording the screen constantly and by randomly inspecting the recording or by using machine learning to identify things like pornography, but it won't cover everything (browser bars that are actually malware or other viruses) and it's a whole lot easier to just thwart HTTPS than it is to do anything else.
Your answer could have also been "doesn't matter, still use HTTPS everywhere!" which I think is also a fine answer if we're also ok with taking certain computers off of the internet, like say the computers that children use at school[1] or computers in charge of medical data, but our choice is one of three things:
1. Give up privacy because our data is easy to leak out through HTTPS traffic, so we'll admit defeat and let our healthcare records leak because we can't MITM the traffic.
2. Give up privacy because we have methods of MITM attacking, including for both good and evil uses.
3. Give up efficiency by removing computers from the internet / other large networks.
Personally I think the long run is #3 but I've underestimated humanity's laziness many times.
[1] I'm actually 100% ok with this until a certain age, they really don't need more than messaging, typing classes, a math program or three, and Wikipedia.
There are other ways to accomplish preventing children from accessing inappropriate content, namely filtering by domain which is still possible with HTTPS. Google SafeSearch can also be turned on at the DNS level, still allowing HTTPS to be used and privacy to be maintained.
The best way to accomplish more granular filtering is to install a custom browser extension that monitors what pages are visited, no machine learning necessary. And if group policy doesn't prevent browser toolbars from being installed, the school has bigger problems.
Yes... yes they should. What would possess someone to say they shouldn't?
If this is about parental controls, it's a non-issue, as someone else explained. You can have both privacy and parental controls.
You do understand that:
a) nobody has come up with an algorithm that can visually identify pornography? Hell, how can we come up with an algorithm when we have such trouble even legally defining pornography? https://en.wikipedia.org/wiki/I_know_it_when_I_see_it
b) TLS doesn't mask the source/destination IP's, just the content, and as such pornographic sites can still be filtered and banned in school environments without attacking TLS.
... right?
Also, plenty of people have come up with algorithms that are very reliable (highly performant ROC curves) at identifying pornography. Certainly reliable enough for whatever pornography today's children are searching for on school computers.
Should a administrative person at your local police department be able to take screenshots of a criminal complaint where someone wrongfully alleges that you have commited some horrific crime and post them to Facebook or save to their Dropbox?
You have a duty to protect your customers. In my career, I've had to testify as a witness when employees attempted to steal customer identities by various means. They were caught because our outbound DLP/proxy identified structured data that matched records commonly in use.
I don't claim that AV is special. I do claim that evaluating the quality of an HTTPS implementation inside of AV software is difficult, particularly for customers (typically SMB, schools, or municipal government) who are looking at client based solutions.
If you're in a position of leadership in a company that may be handling my data, please let me know so that I can do business elsewhere.
Even in the US where employer snooping is largely unregulated, people are still left with more than enough capability to exfiltrate information from their organisations.
Changing that would imply twice-daily pat-downs / cavity searches, inability to exit the workplace for lunch, bans of personal smartphone etc devices, regular home searches, wiretapping of personal phone/im/email etc and it would still be leaky.
I'm sure you can find instances of leaks where they happened through channels that your "DLP" product has caught, and I can see how that works as a marketing point for DLP. But in the big picture the problem isn't "TLS is secure" and outbound traffic snooping doesn't solve it.
Good luck for them. FTA:
> They also find that the default settings on 11 of 12 network appliances tested introduce severe flaws, such as incorrectly validating certificates, while 24 of 26 antivirus products introduce one or more security flaws.
...
> Similarly on the appliance side, only Blue Coat's ProxySG 6642 scored an A. Others products are from A10, Barracuda, Checkpoint, Cisco, Forcepoint Websense, Fortinet, Juniper, Microsoft, Sophos, Untangle, and WebTitan.
Which APIs should be provided by operating systems and/or browsers?
On Windows, browsers (at least Firefox) do provide an API for antivirus scanners, as can be seen by the pause after every download on slower machines with an antivirus scanner (which, the last time I saw it, explicitly mentioned "scanning for viruses" on the download status). On Linux, the operating system kernel provides the fanotify API, which was designed to allow an antivirus scanner to scan every newly created file. What other APIs do you believe should be added?
Think ICAP for Chrome.
That way you can leave the network path intact, not worry about proxy bypass, and keep crypto operations in the browser.