Some HTTPS Inspection Tools Actually Weaken Security (itworld.com)

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.

Comments

expose them to man-in-the-middle attacks

[fisted]

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:expose them to man-in-the-middle attacks

[bill_mcgonigle]

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 the concept of HTTPS interception.

Re:expose them to man-in-the-middle attacks

[JohnFen]

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

[93 Escort Wagon]

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

[JWW]

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

[Mindscrew]

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 absolutely ZERO expectation of privacy when using an asset that is provided by your employer.

Any IT group who is serious about decreasing their attack surface, knows that solution's like this are imperative to the overall security posture of the organization. Any IT department who is serious about protecting the organization knows; you just cannot allow unknown encrypted data to leave the network at the will of an employee.

The IT department doesn't give one fuck about your privacy.... as they shouldn't.
Its IT's job to protect the business from technology, and ensure that it has the tools and solutions in place to achieve the organizations business requirements. Yes, this includes middling SSL and TLS connections to ensure that company data is not leaking out of the perimeter.

If you don't want the IT department decrypting their data as it leaves their network; use your smartphone instead.

What's with the banner across the page?

[I'm New Around Here]

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:If it's unzipping encryption it has to re-zip i

[JohnFen]

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 HTTPS in the first place: that there were only two parties handling unencrypted data, the sender and the receiver.

"Inadvertently"?

[jddj]

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...

What happened to the alternatives to SSL/TLS?

[jonwil]

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:What happened to the alternatives to SSL/TLS?

[tepples]

Windows supports multiple DNSSEC trust anchors (source) and deploys them through Active Directory Domain Services (source).

Re:If it's unzipping encryption it has to re-zip i

[guruevi]

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

[tepples]

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 cipher suite. The IT department can view exceptions in effect.