Obviously: what they're saying is broadly true. I also agree with the other commenters here who are pointing out that this is largely a response to endpoint TLS interception, and that the point is to focus attention on tools that intercept but don't validate certificates --- CERT is not telling every Fortune 500 company and every federal agency to stop deploying BlueCoat boxes.

But the more important thing to push back on in your comment is the notion that a proclamation from CERT has any real meaning. It doesn't, even within FedGov IT.

US-CERT is explicitly calling out that many appliances and applications often are weakening security vs. the common TLS clients, by way of not properly validating certificate chains by proxy for the client and otherwise masking SSL/TLS issues from being surfaced to the end user.

I believe this is CERT trying to get software companies to get their act together on solving security-detrimental UX/UI issues vs. a blanket statement not to add TLS interception proxies to a corporate network.

This is the usual reaction to this I see everywhere. It doesn't match with reality. Read the complete paper by Halderman et al [1].

It says pretty clearly that all existing products lower the security in one way or another: "Our grading scale focuses on the security of the TLS handshake and does not account for the additional HTTPS validation checks present in many browsers, such as HSTS, HPKP, OneCRL/CRLSets, certificate transparency validation, and OCSP must-staple. None of the products we tested supported these features."

TLS Interception that doesn't degrade security is a myth that exists only in some parallel world fantasy. It's also not very surprising. Browser vendors have extremely qualified security teams that are involved in many ways in the development of stronger TLS protections. Nothing like that can be said about any of the vendors of interception products.

[1] https://jhalderm.com/pub/papers/interception-ndss17.pdf

Other than the unavoidable weakening of having another system seeing the unencrypted data, which is inherent in using one of these systems and can never go away.

In theory, yes, apart from the obvious "more attack surface" problem. They could check for HPKP, CRLset, CT. They could even do more. (CT checking is very basic in Chrome and nonexistent in other browsers.)

However in reality? No. In the real world Bluecoat manages to break TLS 1.3 deployment, although its designers tried everything to avoid that and they have been asked by Google to test that.

It became "extra cool" to hate on reverse proxies recently while everyone hates CloudFlare (and to be clear: I've hated CloudFlare since before it was cool to hate on CloudFlare, and you should check my comment and submission history to verify if you don't believe ;P), but what people are essentially complaining about are "it encourages you to do something insecure", which I think is actually largely true only of CloudFlare, and you have to remember that the vast majority of developers who are using CloudFlare are doing so because they don't know much about network administration.

But like, think about it this way: Apache is also an SSL termination point. The code in your website is likely 99% "transform a URL into SQL, then transform the result into HTML": it is just a dumb encoder/decoder, and pretty exactly analogous to an SSL termination point. If you really believe in true end-to-end encryption, then having this webserver in the middle is a bad idea: you should route requests directly to database servers and ensure that at no point does any non-database computer have a decrypted copy of the information that will eventually be rendered to the user.

Another thing to think about: if you are heavily concerned that the CDN or reverse proxy service you are using has access to your traffic, realize that they are no different than using a hosted server. We don't even need to invoke "the cloud" for this one: unless I built the machine myself, I have no way of knowing that the server I am renting to run my database server on isn't running under a hypervisor that is allowing dumps of my decrypted memory. A reverse proxy is just another piece of rented infrastructure that someone else is in control of, and I don't see many people (though if you are, that's great, and then I'd be really happy ;P) insisting that everyone build their own computers and host them at their office, to make sure decrypted data never touches a computer owned and operated by someone else.

The risk profile is also just so fundamentally different, in no small part due to these differences of "who is in control and how is it implemented". Let's say that CDNetworks is failing to check SSL certificates correctly: how exactly are you going to attack that against my website? I mean, sure: if you are a state-level actor, that is going to be easy, but otherwise, that's going to be extremely rough. An "antivirus" filter that, as described in this alert, is failing to correctly check SSL certificates... well, that opens you up to attack by amateur attackers that are "close to you", such as a stalker or an ex-spouse or a corporate competitor. You can't just claim "well, if I abstract away all of the details, they look the same"... you have to look at why you care and verify that you didn't strip away anything required and relevant.

