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

111–120 of 194 posts

Re: Industry Concerns about TLS 1.3

#111

Post by askmike »

Nursie wrote: post #53

While they were very late to the party, this is important for some sectors. Not the reliance on specific tech (RSA) but being able to go back and decrypt their own traffic later, with appropriate keys. They need to routinely spy on some of their people,amd trace what happens to their money. Not sure why this is a problem. Their use-cases are different to (say) a user of Signal.

> They need to routinely spy on some [..] people

Unfortunately this is very far removed from the goals of the IETF, who is striving for a more secure internet.

Re: Industry Concerns about TLS 1.3

#112

Post by vertex-four »

4ad wrote: post #93
XorNot wrote: post #92

Earlier quoted context omitted.

The CVV is optional depending on the type of transaction you're authorized to make.

In particular, Amazon does not require a CVV.

I've definitely had to enter a CVV on occasion on amazon.co.uk. And apparently on .in it even does that and uses 3D Secure!

Re: Industry Concerns about TLS 1.3

#113

Post by akvadrako »

ghshephard wrote: post #99
akvadrako wrote: post #37

Earlier quoted context omitted.

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…

If you control the server, you can decrypt any time you want, because obviously if you were able to decrypt at one time, you can do so later.

That's the whole point of forward secrecy. For the one session you use a temporary key which can't be recovered later. You can only decrypt the stream if you store that key.

Re: Industry Concerns about TLS 1.3

#114

Post by askmike »

CDokolas wrote: post #12

Well, North Korea is not complaining about TLS 1.3, why would banks have to? Their proxy servers are already MITM platforms that meet their needs for security.

Probably because Bank employees/customers use modern browsers/devices which will at some point drop support for anything but TLS 1.3. I don't think this will happen in North Korea.

Re: Industry Concerns about TLS 1.3

#115

Post by Yaa101 »

dimman wrote: post #90
ivan_gammel wrote: post #66

Earlier quoted context omitted.

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

Re: Industry Concerns about TLS 1.3

#116

Post by userbinator »

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…

If they just store traffic and can decrypt it afterwards with the private key that they likely already protect with very high security, I think that's better than having to log traffic and all the session keys which need to be protected in the same manner as the private key...

I agree that his message was a rational argument. The dismissive response was disappointing, however.

Ultimately, the conflict of interest here is created by the fact that not everyone wants the same set of security properties. (Rhetorical question: does everyone want DRM? It's "more secure"!) The important thing to keep in mind whenever reading about security is what it secures against. It is not unreasonable that banks want to audit the data that flows through their network, in the same way that I should also have a right to inspect the data my devices are communicating on my network. The example I like to remember is the smart TV that phones home with viewing info --- discovered because it was doing it in plaintext.

Rationale: We're trying to build a more secure internet.

Phrases like this rather bother me because it assumes everyone wants the same security properties, which is clearly not the case given this example. "more secure" against what? "secure everything against everything else" seems like a popular attitude recently, and I think it does more harm than good.

Relatedly, it's already hard enough with many "smart devices" that aren't full PCs to add your own CA and do MITM; I can't imagine logging session keys to be any easier if even feasible.

I'm with the banks on this one.

Re: Industry Concerns about TLS 1.3

#117

Post by userbinator »

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…

Taking this further, let's not forget the fact that some endpoints might not even be capable of hosting a "monitoring agent", or it be unfeasible to develop and install one on every single endpoint. Admittedly not directly related to financial institutions, but all the IoT stuff comes to mind as something even consumers would want visibility into the traffic of...

In fact, those endpoints themselves might be locked-down environments secured against monitoring... ironically by the same "secure everything against everything else" attitude.

Re: Industry Concerns about TLS 1.3

#118

Post by Aaargh20318 »

4ad wrote: post #67
raverbashing wrote: post #64

Earlier quoted context omitted.

> At the end of the day, I don't lose any money with the less secure technology. The bank does. Why should I care? Apparently you never had a card skimmed 1 - Your card is cancelled and you have to wait some days for a replacement (requiring also that you update it everywhere) 2 - The money you lost (in case of debit) will get back to you, after an investigation.

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

> This is the reason why I have multiple cards, and why I never mix up the cards I use online, with the cards I use physically at the store.

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

Re: Industry Concerns about TLS 1.3

#119

Post by matt4077 »

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…

As far I remember, major banks have been rather secure in the last decades, especially compared to the hipster hackers at Yahoo/Dropbox/github/....

So maybe their checklist is worth a look.

Re: Industry Concerns about TLS 1.3

#120

Post by raesene6 »

userbinator wrote: post #116
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…

If they just store traffic and can decrypt it afterwards with the private key that they likely already protect with very high security, I think that's better than having to log traffic and all the session keys which need to be protected in the same manner as the private key... I agree that his message was a rational argument. The dismissive response was disappointing, however. Ultimately, the conflict of interest her…

I would agree that not everyone wants the same set of security problems and that this causes the conflict evident in the mailing thread, not so sure I'm completely with the banks on this one though.

Standards bodies are trying to improve security for a very wide range of people and the obvious target with this is that they're trying to mitigate the risk that government agencies and others can passively read encrypted traffic and then demand access to the server's keys to decrypt.

This is a very real risk, and one with security benefits to mitigating.

Now obviously banks (and other corps) have a legitimate need to intercept and decrypt comms on their own networks. As long as they have control over one of the two ends of the communication, they can get access to the session key and then, to me, it's an implementation matter with their existing logging solutions to log that.

I'm not trying to trivialise the effort needed, but to suggest that there's no fundamental reason that they can' adapt existing solutions to address it, especially as we're not talking about some kind of near-term problem here. This will only come into focus when/if TLSv1.2 is deprecated and if the amount of places still supporting SSLv3 is anything to go by we're a really long way away from that.

So for me the idea of pushing things forward from a security standpoint at a protocol level somewhat outweighs the impact that organizations will need to modify their solutions over the course of the next say 10 years (that's a ballpark number I don't have a crystal ball that tells me when TLSv1.2 deprecation will occur) to address it.

Post reply on HN