Industry Concerns about TLS 1.3 • Hacker News Board

Re: Industry Concerns about TLS 1.3

#151

Post by jpgvm » Wed, Oct 05, 2016, 2:24 PM UTC

rdtsc wrote: post #9

madmax108 wrote: post #2

>>> My view concerning your request: no. is probably the best response for the request. On a related note though, it's always amazing how on one hand Big Banking tries to show that it's in touch with the latest tech developments (Bitcoin Consortiums, RFID/NFC payments) etc. but on the other hand display a very shallow understanding of how secure systems should work.

I call it paper security or checklist security. Usually it is about implementing enough to check off a list of requirements from some document. Antivirus installed? Check (Nevermind it is a Linux box and AV loads a dubious proprietary driver in the kernel with a huge attack surface and remote exploit posibility because of how it does updates), such and such EAL-4 operating system intalled? Check, and so on ... So the…

We call them "CISSPs" where I have worked. It's a mostly derogatory term for whiteboard warriors of the security world. They usually have a CISSP but no other valuable security background, most certainly aren't programmers and have never even played with Metasploit let alone understood how you exploit a system.

Unfortunately (most) banks/big enterprise are full of CISSPs which is why they keep getting styled on all the time. If they woke up and hired real hackers, adopted real security practices and knowledge sharing they could drastically reduce risk and probably get better software and systems in the process.

Re: Industry Concerns about TLS 1.3

#152

Post by lazyjones » Wed, Oct 05, 2016, 2:24 PM UTC

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

Re: Industry Concerns about TLS 1.3

#153

Post by michaelt » Wed, Oct 05, 2016, 2:40 PM UTC

4ad wrote: post #133

Aaargh20318 wrote: post #118

Earlier quoted context omitted.

> I did! Just a few days ago! And it's a chip card, but doesn't matter since the skimmer used the information in the magstripe online. None of my cards have magstripes, that was phased out years ago, so skimming is only a problem because you still haven't migrated away from those. It's not a problem with the chip cards. Even if you got all the information on the card, my cards all require a second-factor for all onli…

> None of my cards have magstripe Good luck using them in the United States. > that was phased out years ago Where do you live? There have been chip-only debit cards all around the world, but I am not aware of anywhere in the world where they have chip-only credit cards (except maybe in Korea, not sure). Good luck showing up at a hotel without a credit card, or good luck trying to rent a car. > my cards all require a…

  I am sure going to wake up in the middle of the night
  just to approve Amazon's request to take my money for
  some product that I ordered during the day.

Credit and debit card transactions use a two-step process - first of all the charge is approved (between the customer, bank and retailer) and later the charge is transferred. The latter process requires no customer intervention.

In face-to-face retailing the two steps happen within seconds of each other, but they don't /have/ to. They can also charge slightly different amounts - for example if your card is swiped for a restaurant bill before you've chosen what tip you're leaving, or if your order comes in two shipments as it's partly back-ordered.

Any two-factor authentication for online use happens as soon as you give your card details, regardless of whether the retailer waits until the box is shipped before transferring the charge.

Re: Industry Concerns about TLS 1.3

#154

Post by ars » Wed, Oct 05, 2016, 2:41 PM UTC

jrockway wrote: post #5

I don't understand why the banks need to change TLS 1.3 to spy on their employees. When I was working at a bank, there were literally no routes from the Intranet to the Internet. Everything went through a proxy that blocked 95% of the Internet. Had to run a proxy server on jrock.us in order to get anything done. (They just bought the list of sites to block, and jrock.us never ended up on it. Blacklisting, very good s…

> I don't understand why the banks need to change TLS 1.3 to spy on their employees ..... run a proxy server....

You answered your own question. They need it in order to spy on YOU!

Their problem isn't the "good" employees who don't do stuff like that, their problem is exactly people like you who try (and succeed) to bypass things.

Re: Industry Concerns about TLS 1.3

#155

Post by [deleted] » Wed, Oct 05, 2016, 2:47 PM UTC