My live seems more trivil now.

Both clients and servers can have TLS terminating things in the chains that perform arbitrary functions. All of them increase attack surfaces and risks of implementation bugs.

I can't say I haven't considered abusing PL/pgSQL to that point... ;)

I've mostly recovered from the experience, thanks, although I do have occasional flashbacks.

Those can equally happen the other way around. You might put an antivirus filter in place on your own network. Your hosting provider might set up their own reverse proxy.

> But like, think about it this way: Apache is also an SSL termination point. The code in your website is likely 99% "transform a URL into SQL, then transform the result into HTML": it is just a dumb encoder/decoder, and pretty exactly analogous to an SSL termination point. If you really believe in true end-to-end encryption, then having this webserver in the middle is a bad idea: you should route requests directly to database servers and ensure that at no point does any non-database computer have a decrypted copy of the information that will eventually be rendered to the user.

I agree with that - best to have the database and the web server on the same server, communicating via local socket or shared memory. Better still to compile the web layer and the data layer into the same unikernel. Current best practice (e.g. PCI-DSS) seems to accept having an (encrypted) network connection between distinct web and database servers, but only within a single physically secured rack. You're right that if you do the same thing with a load balancer (have it in the same physically secured rack as your web servers, encrypt connections between it and them) then it's no less secure, but I don't think people would want to be using a load balancer within a single rack anyway, since most of the point of a load balancer is availability and you want separate racks for that. Certainly a third-party reverse-proxy is a substantial weakening of security.

> I don't see many people (though if you are, that's great, and then I'd be really happy ;P) insisting that everyone build their own computers and host them at their office, to make sure decrypted data never touches a computer owned and operated by someone else.

I wouldn't go that far - AIUI PCI-DSS etc. require you have physically secured/access-controlled servers but allow you to rent space/power/cooling from a datacenter operator (though they don't get access to your rack, and possibly have to also be audited themselves).

> Let's say that CDNetworks is failing to check SSL certificates correctly: how exactly are you going to attack that against my website? I mean, sure: if you are a state-level actor, that is going to be easy, but otherwise, that's going to be extremely rough. An "antivirus" filter that, as described in this alert, is failing to correctly check SSL certificates... well, that opens you up to attack by amateur attackers that are "close to you", such as a stalker or an ex-spouse or a corporate competitor.

It's a different risk profile to be sure. Are you more worried about someone making a large-scale attack against the remote service you were connecting to, or just against the Internet in general? Or someone making a small-scale local attack? I think both can be serious; it's not just state-level actors but also large criminal rings or even political groups that would potentially have the resources to execute an attack against a particular service (e.g. a medical provider doing something politically contentious, or just anything that accepts credit cards / personal information).

Most certainly, there's no difference whatsoever (or almost so, if the reverse proxy is "smart" and has some application logic in it) if your webapp doesn't speak HTTP natively, but talks FastCGI/uWSGI/SCGI protocols instead. Which is quite common.

I mean, the actual interface (passing buffer pointers in the local process or passing same data via local UNIX sockets) shouldn't matter much, right? As long as interfaces have similar security properties and all the necessary data is passed around properly. A sufficiently privileged user can introspect both (with ltrace or tcpdump), and insufficiently privileged one can't do anything anyway.

They say pretty plainly that you need to ensure that such products provide correct certificate validation, since the client cannot do so reliably.

> In general, organizations considering the use of HTTPS inspection should carefully consider the pros and cons of such products before implementing

So I think there's at least some element of "don't do this unless you have to" in there.

But for the most part yeah, the alert seems to be more about ensuring the interception is done securely than about not doing it at all.

> No, they haven't.

The original report headline from US-CERT: "HTTPS Interception Weakens TLS Security"

That seems pretty unambiguous, regardless of your personal feelings regarding CERT or whether it speaks for the broader US government.

Yes, it's possible. The crypto bits the host is sending are different from the crypto bits the client is receiving. There are several ways to compare those, despite what the MITM box is doing. Out of band channels, timing, and order of data can be used.

