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

151–160 of 175 posts

Re: Stop Breaking TLS

#151

Post by treesknees »

sceptic123 wrote: post #86
treesknees wrote: post #82

Earlier quoted context omitted.

Security takes many forms, including Availability. Having branch offices with 100 Mbps (or less!) Internet connections is still common. I’ve worked tickets where the root cause of network problems such as dropped calls ended up being due to bandwidth constraints. Get enough users streaming Spotify and Netflix and it can get in the way of legitimate business needs. Sure, there’s shaping/qos rules and dns blocking. But…

I think that's a very loose interpretation of Availability in the CIA triad. This looks a lot like using the MITM hammer to crack every nut. If this is an actual concern, why not deny personal devices access to the network? Why not restrict the applications that can run on company devices? Or provide a separate connection for personal devices/browsing/streaming? Why not treat them like people and actually talk to the…

It’s not at all a loose interpretation.

Availability: Ensures that information and systems are accessible and operational when needed by authorized users

Re: Stop Breaking TLS

#152

Post by cxr »

MathMonkeyMan wrote: post #3

I remember at my first job, the internet stopped working at my workstation. I got on the phone with IT, and the guy said "looks like you don't have our new certificates." I asked why I would need my employer's certificates. He said "because we MITM every connection." I asked if that was even legal, and he said yes it's legal. At another job I was handling a support ticket where a customer was asking, in so many words…

No one who understands what "MITM" means should have any expectation that I/O with a device owned and administered by a third party can be trusted (whether they do it by subverting PKI with internal certificate or not).

Re: Stop Breaking TLS

#153

Post by acdha »

tptacek wrote: post #127
NicolaiS wrote: post #67

Earlier quoted context omitted.

TLS inspection can _never_ be implemented in a good way, you will always have cases where it breaks something and most commonly you will see very bad implementations that break most tools (e.g. it is very hard to trust a new CA because each of OS/browser/java/python/... will have their own CA store) This means devs/users will skip TLS verification ("just make it work") making for a dangerous precedent. Companies want…

Sure it can; it just requires endpoint cooperation, which is a realistic expectation for most corporate IT shops.

You also need some decent support + auditing. There are a couple of places to configure (e.g. setting CURL_CA_BUNDLE globally covers multiple OSS libraries) but there will be cases where someone hits one of the edge clients and tries to ignore the error, which ideally would lead to a scanner-triggered DevOps intervention. I think a fair amount of the rancor on this issue is really highlighting deeper social problems in large organizations, where a CIO should be seeing that resentment/hostility toward the security group is a bigger risk than the surface problem.

Re: Stop Breaking TLS

#154

Post by acdha »

iso1631 wrote: post #146
zbentley wrote: post #129

Earlier quoted context omitted.

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

Blocking IPs hasn’t worked well since the 2000s: if you block CDNs, you’ll find out how many legitimate services use the same CDN.

Re: Stop Breaking TLS

#155

Post by acdha »

pimterry wrote: post #8

It's definitely annoying if you work in enterprise, but on the flip side: the fact that these enterprise requirements exist is the main reason that TLS certificate configurability is possible at all, without which it would be dramatically harder (or impossible) to reverse engineer or do security & privacy research on mobile apps, IoT, etc etc etc. Enterprise control over company devices and user control over personal…

> Standardize TLS configuration for all tools, make easy cert configuration of devices a legal requirement

I think this is the right idea (it’s configuring dozens of things which causes problems) but the other idea I’d consider is standardizing a key escrow mechanism where the session keys could be exported to a monitoring server. That avoids needing active interception with all of the problems that causes, and would pair well with a standardized OS-level warning that all communications are monitored by «name from the monitor cert» which the corporate types are required to display anyway.

Re: Stop Breaking TLS

#156

Post by baobun »

mirashii wrote: post #94
bandie91 wrote: post #51

personally i'm happy that i can MITM my docker when it wants to pull gigs of images the 1000th time upstream and just serve them from a local OCI cache server instead.

You don't need to MITM docker for this, you can just configure your containerd or equivalent backend properly.

