Live data from Hacker News

Industry Concerns about TLS 1.3

ietf.org

141–150 of 194 posts

Re: Industry Concerns about TLS 1.3

#141
post #29

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.

Deliberately weakening encryption also adds significant risk of leakage, this time on a global scale.

Re: Industry Concerns about TLS 1.3

#143

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

So here's how I'm imagining the current solution, as implemented at the bank I worked at. Remember first off, there is no route to the Internet from workstations. Everything goes through a regular old HTTP proxy running on a server that accesses both the intra and Inter nets. You send it the host you want ("GET https://example.com/"), it fetches it and returns the HTML. It is nothing more complicated than:

socat tcp-listen:8080,reuseaddr,fork 'system:curl $(grep -m 1 GET | cut -d " " -f 2)'

with a little logging to put Nefarious Sites on your Permanent Record.

Re: Industry Concerns about TLS 1.3

#144

Earlier quoted context omitted.

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.

[deleted]

Re: Industry Concerns about TLS 1.3

#145
post #132

Earlier quoted context omitted.

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.

It is at least meaningless from a data loss prevention/mitigation perspective.

Re: Industry Concerns about TLS 1.3

#146
post #3

Well, 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 up some of my security.

It's 2016, people. Grow up, or get out.

Re: Industry Concerns about TLS 1.3

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

No surprise, given the quality of the edge software of most banking systems. With few exceptions, they are howlingly bad. I cannot imagine what the insides of them are like.

Re: Industry Concerns about TLS 1.3

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

I sense the response was somewhat less receptive for subjective reasons. For example, his tone is too formal and sounds bureaucratic. He refuses to state his actual request until the end of a long winded description of his clout and authority. I think people did listen but were turned off before he even got to the point. edit: Oh dear. Just noticed he has a degree in political science and no development background. H…

> For example, his tone is too formal and sounds bureaucratic. He refuses to state his actual request until the end of a long winded description of his clout and authority.

I see that as just being a professional adult. He states who he is, which implies why his opinion matters, then he states his opinion.

'Please don't do this kthxbye!!!1!cos(0)!!' is hardly more persuasive.

Re: Industry Concerns about TLS 1.3

#149
post #81
post #63

Earlier quoted context omitted.

So my knowledge about how forward secrecy works in TLS is spotty to say the least but the server still has the decryption key in memory AFAIK. Why not sidestep the issue and just create a secure channel between the server and whatever middleboxes there are that need the key and just send the ephemeral key that way? I get that this would be less secure to use in practice because now anyone who gets control over the se…

The person requesting this change controls neither the server nor the client. They control the intermediate network. If they could log the ephemeral keys it would solve the solution, but only the server and client hold that.

As I understand it, if you don't have the server's private key it makes no difference whether a connection uses FS. FS merely means compromise of long-term keys does not compromise past session keys.

Surely for the presence of FS to be relevant, they must already have the server's private key, implying they do have control of the server?

Post reply on HN