Live data from Hacker News

Stop Breaking TLS

markround.com

71–80 of 175 posts

Re: Stop Breaking TLS

#71
post #10

I agree with the sentiment, but I think it's a pretty naive view of the issue. Companies will want all info they can in case some of their workers does something illegal-inappropiate to deflect the blame. That's a much more palpable risk than "local CA certificates being compromised or something like that. And some of the arguments are just very easily dismissed. You don't want your employer to see you medical record…

I’m all for privacy of individuals, but work network is not a public internet either. A solution is required to limit the network to work related activities and also inspect server communications for unusual patterns. In one example someone’s phone was using the work WiFi to “accidentally” stream 20 GB of Netflix a day.

What's the security risk of someone streaming Netflix?

There are better ways to ensure people are getting their work done that don't involve spying on them in the name of "security".

Re: Stop Breaking TLS

#72

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 stabilises a TLS API, regardless of whether that's the OpenSSL API, the WolfSSL API, or GnuTLS, we'll have to keep hacking around in APIs that need to be compatible with arbitrary TLS configurations. Alternatively, running applications through Waydroid/Wine will work just fine if Linux runtimes can't get their shit together.

Re: Stop Breaking TLS

#73
What changed my mind to be in favor of TLS inspection at work environments was seeing what kind of highly confidential stuff employees might be copy-pasting to random websites, LLM assistants, cloud-based "desktop applications" and such against the approved use policies of each of these tools without giving it a second thought.

TLS inspection products can intercept the paste transaction before the data leaves the company network, hitting the user with a "No you didn't! Shame on you!"-banner and notify the admins how a user just tried to paste hundreds of customers' personal information and credit card details into some snooping website, or into otherwise allowed LLM chat which still is not allowed to be used with confidential information.

There can even be automations to lock the user/device out immediately if something like this is going on, be it the user or some undetected malware in the user's device attempting the intercepted action. Being able to do these kinds of very specifically targeted interceptions can prevent potentially huge disasters from happening while still allowing users more freedom in taking advantage of the huge variety of productivity tools available these days. No need to choose between completely blocking all previously unseen tools or living in fear of disastrous leaks when there are fine-grained possibilities to control what kind of information can be fed to the tools and from where.

There are plenty of organizations out there where it is completely justified to enforce such limitations and monitoring in company devices. Policies can forbid personal use entirely where it is deemed necessary and legal to do so. Of course the policies and the associated enforced monitoring needs to be clearly communicated and there needs to be carefully curated configurations to control where and how TLS is or isn't intercepted so employee privacy laws and regulations aren't breached either.

Re: Stop Breaking TLS

#74
post #22

Our cyber team have installed zscaler on most people's laptop, and somewhere in the fabric of the office internet connection.[1] For those that don't know, its a MITM proxy with certificates so that it can inspect and unroll TLS traffic. ostensibly its there to stop data exfiltration, as we've had a number of incidents where people have stolen data and sent it to competitors. (our c-suite don't have as much cyber shi…

Security team in most of the corporates is just a bunch of checklists markers, so for zscaler, crowdstrike or whatever they’re doing for compliance and/or certification and you can’t say no to it because it’s the company policy and who know better than “security” team?

This is 100% true.

Re: Stop Breaking TLS

#75
post #73

What changed my mind to be in favor of TLS inspection at work environments was seeing what kind of highly confidential stuff employees might be copy-pasting to random websites, LLM assistants, cloud-based "desktop applications" and such against the approved use policies of each of these tools without giving it a second thought. TLS inspection products can intercept the paste transaction before the data leaves the com…

So deploy end point security, which sits in the kernel and can thus access the unencrypted communication

Re: Stop Breaking TLS

#76
This kind of TLS "man in the middle" tech is so frustrating to deal with, because it ends up breaking things.

For example, I've encountered zscaler setups in the wild which close TLS connections if non-HTTP traffic is encountered. Presumably the traffic inspection fails since there is no HTTP request, and this failure path closes the socket.

It's hard to say whether it's due to the customer's IT dept's config, or zscaler itself -- but as far as the customer is concerned, it's my problem.

Re: Stop Breaking TLS

#77
a company, I worked for, had their own endpoint which you can easily introduce in windows, unfortunately every other tls connection which does not use the windows certificate store breaks because of that, so maven, npm et al won't work

Re: Stop Breaking TLS

#78

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?

I have found a definite answer from the Dutch Protection Agency (although it could be out of date).

https://english.ncsc.nl/binaries/ncsc-en/documenten/factshee...

Re: Stop Breaking TLS

#79
post #9

Earlier quoted context omitted.

You should make it about CT logs. I believe you need to compromise at least three of them.

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

> It is striking that we don't see that

It probably just means they are asking the providers to hand over the data, no need to perform active attacks.

Re: Stop Breaking TLS

#80
post #30

Earlier quoted context omitted.

I wish so too, same for all the self-hosters using tailscale...

Tailscale cannot passively observe traffic. They could inject malicious keys into your config but would be hard to mask the evidence of that.

Would it be hard? I thought the point of tailscale was not having to manage or concern yourself with key distribution.
Post reply on HN