I sometimes refer to HTTPS Everywhere as "Security Theater Everywhere". Before the mania for HTTPS, many sites only used HTTPS only for crucial transactions such as logins and credit cards. Those were infrequent enough that they didn't have to go through a CDN. Now, with HTTPS Everywhere, there's no distinction between the stuff that has to be hidden from observers, and the stuff which only needs something like Subresource Integrity to make sure it hasn't been messed with. So now the secure channel over which credit card numbers and logins are passed is exposed at the CDN.

Also, once you're signed in, every request sends a cookie which is also valuable to steal as it's an active session.

Every request needs to be encrypted. We haven't made TLS worse by deploying it everywhere.

How many more cases do we need where some stupid ISP or middleware puts ads into other peoples webpage. Not to mention that those ads might also be a security problem.

Privacy is another issue that HTTPS Everywhere at least helps considerably. The NSA literally tcpdumps the internet and uses sophisticated tools to analyse it. I prefer to have a internet that makes it hard for the NSA and company.

That's why the poster said "the stuff which only needs something like Subresource Integrity to make sure it hasn't been messed with".

Browser certificate validation hasn't been as simple as "check CA signature" for close to a decade, and even a decade ago you could configure your browser to trust only certain CAs, or, through the certificate exception manager, only certain specific certificates.

All of this functionality breaks MITM proxies.

https://jlospinoso.github.io/node/javascript/security/crypto...

Most of the usual client-side JavaScript crypto caveats apply: Of course, all bets are off if the man in the middle is also a man in your device. You should give up any expectations of privacy in this case.

In that case even if you MITM it - all the bad guy gets is encrypted (AES) data. Whitebox does sound a bit like black magic, but it's widely deployed (over 5 billion devices for Irdeto's) and add a nice layer to ensure that you're actually talking to the end users browser, and it's your code that's running on it.

However I'd also argue you don't actually need to stop people grabbing the data. Noticing achieves a large chunk of that, as (for example) I can notify the credit card system it's happened.

If you want to see exactly what it does and doesn't do see https://resources.irdeto.com/payments-banking/solution-overv...

And you can't guarantee that you can notify either, and for the same reason. The code that leaves your server won't be the code that actually runs on the client - it'll be a mutated version that will say "everything is OK" and acts normally to your server while it sends all the data somewhere else.

Nothing has changed since [1] was written; I don't see how that is anything but DRM promising more than it can deliver.

[1] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

It can't stop keyloggers, people looking over your shoulder, malware in the browser (MITB)/plugins as it still sits within the browser sandbox. It can in some cases detect that, and in some cases hinder it.

An attacker can stop it loading by MITM the connection, but then the site can't work against it's APIs as the solution also verifies as data goes into those API's the encryption is present and the code isn't tampered. If it's tampered a business rule is applied to decide what to do, either stop the messages, OR pass it back to risk management systems (very common in finance).

Alternatively, and in my opinion better, is to have a (sub)domain for static assets, served from the CDN, and keep the main one free from man-in-the-middle.

I wonder how schools and banks plan to react to this... Apparently financial firms have to record everything their employees do for some regulations.

To me, schools doing this sort of thing is wrong. I wouldn't be surprised if the principle would grab people's passwords and login to their accounts even. I know some schools even went as far to demand students hand over their passwords to social media when they report bullying... Which if the school blocks social networks anyways, I don't see how it's a school issue for what happens outside of school...

If this sort of thing really needs to be done, at-least people should be warned and aware they are being monitored. If it's for a bank and it's only company equipment everything is being monitored it seems a bit more okay to do if everyone is well aware. "You are only to use work computers for official business." sort of policy.

Phone calls, emails, instant messages and other forms of client contact, yes. Internet browsing history? No. Rest assured, many firms do this. But it's because they decided to, not because of regulation.

https://badssl.com/dashboard/

I'm currently fighting a battle in a company in the middle of rolling out Blue Coat ProxySG. I only became aware of it because it began causing interruptions to our work since none of the development tools get the necessary root cert to validate the certs that the proxy is rewriting. The root cert is only installed into the Windows credentials to make browsers work and it's left up to every client to fix whatever other problems they have.

