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…
Industry Concerns about TLS 1.3
161–170 of 194 posts
Re: Industry Concerns about TLS 1.3
#162That leaves two cases: internal client internal server and internal client internal MITM. For both of these cases, I see two easy solutions:
1. Log the session key.
2. Define a custom TLS extension that contains the session key encrypted with against a known bank-controlled public key and have the server/MITM send this extension after the handshake. Problem solved.
In any event, the internal client external server case is highly problematic. What's to stop, say, Snapchat from running an extra unauthenticated DH exchange in JavaScript and encrypting all the application layer traffic against the resulting session key? The MITM proxy won't notice unless it's very clever indeed and then all those nice MITM proxy logs are useless.
Re: Industry Concerns about TLS 1.3
#163https://www.ietf.org/mail-archive/web/tls/current/msg12266.h...
> The consensus in the room at IETF-89 was to remove RSA key transport from TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014.
https://threatpost.com/tls-1-3-working-group-has-consensus-t...
https://github.com/tlswg/tls13-spec/commit/5d861d58b8a5ef2e8...
Re: Industry Concerns about TLS 1.3
#164Earlier 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…
In Australia, you can activate the card terminal by inserting it, swiping it or tapping it. There is no difference in liability shifting.
In Europe, if you insert the card you'll be prompted for your PIN. If the transactions succeeds, the liability is shifted to you (the cardholder).
It just happens to be what consumers have become used to in each country.
Re: Industry Concerns about TLS 1.3
#165Earlier quoted context omitted.
> 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…
> insert PIN, wait another 5-30 seconds until the transaction runs, and then get my card back. Never had to wait that long (unless there is some issue at the bank but usually it just stops working all together when that happens) here in Finland. Also if you use a credit card instead of debit for payments under X euros it doesn't even call the bank just checks on the machine if the pin matches the chip.
The payment industry in the US did not properly prepare for the EMV transition, and it's pissing everyone off.
Re: Industry Concerns about TLS 1.3
#166There 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…
Sounds good to me.
Re: Industry Concerns about TLS 1.3
#167Earlier quoted context omitted.
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.
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.
Re: Industry Concerns about TLS 1.3
#168lolz
Re: Industry Concerns about TLS 1.3
#169I 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…
Re: Industry Concerns about TLS 1.3
#170Well, that was kind of a burn. Was the argument by the bankers basically a complaint that retooling would be very expensive? and/or that employee surveillance would be more difficult? (yeah, I'm sure everyone is a fan of that!)
> Was the argument by the bankers basically a complaint that retooling would be very expensive? Yes. Everyone else should be more vulnerable to MitM attacks and insecurities, because it's too expensive for them to fix their endpoints. I don't care. Security protocols are hard enough to design correctly, without adding crap like that. And, I don't care enough about their crappy business model to support it by giving u…