Hacker News Reader

Comment by Spooky23 | Hacker News Reader

Obviously 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?

View on HN

Can you describe what is "knee jerk" about HTTPS everywhere?

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?

Should elementary aged school children have privacy while surfing the internet from school? If the answer to that question is "no" then the answer about HTTPS everywhere can be seen as knee-jerk.

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.

Yes, of course children should have privacy.

Don't forget that HTTPS everywhere is not just about privacy.

Your argument is that privacy and security stances for web browsing should be driven by what is appropriate for the 10-and-under crowd?

The situation you describe is a great use case for well-implemented TLS interception. There is absolutely no need to degrade security and privacy for everyone else just to cover this case of individuals in a more restrictive environment.

The question was "why not HTTPS everywhere?" which I've answered. Your rebuttal is "then don't use HTTPS everywhere!" then ok, we're in agreement.

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.

TLS interception does not equate to not using HTTPS. Loading a trusted MITM certificate into the trust stores of computers an organization manages is a perfectly valid way to use HTTPS that does not need to compromise the security of HTTPS, even if many products have implemented it poorly.

Yes, they should. They might want to look up information on abuse, sexual health or homosexuality in confidence.

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.

You're simultaneously saying that children should have privacy while also saying children should have browser extensions that monitors what pages are being visited.

> Should elementary aged school children have privacy while surfing the internet from school?

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.

> to identify things like pornography

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?

Of course I realize that TLS doesn't mask that. It doesn't matter though because https://reddit.com/r/nsfw or https://imgur.com/hotaction.jpg are both shrouded by HTTPS.

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 your therapists secretary, who has access to your medical records and your therapists notes be able to pick up malware from some drive by page and be able to exfiltrate your data without any audit trail or inspection?

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.

Do you realize what controls "Should person X be able to do Y" implies? We don't live in a surveillance state where we control people by all encompassing surveillance. This is the status quo, and there's a consensus to keep it that way.

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.

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

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.

> But this is more a problem with the knee jerk HTTPS everywhere movement and a quick and dirty response than anything else

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.

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

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

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

I think they did:

> How can you claim to protect customer data or respect customer privacy without looking at the data flowing out the front door?

Why can your employees access resources that aren't approved in the first place? Considering their machine contains such sensitive information, that seems irresponsible.

Because some of those employees are database administrators and business analysts.

Because others are customer service reps.

Because how do you do a job without the data required to do a job?

Who said they're not approved? People get approval to access all sorts of things that they aren't supposed to let out of the company. Or may be obligated to take certain steps to ensure that it's not just on the good graces of the employees to ensure doesn't get out.

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.

I agree with jerf here. In many cases I think the answer should be to create certain systems that are almost always offline (say after installation). We shouldn't be connecting the same computers that hold health records to the network that the doctor is checking Ask MD in the back office.

This is my point exactly. If you need to access health records you don't need to simultaneously access Facebook or Twitter. All resources should be approved, IE have a legitimate business purpose. This can be done easily in any enterprise firewall, simply implement a white list of acceptable sites and block everything else no DPI required.

Why do we have homicide detectives?

Murder and manslaughter are illegal!

How on earth do you identify the illegitimately outflowing data in the vast soup of data being emitted from the browser? Do you have a magic key that lets you decode Microsoft telemetry, for example?

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.

> How on earth do you identify the illegitimately outflowing data in the vast soup of data being emitted from the browser? Do you have a magic key that lets you decode Microsoft telemetry, for example?

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.

We have computers that do things. Google Fireeye.

> The browser and OS vendors don't provide high quality APIs for this purpose

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?

I think there should be an API that allows applications to use a managed service to read browser network IO without relying on a proxy.

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.

Speculating here: Assuming that you only let prod servers access customer data, you can restrict to which hosts the storage servers open connections to. No?

Sorry I'm not sure I understand - how can you do TLS inspection without breaking the security promise TLS is supposed to provide?

If you trust your proxy, and your software trusts your proxy's self-signed CA, then your proxy can MITM the connections and sign its own certificates, and you still know nobody "else" is listening.

It depends on who you trust. TLS inspection will break the security promise of TLS in a sense because your trust chain is no longer exclusively the operator of the website. However, the 'extra link' in that trust chain can be someone that you trust, for example an employer or trusted vendor. In this case, well implemented TLS interception changes the situation from "I trust google.com" to "I trust my employer and google.com", with proper cryptographic verification of both of those steps.

The owner of the computer and network can choose to trust itself, intercept traffic, and reencrypt using an organizational key.

Reply on news.ycombinator.com