One of the common arguments I've encountered from people is along the lines of "if the company trusts the security people, then I trust the security people". However this ignores the fact that the company has legally enforceable agreements in the form od employment contracts, NDAs, and what-have-you that protect the company against a breach of that trust.

But what kind of protection do you have as an individual if, for what ever reason, one of the security people decides to single you out while they have unsupervised access to you social media logins, personal email and credit cards numbers and financial details (and lets face the fact that everyone does all of these things to some degree on a work computer).

The answer is that you more than likely have no protection at all (likely not even in workplace law). Even if you suspected someone had inappropriately accessed your personal details, the company almost certainly has an IT policy saying that you shouldn't be using your computer for personal use. You're screwed.

However these inspection boxes drastically change the situation to what it was before, because most people outside the IT department won't even know about this drastic change in capability. And likely they try hard not to think about until (if) they discover something has happened. I'm sure everyone here is aware of the abuses of NSA employees spying on their wifes, or ex-es [0]. Such is human nature.

Sadly I suspect that all these arguments will do little to change the situation. It seems more likely that the companies who deploy these systems are only going to listen to arguments specifically about how it is increasing work, causing delays of deliveries and affecting project costs.

[0] http://www.reuters.com/article/us-usa-surveillance-watchdog-...

  > The answer is that you more than likely have no protection at 
  > all (likely not even in workplace law). Even if you suspected 
  > someone had inappropriately accessed your personal details, 
  > the company almost certainly has an IT policy saying that you 
  > shouldn't be using your computer for personal use.

This was what I sent to the HR lead immediately after the meeting:

I remember a while back we all signed some document regarding data security here. I don't remember what that document said specifically -- did it mention at all the possibility that all of our network traffic could be monitored? I ask because, while [new security guy] claims that with the new firewall "No data is stored or made available for other purposes," the fact is that it absolutely can be viewed and stored, and we as the end users have no way to verify whether it is or not. On Palo Alto Network's own website there are comments from other users of our firewall asking how to disable packet inspection in the logs because, "I can also see users passwords in some cases".

I understand and agree with the necessity of setting up a firewall that can inspect encrypted traffic. However, I also understand that this means everything we do or send on the office internet can be inspected by presumably anyone with access to the firewall's back end (including personal passwords and anything usually thought of as "secure"). I'm not sure how clear this is to some (or most) of the employees here. If the agreements that we signed don't reflect this, I think they should be updated and re-agreed to.

[some back and forth ensued, where she reminded me of a line in the agreement that does say we can be monitored at any time]

That may be fine then. All I know is that I heard some concern over being able to go to facebook and whatnot, which seemed to be relieved when we were told it would still work. I just don't know whether or not people realize that while they can still go to facebook, theoretically anything they say or do on it, including all of their login information, chats, and posts marked to be shown only to friends can (though not necessarily will) be viewed by the company as well.

I could be making a bigger deal out of this than it needs to be, I just tend to take online privacy matters pretty seriously. Assurances that the data will be treated responsibly (not viewed or cached) are all well and good, but at least for me, aren't good enough. I won't be going to any personal websites on the network here at all.

Acceptable use policies are not self-enforcing, they are really only used selectively, regardless if they say you shouldn't use your computer for personal use. Everybody does that to some degree and it is accepted in reality as long as it's within certain limits.

If the policy was self-enforcing then half the internet would be blocked, but of course companies don't do that because no one wants to work in that environment.

If you're watching porn or torrented movies, you'll either get a warning or fired, but the company will do nothing if you make an online payment.

But what happens if the proxy gets hacked and the attacker gets hold of your banking/personal logins/data? Who is most likely to discover the hack? Probably the same security guys who are managing the proxy. Will the security guys do the right thing and inform management that a hack occurred? Will the company also then do the right thing and inform all their employees that a hack occurred and now you might be missing some money? Will the company choose to hide behind the “acceptable use” policy to absolve itself from liability and say that it was you doing the wrong thing and stuck with the costs of your actions?

At each layer beginning at the individual working in the security team, to the whole security team, to the company management team, to everyone working at the company, that the incentives are aligned to cover up such an incident rather than reveal it.

