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

141–150 of 175 posts

Re: Stop Breaking TLS

#141

Post by JetSpiegel »

acdha wrote: post #123
cornonthecobra wrote: post #37

> Consider this - what is the likelihood of every certificate authority on the Internet having their private keys compromised simultaneously? Considering that CloudFlare has managed to MitM a huge part of the internet, I'd say that probability is not just non-zero, but greater than by a worrying margin.

That’s not what MITM means, and also misunderstands how CAs work. Cloudflare is a concern for how many people would be affected if there was another Cloudbleed but misstating their relationship with their customers isn’t going to accomplish anything.

How is that not a MITM? Just because it's the modern day CryptoAG?

Re: Stop Breaking TLS

#142

Post by crote »

dcminter wrote: post #41
noroot wrote: post #28

Earlier quoted context omitted.

It's such a nightmare at my current job as well. Everything always just breaks and needs investigating how to fix. Even putting aside the MITM and how horrendous that is, the amount of time lost from people dealing with the fallout got to have cost so much time (and money). I can't fathom why anyone competent would want to implement this, let alone not see how much friction and safety issues it causes everywhere.

> I can't fathom why anyone competent would want to implement this Compliance. Big financial orgs. and the like must show that they are doing something about "data loss" and this, sadly, is the easiest way to do that. There's money in it if you can show them a better way.

Big emphasis on the "show you're doing something" part: actually being effective isn't a requirement.

Re: Stop Breaking TLS

#143

Post by crote »

jeroenhd wrote: post #72
gschizas wrote: post #11

The fact that most tools have completely different ways to allow them to add certificates is the biggest pain. Git, Python and Rust also have large issues. Git doesn't default to "http.schannel". Python (or rather requests, or maybe urllib3) only looks at its own certificate store, and I have no idea how Rust does this (well, I use uv, and it has its own problems - I know about the --use-native-tls flag, but it shoul…

On Android, macOS/iOS, and Windows, this is a solved problem. Only on the extremely fragmented Linux/Posix runtimes do these problems surface. Rust's solution is "it depends". You can use OpenSSL (system or statically compiled) or rustls (statically compiled with your own CA roots, system CA roots, or WebPKI CA roots). I'm afraid that until the *ix operating systems come out with a new POSIX-like definition that stab…

> On Android, macOS/iOS, and Windows, this is a solved problem.

Is it, though? It is absolutely trivial for an Android app (like the one you use for banking) to pin a specific CA or even a specific server certificate, and as far as I'm aware it is pretty much impossible to universally override this.

In fact, by default Android apps don't accept any user-installed certs. It uses separate stores for system-installed CA roots and user-installed CA roots, and since Android 7.0 the default is to only include the system-installed store. Apps have to explicitly opt-in to trusting the user-installed store.

Re: Stop Breaking TLS

#144

Post by apexalpha »

johncolanduoni wrote: post #62
apexalpha wrote: post #39

Earlier quoted context omitted.

Yes, at least in the Netherlands it is generally accepted that employees can use your device personally, too. Using a device owned by your company to access your personal GMail account does NOT void your legal right to privacy.

So does nobody in Europe use an EDR or intercepting proxy since GDPR went into force?

You can do it but you'd have to have a good case for it to trump the right to privacy.

It's not as simple as in the US where companies consider everything on company device their property even if employees use it privately.

Re: Stop Breaking TLS

#145

Post by itopaloglu83 »

lisbbb wrote: post #130
itopaloglu83 wrote: post #98

Earlier quoted context omitted.

Yes, but also it’s not an employer’s job to provide entertainment during work hours on a factory floor where there are machines that can kill you if you’re not careful. There’s a famous fable where everyone is questioning the theft victim about what they should’ve done and the victim says “doesn’t the thief deserve some words about not stealing?” Similarly, it’s a corporate network designed and controlled for work pu…

I agree with all you said, but it's not like it is well advertised by the companies--they should come right out and say "we MITM TLS" but they don't. It's all behind the scenes smoke and mirrors.

I agree, that’s a bad business practice.

Normally no personal device have the firewall root certs installed, so they just experience network issues from time to time, and dns queries and client hello packets are used for understanding network traffic.

