Live data from Hacker News

Industry Concerns about TLS 1.3

ietf.org

31–40 of 194 posts

Re: Industry Concerns about TLS 1.3

#31

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

> display a very shallow understanding of how secure systems should work. They still ask about mother's maiden name, prevent paste of passwords, took forever to adopt EMV in the US and other idiocies It's security by cargo-culting

> took forever to adopt EMV in the US and other idiocies

Totally agree with your comment, but I'll go a little bit on a tangent here.

I am an European, all my cards have always had a chip, I have not even seen a card without a chip until I visited the United States. All this reluctance to adopt chips seems so ridiculous to me.

But then I spent more time in the United States and with magnetic stripe cards, and boy do I love the better experience.

Let's see, in the US I can swipe a card at any moment of the transaction, and this physical act takes less than a second.

With chip, in most European countries not only I have to wait for the cashier to scan everything, but I also have to wait for the cashier to press a magic button that says "card payment"; only then does the POS become active.

Then I have to plug the card in, different POS terminals require the card to be put in different orientations, wait 3 seconds for the terminal to do whatever, insert PIN, wait another 5-30 seconds until the transaction runs, and then get my card back.

Or let's look at NFC. I still have to wait for the cashier to scan everything and push the magic button, I have to press the card 3 seconds on the POS until the NFC chip is read. Since there's no feedback, I have no idea if I keep the card in the right place until it beeps. After that, it still takes the same 5-20 seconds until it's done. The only advantage of NFC is that I don't have to plug my card in the terminal, but since the progress feedback is worse, I am not sure how that is any improvement at all.

The user experience is so much worse. Why wouldn't I want a magstripe-only card? Yes, it's (vastly) more insecure, but I am not liable for fraud. I don't have anything to lose.

Re: Industry Concerns about TLS 1.3

#32
post #27
post #20

Earlier quoted context omitted.

> After all, who doesn't have a bank account? But rules and regulations shield me and give me legal and financial aid for the stupid thing my bank might do.

True enough. But those who steal your account information and use it to pose as you don't follow the rules and regulations.

But the bank follows the regulations that tell it to give me all my money back, if there's some fraud. I don't have any money to lose if the bank does not implement security properly. Only the bank has to lose.

Re: Industry Concerns about TLS 1.3

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

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

Re: Industry Concerns about TLS 1.3

#34
post #8

>>> 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 think that's a very biased way of looking at this request. They don't necessarily have a shallow understanding. They have a set of very strict rules they have to obey. If that means no privacy for the employees, then they have to implement no privacy for the employees. The reasoning of the author has been explained pretty well in my opinion. But that's completely orthogonal to the understanding how the secure syste…

Indeed, orthogonal. I think it's a denied attempt to connect cross-purposes. I.e. design for security with practicalities of implementation in a broader context.

I notice some posts argue that we should aim for a pareto-optimum and accommodate the banks, but really this should require a broad representation for the rest of the subjects of TLS 1.3 to work out exactly what the pareto would look like. Given that they are 15 drafts in, it seems to me that there has been ample opportunity.

Re: Industry Concerns about TLS 1.3

#35
post #9

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

Right. And at the end of the day, skilled attackers can either: a) not care if you decrypt their traffic as they're already in your network and it's too late by the time you're reviewing the incident or b) take a copy of your checklist and say, "well here's something they'll probably never figure out"

A little out of the checkbox thinking goes a long way for attackers. It could for enterprises too if they could overcome their inertia.

Re: Industry Concerns about TLS 1.3

#36

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

Usually Big Banking has a sufficient amount of employees that there can be a group that is very interested in the latest developments and a completely different group that only wants to check off boxes on a compliance sheet and change as little as possible "to avoid risk".

Re: Industry Concerns about TLS 1.3

#37

Isn't it pretty much standard for such organizations to have decrypting and re-encrypting proxy, with their own CA that clients have to trust? If they do, I don't see how forward secrecy changes much, and they just have to tap the plain text from the proxy. If they don't, I'm seriously surprised.

The original message does make dubious claims, but a little later in the thread, the real issue becomes clear.

from https://mailarchive.ietf.org/arch/msg/tls/1n1tQSGKMBJKsmuCe-...

"With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available. Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment."

As I understand their argument, if you control the server (and hence private key and cipher suite) you can store the traffic without MITM and later decrypt it if needed. With forward secrecy, that isn't possible.

Re: Industry Concerns about TLS 1.3

#38
post #31

Earlier quoted context omitted.

> display a very shallow understanding of how secure systems should work. They still ask about mother's maiden name, prevent paste of passwords, took forever to adopt EMV in the US and other idiocies It's security by cargo-culting

> took forever to adopt EMV in the US and other idiocies Totally agree with your comment, but I'll go a little bit on a tangent here. I am an European, all my cards have always had a chip, I have not even seen a card without a chip until I visited the United States. All this reluctance to adopt chips seems so ridiculous to me. But then I spent more time in the United States and with magnetic stripe cards, and boy do…

Well, having to wear a safety belt is also an inferior experience but we do it for safety

True, swiping is faster (but you have to scribble something on a paper or an e-screen where the end result usually resembles nothing like your signature) :)

I can agree with the criticism there but the tradeoff doesn't bother me (too much)

Re: Industry Concerns about TLS 1.3

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

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

Re: Industry Concerns about TLS 1.3

#40

Isn't it pretty much standard for such organizations to have decrypting and re-encrypting proxy, with their own CA that clients have to trust? If they do, I don't see how forward secrecy changes much, and they just have to tap the plain text from the proxy. If they don't, I'm seriously surprised.

You're assuming that IT staff in the banking industry is competent and that they have a good budget to work with, but a lot of evidence suggests that often neither of that is the case.
Post reply on HN