The TLS inspection proxy is a bad system and worse still it’s a dangerous system in the hands of people who are not capable of providing and unbiased assessment of the risks they are exposing themselves and everyone else to, not to mention the company. It’s more than just financial risk, it’s the moral-hazard kinds of risk that really concern me because of the lack of transparency/understanding of its roll out, the incentives to cover up when something bad happens, and the lack of legal protections afterwards.

On the topic of liability and owning up to a potential hack, I think my company would be transparent about it, based on a history of being transparent about many atypical things in the past. We're not public, never received any VC funding, and nobody has any equity stake in the company except for the owner, who himself goes over the entire company's income statement in front of all the employees once per year to let us know where all the money's coming from/going to. I do believe he would do whatever he could to make it right, because the buck stops with him and him alone.

Clearly that's only a small comfort if our personal information is leaked, but I don't think in my case it would be covered up. I could certainly see that being the case in most corporate structures, though.

A way forward might be to start requiring TLS client certificates for business products. :-)

For us, we use TLS client certificate authentication to authenticate almost all our users so any TLS MITM breaks that and is unacceptable. This is really common and tens of millions of people use TLS client certificates this way everyday -- mostly with client certificates on smartcards.

HTTPS mitm proxying is a dumb idea that can't work right but is easy to sell to executives. It will be defeated until we're at the state of a few years ago, where the products that really matter, like banking, have tough security and the rest has less.

* certificate issues (expiration, domain mismatch, etc.)

* OCSP/CRL verification

* validation of HPKP header

I understand that few vendors may be doing it (I know one which does at least the first 2). Probably the worst offense is choosing the weakest TLS version + cipher to save resources, like using TLS 1.0 because it take less resources to decode/encode than TLS 1.2 + elliptic curve.

This isn't true. It takes less resources to use ECC. Vendors use TLS 1.0 because they use outdated software they haven't updated in ages.

In fact it seems to me that having the validation happening in one place may potentially be easier to maintain than across many different clients' software.

[0] http://wiki.squid-cache.org/Features/BumpSslServerFirst

[1] http://wiki.squid-cache.org/Features/SslPeekAndSplice

edit: reference peek-and-slice too

I know my organisation do SSL inspection, but they have whitelisted common personal websites like internet banking to protect the privacy of staff.

As far as I'm concerned, if your risk profile requires you to do SSL inspection then this is the right way to do it.

i don't feel like i have a healthy mastery of the ideas discussed in articles like this one.

[0] https://www.feistyduck.com/books/bulletproof-ssl-and-tls/rev...

- TLS v1.2 (https://tools.ietf.org/html/rfc5246)

- Certificate validation (https://tools.ietf.org/html/rfc6960)

- PKI is a little more tricky, as there's no single standard that defines it, though to get basic idea of what are certificates read RFC 5280 (https://tools.ietf.org/html/rfc5280).

Sure, you can dig as deep as you want, but these resources should give you a good starting point.

... no shit.

and I'm a dev at one of these companies!

We really didn't want to add the feature but we were bleeding customer's who for some reason had to have it. ( Yes, we do validate the certificates )

We decided to bite the bullet when it looked like even Google was "supporting" being mitmed as a customer pointed out.

Reading this article... https://support.google.com/a/answer/1668854?hl=en

was my biggest "fuck you" moment.

That's exactly why these systems are a danger to everyone and why you shouldn't be trusted to handle them.

We basically had to protect the executive network/fileserver from outside and inside threats, keep porn/facebook/twitter off the production floor, and the rest was my design to streamline development/production operations. I've never had so much fun writing iptables rules. It's probably swiss cheese by today's security standards and known vulnerabilities, but it was hot stuff in 2008. :)

I guess I cared an awful lot about users of my infrastructure. Now people consumer my relational schemas but I still care.

For instance, you could block lots of crap with the proxy, thus increasing your organizations security. Does your need to spy on employees watching porn outweigh the potential benefit of not having to deal with porn viruses?

You could also use the proxy to cache pages, so that your thousands of users don't waste bandwidth downloading the same pages over and over again. You can do this without harming your ability to spy on people.