stephen_g wrote: post #135

I think this request is pretty unreasonable, and anything that stops the ability to passively snooping on TLS is a great thing. I think there could be a security gain though in adding support for a better way to actively MITM TLS traffic though - in having a proper mechanism for filtering proxy firewalls. For some applications (say, school networks) it is OK to monitor and filter traffic, but the way it is done now i…

[deleted]

Re: Industry Concerns about TLS 1.3

#156

Post by 4ad » Wed, Oct 05, 2016, 2:48 PM UTC

michaelt wrote: post #153

4ad wrote: post #133

Earlier quoted context omitted.

> None of my cards have magstripe Good luck using them in the United States. > that was phased out years ago Where do you live? There have been chip-only debit cards all around the world, but I am not aware of anywhere in the world where they have chip-only credit cards (except maybe in Korea, not sure). Good luck showing up at a hotel without a credit card, or good luck trying to rent a car. > my cards all require a…

I am sure going to wake up in the middle of the night just to approve Amazon's request to take my money for some product that I ordered during the day. Credit and debit card transactions use a two-step process - first of all the charge is approved (between the customer, bank and retailer) and later the charge is transferred. The latter process requires no customer intervention. In face-to-face retailing the two steps…

> Credit and debit card transactions use a two-step process - first of all the charge is approved (between the customer, bank and retailer) and later the charge is transferred. The latter process requires no customer intervention.

Yes, and Amazon does not do the 1st step when you order something. It does it some random time later (usually hours).

Re: Industry Concerns about TLS 1.3

#157

Post by zrm » Wed, Oct 05, 2016, 3:16 PM UTC

qznc wrote: post #107

tremon wrote: post #101

Earlier quoted context omitted.

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…

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

That complexity is a sunk cost. You can't guarantee that the network path through the inspection device is the only one available in a world of cellular data and tethering, twelve different kinds of VPN service some of which can purposely look like HTTP, file-level encryption etc.

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

If the user is the threat then everything on their endpoint is already compromised. Preventing external communication would then require prohibiting every mobile device capable of tethering, constant body cavity searches for storage devices or wireless hardware, etc. If you need that level of security then your internal network should not be connected to the internet at all.

And if you have internal threats but can't justify those measures then it's all the more important that everything is secured at the endpoints to protect the other endpoints from the adversary on the internal side of the inspection device.

Re: Industry Concerns about TLS 1.3

#158

Post by bchociej » Wed, Oct 05, 2016, 3:18 PM UTC

stephen_g wrote: post #135

I think this request is pretty unreasonable, and anything that stops the ability to passively snooping on TLS is a great thing. I think there could be a security gain though in adding support for a better way to actively MITM TLS traffic though - in having a proper mechanism for filtering proxy firewalls. For some applications (say, school networks) it is OK to monitor and filter traffic, but the way it is done now i…

I like your proposed (user-visible) solution quite a lot, this would be great.

I predict certain folks would respond to this by trapping themselves in the indefensible position of "but if they know we're intercepting them, how will we catch them being bad?!?!"

Re: Industry Concerns about TLS 1.3

#159

Post by bchociej » Wed, Oct 05, 2016, 3:24 PM UTC

ivan_gammel wrote: post #68

lisivka wrote: post #29

Earlier quoted context omitted.

MITM introduces significant delays, yet another single point of failure, adds significant risk of leakage. Current DPI are passive, so they have no such problems.

It's technical problem, that can be solved. Dedicated hardware optimized for MITM, probably.

It's already in use, in fact.

Re: Industry Concerns about TLS 1.3

#160

Post by bchociej » Wed, Oct 05, 2016, 3:25 PM UTC

lisivka wrote: post #29

jrockway wrote: post #22

Earlier quoted context omitted.

You don't need to do deep packet inspection when you just MITM all the traffic.

MITM introduces significant delays, yet another single point of failure, adds significant risk of leakage. Current DPI are passive, so they have no such problems.

There are absolutely "bump-in-the-wire" intrusion prevention systems with MITM capability.