Some HTTPS Inspection Tools Actually Weaken Security (itworld.com) 102
America's Department of Homeland Security issued a new warning this week. An anonymous reader quotes IT World:
Companies that use security products to inspect HTTPS traffic might inadvertently make their users' encrypted connections less secure and expose them to man-in-the-middle attacks, the U.S. Computer Emergency Readiness Team warns. US-CERT, a division of the Department of Homeland Security, published an advisory after a recent survey showed that HTTPS inspection products don't mirror the security attributes of the original connections between clients and servers. "All systems behind a hypertext transfer protocol secure (HTTPS) interception product are potentially affected," US-CERT said in its alert.
Slashdot reader msm1267 quotes Threatpost: HTTPS inspection boxes sit between clients and servers, decrypting and inspecting encrypted traffic before re-encrypting it and forwarding it to the destination server... The client cannot verify how the inspection tool is validating certificates, or whether there is an attacker positioned between the proxy and the target server.
Slashdot reader msm1267 quotes Threatpost: HTTPS inspection boxes sit between clients and servers, decrypting and inspecting encrypted traffic before re-encrypting it and forwarding it to the destination server... The client cannot verify how the inspection tool is validating certificates, or whether there is an attacker positioned between the proxy and the target server.
expose them to man-in-the-middle attacks (Score:5, Insightful)
might inadvertently make their users' encrypted connections less secure and expose them to man-in-the-middle attacks,
Well no shit, given that the traffic inspection itself has to be done via a man-in-the-middle attack.
Re: (Score:1)
Yes, this.
My reaction to this story was "well, duh." Anyone who didn't already know this is someone who isn't familiar enough with the concepts involved.
Re: (Score:3)
My reaction to this story was "well, duh." Anyone who didn't already know this is someone who isn't familiar enough with the concepts involved.
Huh? There's no "concept involved" that leads to the inevitable conclusion that some HTTPS proxies won't do certificate authentication. It's an implementation error.
Of course increasing complexity will increase the programming error rate, but that's not at all specific to this vulnerability. And since the vendors have patched these flaws, they're not inherent to t
Re:expose them to man-in-the-middle attacks (Score:5, Insightful)
The concept involved is the increase in the "surface area" of potential failure. If you've introduced a system that sits in the middle, decrypting communications, processing the communications, and re-encrypting them, you've also introduced quite a lot of things that can go wrong, and have increased the chances that something will.
In the global view, given how common these things are, is approaches inevitable that there will be security problems.
Re: expose them to man-in-the-middle attacks (Score:1)
Indeed. No need to target individual computers to access their encrypted data. All you need to do is target the MITM TLS inspection tool.
Re: expose them to man-in-the-middle attacks (Score:3)
Yep, that's always the logic IT security uses when we try to get software approved and they deny it.
Any IT group who implements this is NOT serious about decreasing the attack space, they just want ton spy on employees.
Re: expose them to man-in-the-middle attacks (Score:1)
Or are a school that wants students to have access to educational YouTube without all of YouTube. Honestly that is likely the bulk of the reason for this. The average employer either blocks a whole site or allows it, no need for inspection for that. Google could just move educational stuff to a sub domain but no that would be too hard.
Re: (Score:3, Informative)
Just to make sure i'm clear here...
Are saying; that only IT groups that are serious about security, allow unknown encrypted data to pass out the perimeter with no regard to what could be present in it? Are you saying that IT groups should just accept the risk of data being ex filtrated over these unknown encrypted connections? What about C2 traffic?
As someone who regularly performs Security Assessments and Penetration Tests for the Financial Industry in the US... I would say that's rather naive...
There is a
Re: (Score:2)
There is absolutely ZERO expectation of privacy when using an asset that is provided by your employer.
Is that so? The only way I can access some of my medical information is via my work computer. Are you saying I have zero expectations of privacy to access my private medical data? I'm sure my company is not the only one that has many benefits that are only accessible via intranet services. IT has no right viewing any of that data.
Re: (Score:2)
Is that so? The only way I can access some of my medical information is via my work computer. Are you saying I have zero expectations of privacy to access my private medical data? I'm sure my company is not the only one that has many benefits that are only accessible via intranet services. IT has no right viewing any of that data.
In the US, anyway, Mindscrew is 100% correct. If you are using your employer's equipment, then the employer has every legal right to inspect the traffic you're generating and your
Re: (Score:2)
Ack. Quoting problems! The first paragraph is an (unnecessary) quote of Bengie's comment.
Re: (Score:2)
Re: (Score:2)
Are you sure? That would be highly unusual. In every case I've seen, health care portals are not run by the company itself, but by a different company acting as a contractor. In each of those cases, my employer has offered intranet access as you describe -- but you can also reach the portal by going directly to the contractor's website outside of the intranet.
If this isn't what your company is doing, then something is very, very wrong with your company's procedures.
Re: (Score:2)
And I assume you have something in place to prevent the data on the machine from being encrypted (perhaps steganographically) locally before being sent out? Because otherwise your MITM system will only serve to prevent private information from being accidentally pasted in web forms. It would do nothing against exfiltration by malware or competent intentional leaking.
Re: (Score:2)
Re: (Score:2)
It's not an implementation error, it's an unavoidable feature of these SSL inspection proxies. You basically have to trust everything coming through the proxy, remove the capability of handling or inspecting the security yourself and give up the notion that it's safe, secure and unchanged - that is the feature the people in charge of security over these organizations *want*.
On the other hand, if an SSL vulnerability crops up, upgrading your browser (or the requirement to) doesn't matter anymore and you have
Re: (Score:2)
Re: (Score:2)
Not at all. My reaction had more to do with context than content. This is /. where the vast majority of readers are likely to already be reasonably familiar with these issues. I would not have the same response if the same article appeared in a less specialized forum. I was also not really criticizing its appearance here.
Re: (Score:3)
Oh come on, don't be ridiculous. Next thing you'll try to tell us is that TSA luggage inspection makes the stuff in our suitcases less secure...
Re: expose them to man-in-the-middle attacks (Score:2)
Sometimes I wish there was a like button on slashdot...
Re: (Score:2)
93, I just read this again, and man... I still like it. :)
Re: (Score:2)
might inadvertently make their users' encrypted connections less secure and expose them to man-in-the-middle attacks,
Well no shit, given that the traffic inspection itself has to be done via a man-in-the-middle attack.
Exactly.
At a previous employer (large Fortune 500 company), I got roped into going to a class put on by the vendor of a proxy product.
The instructor was a very sharp fellow who flat out stated that the "HTTPS inspection" feature was a MITM attack.
Interesting thing was this company was not using the feature due to the _legal_department_ prohibiting it's use.
Re: (Score:2)
Re: (Score:2)
The fact that you can transparently MITM a TLS connection,
Fact? Transparently? You can? How?
Re: (Score:2)
Actually that's not true and the man in the middle design is horrible for many reasons.
The better inspection tools will use a lollipop design where the terminating https device spans than traffic to another device for traffic analysis. Traffic that requires modification can then be routed through the lollipop device on a case by case basis.
Re: (Score:2)
It's not actually breaking SSL, but it certainly does weaken HTTPS security.
Re: (Score:2)
It does break SSL, SSL is meant to be point to point, this is a MITM attack.
Perhaps I'm splitting hairs here, but this is not a MITM attack on SSL. The SSL protocol in this situation is behaving just fine. This is a MITM attack on HTTPS, a layer higher than SSL.
If it's unzipping encryption it has to re-zip it (Score:1)
It's as obvious as a zipper. If you unencrypt to inspect, you have to re-encrypt before sending it back along its path. Done perfectly, it's zero impact.
You have to verify that you're re-zip is as good as the original zip, or duh, you've weakened your zipper.
So it kind of begs the question how thorough and deployment-specif is the testing itself in the first place?
Why not test on multiple hops along the path if you can, including on a pseudo-client?
Re: (Score:2)
I think they're also talking about the validation of the source - i.e. the man in the middle attack isn't just accepting the connection it's making on the client's behalf that it's own connection to the server is actually secure in and of itself.
It's a two pronged issue.
Re: (Score:2)
Since the certificate of the original site is very hard to re-create then the recipient would be able to detect a man in the middle attack, but on company computers it may be a lot harder since the company also controls the clients.
So don't do your private banking in a company environment.
Re: (Score:2)
So don't do your private banking in a company environment.
Don't do private anything on company equipment.
What I do, though, is use my own equipment (phone or tablet) to do my private stuff, and I use an SSH tunnel to my home server for internet access, so that the company network never sees any traffic that it can decrypt. Not a solution for everybody, but it works well for me.
Re: (Score:2)
DNS can be sent down the SSH tunnel.
Even if this proxying feature were disabled, the network administrator could still see hostnames. They're in cleartext in the Server Name Indication field of the ClientHello message of any modern TLS connection.
VpnService; DNS over TCP (Score:2)
But how do you do this on a phone?
By installing an app that extends android.net.VpnService [android.com]. Or by tethering your GNU/Linux laptop.
SSH only tunnels TCP, DNS is UDP.
DNS can run over TCP. In fact, many DNSSEC responses are so big that they have to (source [networkworld.com]).
Re: (Score:2)
Teppies is correct, but my approach is a bit different. For safety, I tunnel all UDP traffic as well (not just DNS lookups) using a TCP wrapper.
Re: (Score:2)
I connect with my VPN without using DNS, and once connected, all traffic goes through the tunnel, including DNS lookups.
Re: (Score:2)
Use certificate pinning. Yeah, you won't be able to get out over the corporate shit without first tunneling elsewhere, but your coporate spues won't be able to see your shit if you pin to known good certs.
Re: (Score:2)
Except in this case, the zipper was broken when you got it, you unzip it ignoring the broken teeth, zip it back up ignoring the broken teeth, and everyone assumes you're protecting them against this so they don't notice that it's gotten a bit drafty.
Re: (Score:3)
Done perfectly, it's zero impact.
Which means there's always some amount of impact, since you can't guarantee that it's done perfectly. HTTPS inspection tools are engaging in a man-in-the-middle attack themselves, and are introducing a whole new attack surface. We don't just have to trust that the code itself is implemented perfectly, we also have to trust that the server running it is not compromised, or that a legitimate admin isn't engaging in some nefarious activity.
This negates a rather large portion of the strength (such as it is) of
Re: If it's unzipping encryption it has to re-zip (Score:2)
Yep, the IT group continually sends employees emails telling us how much they don't trust us, THEN the decrypt our SSL sessions and expect our Complete trust in them... no dice, you made it completely clear that No One could be trusted. How does your newfound snooping power change that concept?
Re: (Score:3)
The problem with SSL-unpacking proxies is the following:
- You can't pass along the original SSL certificates, so your clients all have to trust the SSL proxy
- You can't verify with your clients whether the SSL certificate is correct, so you have to either accept or deny all 'broken' SSL certificates.
- Since a significant portion of SSL implementations are expected to be broken (especially once you start dealing with parties like Microsoft, IBM and Oracle), your implementation also has to be broken.
HTTP/1.1 526 Invalid Server Certificate (Score:3)
You can't verify with your clients whether the SSL certificate is correct, so you have to either accept or deny all 'broken' SSL certificates.
That or the proxy could return a 526 ("Invalid Server Certificate") status. (The 52x status codes are defined not by any RFC but unofficially by the Cloudflare reverse proxy service.) The response body describes the problem and displays the details of the certificate that the proxy does not trust. If the user logged into the proxy has "Allow" privileges, the body contains an "Allow" link to let this particular device use this particular upstream certificate despite its use of an unknown issuer or obsolete c
Re: (Score:2)
And as you said, this is a single-vendor workaround and works only if you're interactive.
What's with the banner across the page? (Score:3)
So now Slashdot has to have ads everywhere, even across the page as I scroll down.
Actually, it's just a grey bar, because the adblocker stops the actual content. But I still have a grey bar that I don't want.
So long slashdot. It's been nice knowing you over the last 16 years.
Re: What's with the banner across the page? (Score:2)
Re: (Score:2)
It wouldn't be so bad if the ads weren't shifting the page by 200 pixels all through reading
Oh, that only impacts mobile devices - so it's obviously a tiny minority of the readership that's affected.
Just like the lack of unicode support doesn't impact a significant number of users either. Picky readers...
Re: (Score:2)
Re: (Score:2)
No, my page shifts around in firefox. On my phone I get a full page ad inviting me to enter a contest that I can't make go away. I have to close my browser and come back to read slashdot. At first I thought I had malware of some sort but it only happened on slashdot.
The nice thing about running an adblocker (Ublock Origin) is that I had no idea this was happening until you guys started mentioning it. Seriously, there's an easy solution for this.
I have Adblock running in Chrome, and even tried Adblock Plus as well. Both could "see" the grey bar, and could make it go away, but could not make it stay away. It's similar with sidebar ads on the yahoo page.
I could use the script blockers, and have before. But they make reading or adding comments very difficult/annoying, so I gave up on them.
I will try Ublock Origin and see if the grey bar goes away. Thanks for the info.
Re: (Score:2)
Ublock has made the gray bar go away and stay away.
Re: (Score:1)
Slashdot was never good.
Re: (Score:2)
I don't see those in my uBlock Origin.
Re: (Score:2)
Another poster above mentioned that one. I will try it and see what I get. Thanks.
Re: (Score:2)
I am now using uBlock Origin, and the gray bar is gone. I had to specifically target it and remove it, but it stays gone. Thanks for the help.
Re: (Score:2)
You're welcome. I remember having to block those big ad spots months ago too.
Re: (Score:2)
Re: (Score:1)
"Inadvertently"? (Score:3)
How is this inadvertent?
These tools have been out there for years.
The user of the inspection box is INTENTIONALLY looking at my encrypted data, which could include PHI, PCI, or just plain shit I don't want them to see. My security has already been breached.
That these boxes are even possible to create and deploy (i.e. that someone CAN grant a CA for the box (not even that someone will do so)) shows the untenability of the entire "web of trust" for certs that is supposed to make you certain your data isn't being hijacked over TLS.
As long as this is out there, one can have _zero_ confidence any TLS-encrypted session isn't being hijacked.
I hope there's a rebuild of encrypted transport, and that next time, they don't make certificates so horsey. No, I don't know how to do that perfectly. Seems there's no way to do it peer-to-peer if I have to go down to every bank or business with a printout of their cert and match it up.
Maybe there's something blockchain technology could offer to make certs truly verifiable...
Re: (Score:2)
An immutable database doesn't help here. This is about the intentional breaking of security for whatever reason. It's similar to you installing malware on your computer, you can't prevent stupid people from doing stupid stuff.
CA's are supposed to be responsible for the trust of a certificate. Even if a bank were to print out their certificate hash, you can technically generate another certificate with the same hash and you would also have to trust the $10/h teller and the branch's printer - I'd much rather
Re: "Inadvertently"? (Score:2)
Yes, but the exposure here is in no way related to the banks choice of a cert provider. The bank doesn't enter into it, except as a place to rob.
Because top-level CAs CAN issue more CAs, some WILL: to governments, and accidentally or on purpose to freelance thugs. The thug sets up an interception box with said CA, and starts DNS poisoning attacks: he's got you.
Would prefer a system where issuance of a CA is a matter of real-time verifiable record, as would be each CA and cert on my machine. The browser coul
Certificate Transparency (Score:2)
Would prefer a system where issuance of a CA is a matter of real-time verifiable record [...] blockchain might help here
Such a system is being built in response to the DigiNotar fraud of 2011. It's called Certificate Transparency [wikipedia.org]. And like Bitcoin, it uses a Merkle tree. Chrome already requires it for EV certificates and for certificates issued by Symantec.
Re: (Score:2)
That sounds promising. Thanks for the heads-up.
Re: (Score:2)
a) You can get multiple certificates from multiple CA's for the same domain for good reason (say you want to switch providers or have multiple servers you need to secure). An SSL certificate only establishes a weak verification of ownership and no relationship whatsoever to your IP or a particular system.
b) You would have to trust and be able to scan hundreds of CA's containing millions of SSL certificates. Most blockchains take anywhere from 2-10 minutes to do a verification, can take up to days or weeks t
Re: "Inadvertently"? (Score:2)
Yes, but what makes this box work is a phony _CA_. If I can verify the CA with a world-verifiable blockchain, then can't I trust the cert? Or at least make a smart decision about doing so?
Seems the size of the CA problem is orders of magnitude smaller.
What I want is to sniff the phony CA(s) and distrust all certs from it.
Modern TLS has not been SHAttered (Score:2)
Even if a bank were to print out their certificate hash, you can technically generate another certificate with the same hash
Good luck with that. For one thing, the existing SHA-1 attack is a collision, not a preimage, which is orders of magnitude harder. For another, web browsers aren't supporting new SHA-1 certificates, and SHA-256 isn't in foreseeable danger of even a collision.
Re: (Score:2)
Certificate pinning resolves this issue
How should a website get its certificate pinned [wikipedia.org] correctly if a user's first visit is through the corporate MITM?
In fact, Chrome disables pinning when a certificate chains up to a user-installed CA, such as a corporate MITM (source [chromium.org]).
US-CERT is worthless (Score:2)
No shit Sherlock this announcement is 10 years too late. Years ago the cert list was much better and regularly provided somewhat useful information. Now traffic is nearly nil and warnings they send are comically outdated.
What happened to the alternatives to SSL/TLS? (Score:3)
Various proposals have been put forward to replace various parts of SSL/TLS (including the broken CA model) with better things that can't be easily targeted with man-in-the-middle attacks.
The EFF has the Sovereign Keys project.
DANE stores security related information in DNS and is the subject of several RFC standards.
Other proposals exist to replace some or all of SSL/TLS as well.
Why are people out there in the real world (makers of web browsers and servers for example) not interested in implementing any of these alternatives to the current horridly broken system?
Re: (Score:2)
Because they all have the same problems and don't fix any of the article's problems. I can repackage google.com's DNS response and sign it with my own DNS key, as long as the clients of my server(s) 'trust' that I am Google, they will accept it as such and that is the entire point of security.
The simplest fix for these issues is to simply delete your company's and Microsoft's CA (if they use AD) from your computer - problem solved, it will no longer trust your company and you probably won't be able to get o
Re: (Score:2)
The way DNSSEC works is that everything ties back to the root namesevers and their special keys.
Unless you replaced the root DNS trust anchor in the OS/browser on every single system on your network (something that any well-written OS/browser should make it VERY hard to do) AND re-signed every single DNS request made through that network with a new set of keys chained off that new root trust anchor, you wont be able to defeat DNSSEC.
Its not like SSL where you can just add a certificate from your HTTPS-inspe
Re: (Score:2)
Unless you replaced the root DNS trust anchor in the OS/browser on every single system on your network (something that any well-written OS/browser should make it VERY hard to do)
I don't see how that'd work. Even if it's hardcoded into the kernel, someone who controls all endpoints on a LAN can just recompile the kernel from source [kernel.org] with a patch that changes the trust anchor to that of the MITM.
Re: (Score:2)
Not if you are on Windows (the kind of organization that would be doing MITM of this sort is likely going to be the kind of organization that runs Windows)
Re: (Score:3)
Windows supports multiple DNSSEC trust anchors (source [microsoft.com]) and deploys them through Active Directory Domain Services (source [microsoft.com]).
Re: (Score:2)
As you say, you have to insert the DNS trust anchor in the OS, just like you insert the CA in every OS you control for these proxies to work. Re-signing or filtering out the DNSSEC for a request is trivial at that point (basically make it appear as if the entire DNS tree doesn't have DNSSEC).
Many security tools are a security risk (Score:2)
no stupid... (Score:1)