How about that build script cloning the same git repo or wgetting the same release bundle over and over?

Re: Stop Breaking TLS

#157

Post by parliament32 »

The author is complaining a lot about implementation pains without taking a step back and looking at why it exists in the first place.

Say you work at a place that deals with credit cards. You, as a security engineer, have a mandate to stop employees from shipping CC numbers outside the org.

You can educate all you want, you can have scary policies and HR buy-in, you can have all the "Anomaly detection, Zero Trust network architecture, EDR, Netflow analysis" in the world, but exactly zero of those will stop Joe Lunchbox from copy/pasting a block with a CC number in the middle into ChatGPT. You know what will? A TLS-inspecting proxy with some DLP bits and bobs.

It sucks, yes. But it works, and (short of the fool's errand of trying to whitelist every site any employee needs) it's the only thing that works.

And yes, I'm aware PCI DSS has additional requirements for CDEs and whatnot, but really this can apply to anything -- a local government office dealing with SSNs, a school with student ID numbers, a corporation with trade secrets.. these problems exist everywhere, and implementing PCI-like controls is often a bridge too far for unregulated industries.

Re: Stop Breaking TLS

#158

Post by dadrian »

parliament32 wrote: post #157

The author is complaining a lot about implementation pains without taking a step back and looking at why it exists in the first place. Say you work at a place that deals with credit cards. You, as a security engineer, have a mandate to stop employees from shipping CC numbers outside the org. You can educate all you want, you can have scary policies and HR buy-in, you can have all the "Anomaly detection, Zero Trust ne…

That is not true, you can run DLP on an endpoint directly and inside a browser directly (e.g. via an extension or direct integration hooks).

You can also try to stop the situation where the CC numbers are in the clear anywhere in the first place, so that you can't copy/paste them around. What happens if someone writes the CC number down on a piece of paper?

Re: Stop Breaking TLS

#159

Post by parliament32 »

dadrian wrote: post #158
parliament32 wrote: post #157

The author is complaining a lot about implementation pains without taking a step back and looking at why it exists in the first place. Say you work at a place that deals with credit cards. You, as a security engineer, have a mandate to stop employees from shipping CC numbers outside the org. You can educate all you want, you can have scary policies and HR buy-in, you can have all the "Anomaly detection, Zero Trust ne…

That is not true, you can run DLP on an endpoint directly and inside a browser directly (e.g. via an extension or direct integration hooks). You can also try to stop the situation where the CC numbers are in the clear anywhere in the first place, so that you can't copy/paste them around. What happens if someone writes the CC number down on a piece of paper?

Endpoint DLP helps but it's not even close to bulletproof. Just for fun, if you have DLP at work, open the integrated browser in VS Code and notice how you can send protected test strings without anything chirping you.

> CC numbers are in the clear anywhere in the first place

Sounds great in theory, until you realize that in a large number of industries the majority of employees need access to protected data to do their jobs. Imagine telling the IRS their employees can't see/use cleartext SSNs.

As for paper / mobile phones / whatever.. you're not wrong, but physical security is typically someone else's job.

Re: Stop Breaking TLS

#160

Post by dadrian »

parliament32 wrote: post #159
dadrian wrote: post #158

Earlier quoted context omitted.

That is not true, you can run DLP on an endpoint directly and inside a browser directly (e.g. via an extension or direct integration hooks). You can also try to stop the situation where the CC numbers are in the clear anywhere in the first place, so that you can't copy/paste them around. What happens if someone writes the CC number down on a piece of paper?

Endpoint DLP helps but it's not even close to bulletproof. Just for fun, if you have DLP at work, open the integrated browser in VS Code and notice how you can send protected test strings without anything chirping you. > CC numbers are in the clear anywhere in the first place Sounds great in theory, until you realize that in a large number of industries the majority of employees need access to protected data to do th…

Network DLP is also not bulletproof so I'm not sure what the argument is there. These things are all best effort.

> if you have DLP at work, open the integrated browser in VS Code and notice how you can send protected test strings without anything chirping you.

I recognize it's not instrumented, but how are protected strings getting there in the first place?

Post reply on HN