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

Industry Concerns about TLS 1.3

ietf.org

Post reply on HN
Print view View original

101–110 of 194 posts

Re: Industry Concerns about TLS 1.3

#101

Post by tremon »

lexman0 wrote: post #18

There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business. Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users". The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt i…

I would have preferred if HN linked to this response, as it is much more in-depth: https://www.ietf.org/mail-archive/web/tls/current/msg21325.h...

Endpoint security is paramount, and some sort of network MitM system is absolutely not a replacement for endpoint agents. I would highly suggest deploying agents on your endpoints.

If you're relying on MitMing S2S traffic for debugging a payment stack, it sounds like your payment stack is opaque to you, which is not only a concern for security, but the general reliable operation of your payment stack as a whole.

Re: Industry Concerns about TLS 1.3

#102

Post by tremon »

superuser2 wrote: post #52
lazyjones wrote: post #33

Earlier quoted context omitted.

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

>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-b…

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.

Re: Industry Concerns about TLS 1.3

#103

Post by tremon »

xg15 wrote: post #96
kybernetyk wrote: post #75

Earlier quoted context omitted.

>Take this example: A regulation says... Then the regulations are faulty and need updating to be on par with reality.

Because why? The idea that an organization shots be able to monitor its own traffic seems quite reasonable to me.

But the organization already can monitor its own traffic. At the source, before it is encrypted.

Re: Industry Concerns about TLS 1.3

#104

Post by drvdevd »

xg15 wrote: post #95
drvdevd wrote: post #62

Earlier quoted context omitted.

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.

Re: Industry Concerns about TLS 1.3

#105

Post by drvdevd »

tremon wrote: post #101
lexman0 wrote: post #18

There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business. Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users". The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt i…

I would have preferred if HN linked to this response, as it is much more in-depth: https://www.ietf.org/mail-archive/web/tls/current/msg21325.h... Endpoint security is paramount, and some sort of network MitM system is absolutely not a replacement for endpoint agents. I would highly suggest deploying agents on your endpoints. If you're relying on MitMing S2S traffic for debugging a payment stack, it sounds like your…

Wow that is right in line with my own response and does change the conversation. Thank you.

Re: Industry Concerns about TLS 1.3

#106

Post by anonymousDan »

lisivka wrote: post #25
kbart wrote: post #6

"Like many enterprises, financial institutions depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation. Unlike some other businesses, financial institutions also rely upon TLS traffic decryption to implement fraud monitoring and surveillance of supervised employees." I'm at lost here. What…

TLS can be decrypted with private key. Just keep your private key secret. For example, this feature is useful for debugging TLS encrypted communication with server by capturing data and decrypting it using WireShark. Forward secrecy breaks that.

Ok I'm missing something here. If an internal bank employee initiates a TLS session to an external service, the only key the bank could hope to access is the session key if it has control over the end host, in which case it can just store the session key for each connection. What private key are you referring too if not the session key?

Re: Industry Concerns about TLS 1.3

#107

Post by qznc »

tremon wrote: post #101
lexman0 wrote: post #18

There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business. Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users". The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt i…

I would have preferred if HN linked to this response, as it is much more in-depth: https://www.ietf.org/mail-archive/web/tls/current/msg21325.h... Endpoint security is paramount, and some sort of network MitM system is absolutely not a replacement for endpoint agents. I would highly suggest deploying agents on your endpoints. If you're relying on MitMing S2S traffic for debugging a payment stack, it sounds like your…

The original request (see TFA) already addresses this:

> End point monitoring: This technique does not replace the pervasive network visibility that private enterprises will lose without the RSA key exchange. Ensuring that every endpoint has a monitoring agent installed and functioning at all times is vastly more complex than ensuring that a network traffic inspection appliance is present and functioning. In the case of monitoring of supervised employee communications, moving the monitoring function to the endpoint raises new security concerns focusing on deliberate circumvention - because in the supervision use case the threat vector is the possessor of the endpoint.

Re: Industry Concerns about TLS 1.3

#108

Post by WhitneyLand »

lexman0 wrote: post #18

There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business. Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users". The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt i…

I sense the response was somewhat less receptive for subjective reasons.

For example, his tone is too formal and sounds bureaucratic. He refuses to state his actual request until the end of a long winded description of his clout and authority.

I think people did listen but were turned off before he even got to the point.

edit: Oh dear. Just noticed he has a degree in political science and no development background. How can this end well for him?

Re: Industry Concerns about TLS 1.3

#109

Post by Lazare »

tremon wrote: post #102
superuser2 wrote: post #52

Earlier quoted context omitted.

>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-b…

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.

Re: Industry Concerns about TLS 1.3

#110

Post by joe563323 »

lexman0 wrote: post #18

There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business. Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users". The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt i…

Then the regulations should be changed, you stupid.
Post reply on HN