Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Breaking TLS

markround.com

Post reply on HN
Print view View original

111–120 of 175 posts

Re: Stop Breaking TLS

#111

Post by immibis »

johncolanduoni wrote: post #106
immibis wrote: post #97

Earlier quoted context omitted.

Many programmers tend to treat the legal system as if it was a computer program: if(form.is_public && form.contains(private_health_records)) move(form.owner, get_nearest_jail()); - but this is not how the legal system actually works. Not even in excessively-bureaucratic-and-wording-of-rules-based Germany.

Yeah, that’s my point. I don’t understand why the fact that you could access a bunch of personal data via your work laptop in express violation of the laptop owner’s wishes would mean that your company has the same responsibilities to protect it that your doctor’s office does. That’s definitely not how it works in general.

The legal default assumption seems to be that you can use your work laptop for personal things that don't interfere with your work. Because that's a normal thing people do.

Re: Stop Breaking TLS

#112

Post by immibis »

johncolanduoni wrote: post #60
Msurrow wrote: post #53

Earlier quoted context omitted.

Yes. GDPR covers all handling of PII that a company does. And its sort of default deny, meaning that a company is not allowed to handle (process and/or store) your data UNLESS it has a reason that makes it legal. This is where it becomes more blurry: figuring out if the company has a valid reason. Some are simple, eg. if required by law => valid reason. GDPR does not care how the data got “in the hands of” the compan…

What if your employer says “don’t access your health records on our machine”? If you put private health information in your Twitter bio, Twitter is not obligated to suddenly treat it as if they were collecting private health information. Otherwise every single user-provided field would be maximally radioactive under GDPR.

I suspect they should say "this machine is not confidential" and have good reasons for that - you can't just impose extra restrictions on your employees just because you want to.

The law (as executed) will weigh the normal interest in employee privacy, versus your legitimate interest in doing whatever you want to do on their computers. Antivirus is probably okay, even if it involves TLS interception. Having a human watch all the traffic is probably not, even if you didn't have to intercept TLS. Unless you work for the BND (German Mossad) maybe? They'd have a good reason to watch traffic like a hawk. It's all about balancing and the law is never as clear-cut as programmers want, so we might as well get used to it being this way.

Re: Stop Breaking TLS

#113

Post by tialaramex »

dns_snek wrote: post #84
tialaramex wrote: post #34

Earlier quoted context omitted.

The whole point of the logs is that they're tamper-evident. If you think the certificate you've seen wasn't logged you can show proof. If you think the logs tell you something different from everybody else you can prove that too. It is striking that we don't see that. We reliably see people saying "obviously" the Mossad or the NSA are snooping but they haven't shown any evidence that there's tampering

> We reliably see people saying "obviously" the Mossad or the NSA are snooping but they haven't shown any evidence that there's tampering Why would they use the one approach that leaves a verifiable trace? That'd be foolish. - They can intercept everything in the comfort of Cloudflare's datacenters - They can "politely" ask Cloudflare, AWS, Google cloud, etc. to send them a copy of the private keys for certificates t…

> Why would they use the one approach that leaves a verifiable trace?

It is NSA practice to avoid targets knowing for sure what happened. However their colleagues at outfits like Russia's GRU have no compunctions about being seen and yet likewise there's no indication they're tampering either.

Although Cloudflare are huge, a lot of transactions you might be interested in don't go through Cloudflare.

> the hardware that generates those keys in the first place

That's literally any general purpose computer. So this ends up as the usual godhood claim, oh, they're omniscient. Woo, ineffable. No action is appropriate.

Re: Stop Breaking TLS

#114

Post by zmmmmm »

I'd like to know if there is any real world data about the effectiveness of TLS inspection in preventing harm. It's empirically a massive tax on any organisation that engages in any kind of software engineering or technical work. I estimate that something like 3% of all our engineering effort goes to working around the TLS inspection which breaks security on literally every piece of infrastructure we build. And it embeds all the harm that the article alludes to (and more). So it takes quite a significant balance of upside to counteract that.

So is the benefit worth it? Is there data to prove it? Or is it just authoritarian IT departments drunk on power implementing this stuff?

I'd love to know.

Re: Stop Breaking TLS

#115

Post by dns_snek »

