12 ms·
Google and Mozilla's message to AV and security firms: Stop trashing HTTPS
- zaphar 10y agoSadly for companies in some industries (i.e defense or healthcare) there are regulatory compliance issues that force them into running something that can intercept TLS connections. These companies are many times in a position of either weakening security or failing an audit. Until the regulations catch up they will be stuck between a rock and a hard place.
- Jonnax 10y agoWell part of the argument that Google/Mozilla are putting forward is that some software does their man in the middle attack in bad ways that compromise user security. 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.
- zaphar 10y agoSure but for most of these companies conducting a security audit of their AV solution is very much not something are going to be competent at. The typical auditing companies they might hire for there compliance reasons are also not going to be competent at it. As a result, due to a lack of knowledge and a need to check boxes, they will be choosing AV solutions that lower their security. It's a perfect storm. Especially since many of the ones on the list are considered best in market for these people.
- Neil44 10y agoI can only speak to Eset as it's the only one I am sure about, but it definitely does validate certs. I have screen grabs of validation errors because they were interesting.
- fulafel 10y agoThey should just live without HTTPS and not break it for everyone else.
- tonyztan 10y agoTLS interception is not the problem. Improper implementation of the protocol is. AV / Appliance vendors need to configure their MITM proxies correctly so that they utilize the same protocols and verifications that the browsers have.
- KingMob 10y agoBut these devices are rarely updated, so even one that's safe now has no guarantee that it can be kept safe in the future. 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.
- madars 10y agoThe OP's point is that in some realms the user is forbidden (not by technical means, of course, but by law) from entering into such contracts or, at least, executing them. I completely agree that the current state of affairs is gravely deficient :(
- deburo 10y agoThe article is also pointing out that .. "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?
- WorldMaker 10y agoEase of deployment? At least for corporate interception the answer seems to be just how much easier it is to deploy a central proxy than to make sure that client software is up to date. (Forgetting, conveniently, that you have to update client certificate stores every so often.) 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".
- hehheh 10y agoShould people in those industries have access to the outside web on the computers that have even a smidge of access to data that must be kept private by law? I'd say "no" -- I can't think of a scenario in which a healthcare device needs access to Google or hacker news or whatever. 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.
- paulddraper 10y agoThere are internet-based patient management systems. 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.
- jcrawfordor 10y agoTelling people that they cannot 1) have their records management system and 2) have internet access on their computer is simply unrealistic. Basic measures like blocking webmail providers are extremely unpopular with employees and produce huge executive pushback, a whitelist approach to internet access like you propose would just be a total non-starter. Imagine if you yourself worked in that environment, where your computer could only access a few select websites because you have access to restricted information (which you almost certainly do) - I mean, most tech workers I know are deeply upset about not having local admin on their machines. What you're proposing is about a thousand steps more restrictive.
- cmiles74 10y agoPeople work in much worse conditions everyday. Most everyone I know owns a cell phone that has internet access, people can always use those. I don't think expecting people who access restricted data also using machines that lack internet access is that big a deal.
- crpatino 10y ago> Telling people that they cannot 1) have their records management system and 2) have internet access on their computer is simply unrealistic. 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.
- mirimir 10y ago> there are regulatory compliance issues that force them into running something that can intercept TLS connections. 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/avc_datasending_2014_en.pdf https://www.av-comparatives.org/wp-content/uploads/2014/04/a...
- jcrawfordor 10y agoVendor NDAs and other compliance measures are in place. This is a standard part of negotiating enterprise licensing in security-sensitive sectors.
- mirimir 10y ago> Vendor NDAs So you're saying that providers just promise not to disclose? What if they screw up? Who's liable?
- jcrawfordor 10y agoThe vendor is liable. That's what the NDA is for.
- mirimir 10y agoOK, so I wonder who can negotiate NDAs. Let's say that I'm a freelance developer. Could I get an NDA? And if so, would it cost a lot?
- richardwhiuk 10y agoAn NDA is meaningless if you have no intention of suing the party that violates the NDA. 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.
- Spooky23 10y agoObviously HTTPS needs to be implemented correctly. 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?
- jstanley 10y ago> I would argue that's it is irresponsible not to Please do so. Please present a compelling argument for why, in the general case, it is irresponsible not to spy on your employees.
- pilif 10y agoWhile there's the potential of spying, there's also the much more common use-case of AV scanning the whole stream but otherwise not looking at it and not archiving it anywhere. 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.
- jcrawfordor 10y agoIn real corporate environments (where, keep in mind, most users are very non-sophisticated), this kind of inline scanning is extremely valuable. TLS intercepted data is also invaluable for post-incident investigation, for example, to determine whether or not a host A/V detection is likely valid without having to go through a costly and disruptive host forensics process (typically by grabbing the file out of retained data, or just by determining where the file actually came from). In fact, without TLS interception, post-incident investigation based on network artifacts is becoming more and more impractical as malicious actors are taking advantage of LetsEncrypt and CloudFlare to HTTPS protect their delivery and C2.
- nrki 10y agoPlease also stop trashing SMTP.
- mholt 10y agoI really believe this is an important study. To help expose MITM, I implemented HTTPS interception detection features into Caddy, based on the heuristics described in the paper: https://github.com/mholt/caddy/pull/1430 https://github.com/mholt/caddy/pull/1430 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}} Or: redir { if {mitm} is likely /http-451-censorship.html } The researchers won't be releasing the fingerprints they collected until after NDSS '17 (March), but I'll look at taking those into account when they are available.
- javajosh 10y agoYou're doing excellent work with Caddy, Matt. This solution of yours, which detects inconsistent headers on a single connection, is a good one. What will you do if and when MITM attackers do the extra work to duplicate headers?
- mholt 10y agoThanks Josh, I appreciate it. Their method works by comparing the User-Agent HTTP header to the characteristics of the TLS handshake of the underlying connection. 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.
- paulddraper 10y agoI see a lot of hate for TLS interception of any kind, but I did it just the other day for my CI servers. This isn't what Chrome and Mozilla are upset about, but it's an example of IMO valid TLS MITM. 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.
- deleted 10y ago[deleted]
- mschuster91 10y agoHave you tried Sonatype Nexus OSS yet? It's free (actually, open-source-free) and supported by docker, npm and maven. No need for strange SSL interception any more. (Not affiliated, just an extremely happy user)
- paulddraper 10y agoYep, I've used it. 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.
- user5994461 10y agoIt's not MITM. It's regular HTTPS tunneling through a regular proxy, which is a feature supported by most proxies. Both the client and the proxy must be configured and aware of each other.
- TheDong 10y agoWhat you did doesn't sound like MITM/TLS interception. 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.
- SimeVidas 10y agoI still don’t know if I’ve disabled HTTPS interception in ESET Internet Security. I went in Settings > Internet Protection > Web Access Protection > Web Protocols, and then disabled HTTPS checking, but I’m not sure if that’s it or if there’s more.
- cesarb 10y agoIf you're using Firefox or Chrome, go to a site with an EV certificate (for instance https://twitter.com/ https://twitter.com/), and check if it shows the EV bar. These two browsers only accept EV certificates from a few hardcoded CAs, so if it's still being intercepted, it won't show as EV. 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.
- tonyztan 10y agoYou can manually inspect the website certificate in your browser. If it is issued by a CA that looks like it is from your antivirus, then you haven't. Also, you can go to https://twitter.com/ https://twitter.com/ and see if the EV indicators show up ("Twitter, Inc. [US]" in green).
- tracker1 10y agoI generally disable all "web access protection" or similar. then again, on windows, I find that Windows Defender (since 10 includes the MS AV product) is good enough. I do use ublock origin and ghostery in my browsers though. 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.
- j_s 10y agoYou can request a second opinion attempting to detect MitM via JavaScript using snuck.me: https://jlospinoso.github.io/node/javascript/security/cryptography/privacy/2017/02/20/snuckme-cert-query.html https://jlospinoso.github.io/node/javascript/security/crypto... The usual client-side JavaScript crypto caveats apply.
- j_s 10y agoAn client-side SSL interception API exists: SSLKEYLOGFILE. It isn't any help for security appliances though. 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.
- rkeene2 10y agoMy main complaint with attempts to MITM TLS is that it is a failure -- you cannot actually MITM TLS without breaking TLS. Specifically, TLS client certificates are almost always broken when by attempts to MITM TLS and we use TLS client certificates for almost all HTTPS connections.
- majewsky 10y agoThis was actually a huge problem when, at $work, we recently locked down our productive Kubernetes clusters to only allow access via an SSH jump server. The approach that we've settled on is to have a forward HTTP (without S) proxy on the jump server (listening only on localhost) whose port is forwarded to the local machine by SSH, so we can do `export https_proxy=https://localhost:$forwarded_port` https://localhost:$forwarded_port` to make kubectl work. sshuttle was also evaluated, but it clashes with the VPN client that the remote colleagues need.
- majewsky 10y agoCannot edit anymore, but that sould be "http://" http://" instead of "https://" https://".
- tyingq 10y agoHPKP[1] everywhere? Are any of the antivirus or corporate proxy products able to defeat it? [1] https://en.m.wikipedia.org/wiki/HTTP_Public_Key_Pinning https://en.m.wikipedia.org/wiki/HTTP_Public_Key_Pinning
- mrbabbage 10y ago> Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning. https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- https://www.chromium.org/Home/chromium-security/security-faq... I can't remember what Firefox does in this situation
- tyingq 10y agoWow..That pretty much neuters the entire purpose.
- aseipp 10y agoExcept for the fact that HPKP actually works and has been working. The part that "does not work" -- which is actually a design issue -- is that it does not override private anchors. 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.
- jpalomaki 10y agoCorporations can defeat all browser based features by forcing their users to use another browser.
- askvictor 10y agoIs it not possible to implement an interception or proxy API in the browser? That way everything is above board, and the user knows what's going on.
- reiichiroh 10y agoWhat about intercepting SSL decryption in the workplace with Fireeye and Palo Alto type devices?
- reiichiroh 10y agoWhat about intercepting SSL decryption in the workplace with Fireeye and Palo Alto type devices?
- jpalomaki 10y agoThe reason why corporations are doing this is because they are afraid what kind of (malicious) content is coming down to their network and what users are possibly sending out. 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.