Hacker News Reader

Comment by lazyjones | Hacker News Reader

> Take this example: A regulation says that all incoming traffic into a banking sector company must be scanned for potential vulnerabilities and exploits, and allows for "compensating controls". If the incoming traffic is unable to be decrypted at TLS1.3, it will simply be decrypted at the boarder of the business and routed internally unencrypted.

Sorry, I don't get it. All encrypted traffic is typically decrypted by the recipient. There's no need to add transport-level vulnerabilities to facilitate virus/exploit checks.

View on HN

>All encrypted traffic is typically decrypted by the recipient.

The use-cases for inspection at the corporate firewall are often explicitly about catching cases where the recipient isn't policing itself:

- the device is compromised, exfiltrating company secrets, but has been rigged to send false reports to the central antivirus server saying it's clean.

- the device is not something it makes sense to install a host-based IDS/firewall/AV on.

- the device is assigned to a broker-dealer who is using a non-work email account to give fraudulent advice to clients off the record.

In an enterprise IT environment, "the recipient" is the company, and the company has internal controls, often required by law or regulation, that involve i.e. people who are not salesmen or traders (IT, compliance, legal, etc) knowing what information flows into and out of the sales and trading departments.

The use-cases for inspection at the corporate firewall are often explicitly about catching cases where the recipient isn't policing itself

But I don't want financial institutions to use clients that can't be trusted to police themselves.

Yeah? Neither do they.

>- the device is compromised, exfiltrating company secrets, but has been rigged to send false reports to the central antivirus server saying it's clean. - the device is not something it makes sense to install a host-based IDS/firewall/AV on. - the device is assigned to a broker-dealer who is using a non-work email account to give fraudulent advice to clients off the record.

So, because banks fail at keeping their devices secure, TLS 1.3 must be weakened? I don't see a convincing case here.

The third point especially seems a bit ridiculous: non-work accounts can probably be used from anywhere, why would said broker-dealer bother using the bank's network for his fraudulent activities? If he controls his device, he can use an LTE USB stick, an external VPN with a cipher of his choice etc. ...

The guy is basically complaining that they have to change all their infra over to MITM versus just decrypting traffic with private keys.

He is right, it will be expensive. And he has a right to complain. Should the working group ignore him? It's a tough call. You risk forking standards when you start to do that.

I think the working group should ignore him because he ultimately wants to save a buck now and shoot himself in the foot, he just doesn't realize it yet.

The enterprise as walled garden approach to security seems quite out of date and is harmful to all parties involved. Like it or not, the Internet at large has made our life one big WAN party, and we need to come to terms with that sooner rather than later.

That clashes big time with the fact that more users than ever are online today with no clue at all about security. (And it's not practical to change that)

So how would that new approach look? The de-facto solution today is that security is more and more delegated to device vendors and cloud providers. But that seems worse to me than delegating it to the admins of your organization that you know and trust.

I don't think it's so much about who you delegate responsibiltiy for securing networks to so much as how that security actually works. I believe traditional perimeter security is dead or dying and the idea of incident responders manually pouring over pcap files just doesn't scale much further either.

We need machines and global policy to help do this work and we need to stop putting faith in magic black boxes which we know will be thoroughly compromised (e.g.: all enterprise vendor equipment).

More on point, TLS 1.3 seems like a step in the right direction of thought: that you can improve your local security posture by improving the global posture.

The problem he has is that while we're obviating the need for a wall, we're also denying even the possibility of an attractive ironwork fence.

It will be expensive, but there's a big market for that. I'm pretty sure that the costs will fall, as soon as the industry understands the demand.

Most likely yes, the only sad part is that as soon as there's a cost for banks, it's the customers who ends up paying for them one way or another.

Which is not the worst outcome since customers too will benefit from the security...

All encrypted traffic is decrypted by the recipient, sure. Who's "the recipient" though? Do all your services handle tls, or do you terminate tls at an haproxy/Nginx/etc before hitting the actual services? How many hops do the unencrypted payloads take inside your network? Do you agree that it would be best to reduce that number to a minimum? There's ways to work around this, but they have trade offs associated with them, and they do have a reasonable requirement here.

Reply on news.ycombinator.com