However, with recent privacy focused enhancements, which I love by the way because it protects us from ISP and other, we (as in everybody) need a way to monitor and allow only certain connections in the work network. How? I don’t know, it’s an open question.

Re: Stop Breaking TLS

#146

Post by iso1631 »

zbentley wrote: post #129
iso1631 wrote: post #101

Earlier quoted context omitted.

It's also normally deployed by companies who want this level of access anyway If you don't then you're simply open to encrypted comms over your deep inspection TLS breaking box anyway

Eh, I'm not so sure. Most companies are only somewhat serious about infosec, so they run some light endpoint protection or BYOD, but don't do much network-level restriction on end user devices. For companies in that position, it's much cheaper to do that at the router/VPN endpoint layer with TLS interception--not only is the pricetag of doing that usually a lot lower than the per-seat license of a more capable endpoi…

IP level blocks will work fine for that

Re: Stop Breaking TLS

#147

Post by tialaramex »

dns_snek wrote: post #115
tialaramex wrote: post #113

Earlier quoted context omitted.

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

Your "I bet they're God" stance is even more naive. They're not God, they've got a finite budget both in financial terms and in terms of what will be tolerated politically.

Of course spooks expend resources to spy on people, but that's an expenditure from their finite budget. If it costs $1 to snoop every HTTP request a US citizen makes in a year, that's inconsequential so an NSA project to trawl every such request gets green lit because why not. If it costs $1000 now there's pressure to cut that, because it'll be hundreds of billions of dollars to snoop every US citizen.

That's why it matters that these logs are tamper-evident. One of the easiest ways to cheaply snoop would be to be able to impersonate any server at your whim, and we see that actually nope, that would be very expensive, so that's not a thing they seem to do.

Re: Stop Breaking TLS

#148

Post by acdha »

JetSpiegel wrote: post #141
acdha wrote: post #123

Earlier quoted context omitted.

That’s not what MITM means, and also misunderstands how CAs work. Cloudflare is a concern for how many people would be affected if there was another Cloudbleed but misstating their relationship with their customers isn’t going to accomplish anything.

How is that not a MITM? Just because it's the modern day CryptoAG?

Because it’s not an attack but rather a voluntary infrastructure choice by a company. We don’t say that Varnish is a MITM because it’s in front of my application, because it’s intentional and under my control. Misusing the term muddies the topic rather than adding clarity, and while there’s a very useful discussion about centralization or why Cloudflare’s most stringent customers might want to deploy their Keyless SSL service that discussion won’t happen if someone misuses the term.

Re: Stop Breaking TLS

#149

Post by acdha »

rini17 wrote: post #134
acdha wrote: post #120

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…

Are you aware how https proxying works? Clients use CONNECT method and after that everything is opaque to the proxy. So without mitm you only know remote IP address.

There’s another difference which is what I was referring to: in both cases, your proxy has to forge the SSL certificate for the remote server but in the transparent case it also must intercept network traffic intended for the remote IP. That means that clients can’t tell whether an error or performance problem is caused by the interception layer or the remote server (sometimes Docker Hub really is down…) and it can take more work for the proxy administrator to locate logs.

If you explicitly configure a proxy, the CONNECT method can trigger the same SSL forgery but because it’s explicit the client’s view is more obvious and explainable. If my browser gets an error connecting to proxy.megacorp.com I don’t spend time confirming that the remote service is working. If the outbound request fails, I’ll get a 5xx error clearly indicating that rather than having to guess at what node dropped a connection or why. This also provides another way to implement client authentication which could be useful if you have user-based access control policies.

It’s not a revelation, but I think this is one of the areas where trying to do things the easy way ends up being harder once you factor in frictional support costs. Transparent proxying is trading a faster rollout for years of troubleshooting.

Re: Stop Breaking TLS

#150

Post by arianvanp »

OptionOfT wrote: post #103
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…

The certificate presented is not a Cloudflare one. So it might be that they're using a custom one, which I believe is passed through end-to-end.

Cloudflare doesn't have their own CA. They use a bunch of third party CAs (LetsEncrypt, Google and W2)
Post reply on HN