Live data from Hacker News

Industry Concerns about TLS 1.3

ietf.org

131–140 of 194 posts

Re: Industry Concerns about TLS 1.3

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

Put the cyber-snooping aspect aside for a minute.

Where have the banks been?

Why didn't this Andrew Kennedy guy (or any other banks) chime in when this was fresh?

Why did this only become relevant to them at the last minute? Forgive me, but I have no sympathy for these institutions. If they really cared about Security, they would have dealt with this nonsense a long time ago.

You want to excuse the banks because they are "big businesses [that] have regulations you don't understand or even care about", but for institutions where security is of critical importance, why haven't they been following this more closely?

This a case of pure neglect and greed.

Re: Industry Concerns about TLS 1.3

#132
post #129

Earlier quoted context omitted.

Unless the devices that need to be monitored are the endpoints. Do you really oppose the laws requiring banks to record all communication (including non-official channels) that goes in and out of their trader's computers? Or do you have an alternate solution that doesn't make circumventing it dramatically easier?

I'm not sure I follow what you're saying. I'm arguing that the banks should already be in full control of their endpoints, so I don't see why they can't perform the monitoring there. Nor do I think that banks should be facilitating the use of non-official channels for communication. As for circumvention: are you concerned about ensuring a complete communication paper trail or protection from insider threats?

And if you don't have control of your endpoints, any network monitoring or tls mitm is meaningless anyway, as the contents can always be encrypted again inside of the tls tunnel. Then you're back to square one, the inbound/outbound traffic is inscrutable to monitoring.

Re: Industry Concerns about TLS 1.3

#133
post #67

Earlier quoted context omitted.

> Apparently you never had a card skimmed 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. > Your card is cancelled and you have to wait some days for a replacement (requiring also that you update it everywhere) The new card arrived minutes ago! And that only because they had to send it to a different country. I would have gotten one…

> 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 second-factor for all online transactions.

Good God, what annoyance. My banks also tried to offer me this "service". 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.

Not to mention the whole plethora of online services I use that charge me monthly at random times.

Looking at my CC bills, I use CCs online multiple times a day. I'm so happy I don't have to approve each one of those. Good thing I could opt-out of 3DSecure too, which in the case of my bank uses SMS, which never arrives in time (or at all) while I am abroad.

> An inconvenience that is only required because the security of your cards is less than optimal.

There's no inconvenience. Even ignoring security, not having multiple cards and multiple banks is completely unresponsible. It increases availability for so many reasons. The security aspect of it is just bonus.

What is inconvenient is not being able to buy stuff in the US, or rent hotels and cars. Different people have very different definitions of inconvenient, I guess.

Re: Industry Concerns about TLS 1.3

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

Implementing an official Bump-in-the-wire MITM method for TLS would be the final nail in the coffin of the protocol; nobody would take it seriously and would move onto IPSEC. If big business needs to secure communications in and out of the enterprise, then they need to stop being lazy about it. Tap the endpoints and use internet proxies, block communications with unapproved websites, and install surveillance gear in…

I really like "public sediment"!

Thank you for the eggcorn.

Re: Industry Concerns about TLS 1.3

#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 is terrible for security. Usually this is by terminating the TLS at the proxy, scanning it, and then re-encrypting it with an certificate automatically generated and trusted by an internal CA (whose root certificate is installed on the machines).

The huge problem is that now everyone has to trust all the root CAs installed on the firewall, instead of being able to decide which ones to trust themselves. The firewall has to also decide whether or not to trust self-signed certificates.

Much better would be to be able to decrypt, re-encrypt with a certificate issued by a real CA, and then also send the original certificate along with the handshake. Then, the first time you visited a TLS site, it could pop up a big warning saying 'This traffic is intercepted by firewall.institution.edu, do you consent?' and have a little exclamation mark in the toolbar to always indicate that it's being intercepted. The browser would have to trust both the interception certificate (which encrypts between the firewall and the endpoint inside the internal network) as well as getting the original certificate and deciding whether to trust that (which you don't get now).

Re: Industry Concerns about TLS 1.3

#136
post #82

Welcome to almost two weeks ago? Given how many people seem to be upvoting and commenting on this link, was everyone else on vacation for some holiday I don't celebrate when this came up multiple times before? https://news.ycombinator.com/item?id=12560284 https://news.ycombinator.com/item?id=12561004 https://news.ycombinator.com/item?id=12563481

This had a much catchier, editorialized title earlier.

Re: Industry Concerns about TLS 1.3

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

> it will simply be decrypted at the boarder [sic] of the business and routed internally unencrypted.

If the banks do this, it's their problem, and I hope the regulators will be very unhappy about it. There is no need to make the defaults less secure for billions of people in order to make it slightly cheaper for a few large corporations to implement an obviously correct alternative.

Re: Industry Concerns about TLS 1.3

#138
post #129

Earlier quoted context omitted.

Unless the devices that need to be monitored are the endpoints. Do you really oppose the laws requiring banks to record all communication (including non-official channels) that goes in and out of their trader's computers? Or do you have an alternate solution that doesn't make circumventing it dramatically easier?

I'm not sure I follow what you're saying. I'm arguing that the banks should already be in full control of their endpoints, so I don't see why they can't perform the monitoring there. Nor do I think that banks should be facilitating the use of non-official channels for communication. As for circumvention: are you concerned about ensuring a complete communication paper trail or protection from insider threats?

The entire point of much of the legislation requiring monitoring of the communications of bank officials is to combat insider threats (though not to security in the usual sense). They're required to monitor all communication (i.e. not just official e-mail that can be easily monitored another way) so there is documentation if any of their employees does something funky (fraud, etc.).

In this case, the endpoint by necessity is physically accessible to the possible adversary, which means they have a whole host of methods for disabling monitoring software. It's much harder to interfere with a box which you don't have physical access to that is listening in on your communication, and which simply drops any data it cannot intercept.

Re: Industry Concerns about TLS 1.3

#139
post #132
post #129

Earlier quoted context omitted.

I'm not sure I follow what you're saying. I'm arguing that the banks should already be in full control of their endpoints, so I don't see why they can't perform the monitoring there. Nor do I think that banks should be facilitating the use of non-official channels for communication. As for circumvention: are you concerned about ensuring a complete communication paper trail or protection from insider threats?

And if you don't have control of your endpoints, any network monitoring or tls mitm is meaningless anyway, as the contents can always be encrypted again inside of the tls tunnel. Then you're back to square one, the inbound/outbound traffic is inscrutable to monitoring.

It's not meaningless, since for a lot of these laws doing something like that can be evidence of willfully trying to avoid the legally mandated documentation requirements and is illegal even if they can't access your information. As long as there is a paper trail from that, you're already in trouble.

Re: Industry Concerns about TLS 1.3

#140

Earlier quoted context omitted.

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

You're getting mixed up. DPI on TLS sessions requires a MITM. The problem is (apparently) that there are no enterprise-grade MITM solutions that support TLS 1.3

That argument is a non-starter. Surely somebody will build and market such solutions once TLS 1.3 becomes widely used.

The protocol must be finalized before enterprise-grade products can use it, not the other way around.

Post reply on HN