tialaramex wrote: post #113
dns_snek wrote: post #84

Earlier quoted context omitted.

> We reliably see people saying "obviously" the Mossad or the NSA are snooping but they haven't shown any evidence that there's tampering Why would they use the one approach that leaves a verifiable trace? That'd be foolish. - They can intercept everything in the comfort of Cloudflare's datacenters - They can "politely" ask Cloudflare, AWS, Google cloud, etc. to send them a copy of the private keys for certificates t…

> Why would they use the one approach that leaves a verifiable trace? It is NSA practice to avoid targets knowing for sure what happened. However their colleagues at outfits like Russia's GRU have no compunctions about being seen and yet likewise there's no indication they're tampering either. Although Cloudflare are huge, a lot of transactions you might be interested in don't go through Cloudflare. > the hardware th…

That's the most naive take I've read online this year.

So your stance is that spy agencies aren't spying on us because if they were, we'd know about it?

Re: Stop Breaking TLS

#116

Post by halJordan »

port11 wrote: post #81
arianvanp wrote: post #18

Complains about TLS inspection, yet fronts their website on the biggest and most widely deployed TLS introspection middle box in the world ... Why do we all disdain local TLS inspection software yet half the Internet terminates their TLS connection at Cloudflare who are most likely giving direct access to US Intelligence? It's so much worse as it's infringing on the privacy and security of billions of innocent people…

Do you have an alternative, potentially one that's less centralised or private or in bed with three-letter agencies? I ask because my last infra was probed for vulnerabilities hundreds of times per day; putting Cloudflare in front with some blocked countries and their captchas brought the attempted attacks down to a few dozen per month .

I mean, is doing your own geo blocking actually a blocker for you?

Re: Stop Breaking TLS

#117

Post by kreetx »

arianvanp wrote: post #58
apexalpha wrote: post #36

Earlier quoted context omitted.

I'm not sure if you're serious but in case you are (or other people): TLS inspection is for EVERYTHING in your network, not just your publicly reachable URLs. Putting Cloudflare anti-DDoS in front of your website is not the same as breaking all encryption on your internal networks. Google can already see the content of this site since it's hosted... on the internet.

Given that 50-70% of the critical services I use in my daily life (healthcare, government, banking, insurance) all go through Cloudflare this practically means everything that is important to me as an individual is being actively intercepted by a US entity that falls under NSA's control. So for all intents and purposes it's equivalent. My point is: it's very hypocritical that we as industry professionals are complain…

Having an organization install custom root certificates onto your work or personal computer and hosting a public blog on Cloudflare are two entirely different topics.

That your healthcare, government, bank, etc. are using Cloudflare, is a third. In an ideal world I guess I'd agree with you, but asking any of these institutions to deploy proper DDoS protection may just be too much of an ask.

Re: Stop Breaking TLS

#119

Post by lousken »

Wowfunhappy wrote: post #70
lousken wrote: post #66

Earlier quoted context omitted.

Whitelists instead of blacklists?

I'm pretty sure we'd still need to break TLS. Domain-level just isn't granular enough.

I still find that dumb that you even need to do that. Machines especially for schools should be able to have software policies set directly on them to limit such sites.

I don't know how much chromeOS is configurable and if you can e.g. force it to only use specific network and network interface, or if a student can connect it to a different network somehow, because it would be kinda pointless otherwise.

Re: Stop Breaking TLS

#120

Post by acdha »

I really wish more places would enable explicit proxies: if you have a mandate to inspect all traffic, block 443 except to proxy.megacorp.com and configure clients to use it. You lose all of the bugs and security issues caused by the security software—fun fact, Palo Alto _still_ doesn’t correctly implement TLS 1.2!—which as the author points out is basically training users to disable validation or ignore errors. This is so common I’ve seen security people with the usual certs giving advice from ChatGPT to add -k to curl calls, which is especially great when that’s baked into a container which will run on other networks.

One really nice win is troubleshooting: inspection appliances break decades of performance and reliability work which groups like the Linux kernel developers have done, and they make all errors have the same symptom so the security team will now be the only people who can troubleshoot network-level issues. Explicit proxying can’t fix your network but it makes it very clear where the problem needs to be investigated.

Post reply on HN