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.
Industry Concerns about TLS 1.3
141–150 of 194 posts
Re: Industry Concerns about TLS 1.3
#142Re: Industry Concerns about TLS 1.3
#143Earlier 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
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
#144Earlier 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.
Re: Industry Concerns about TLS 1.3
#145Earlier 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.
Re: Industry Concerns about TLS 1.3
#146Well, 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!)
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
#147There 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…
Re: Industry Concerns about TLS 1.3
#148There 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…
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
#149Earlier 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.
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?