4 ms·

You are right that with the CA key only you still cannot decrypt the traffic. However, your overal statement is incorrect. The network operators would also nego

by JelteF 9y ago

You are right that with the CA key only you still cannot decrypt the traffic. However, your overal statement is incorrect. The network operators would also negotiate the the encryption key, because the TLS is terminated at their proxy. This should make it easy enough to store these keys there and somehow sharing them from there. Instead of gathering them from all the client devices, which sounds like quite an undertaking.

kevin_nisbet 9y ago
Sorry, I miss-understood the part about specifically using a proxy to mitm traffic. However, I would contend using the proxy to be a bad model as well. Depending on the network / architecture, you have to deploy lots of proxies to different area's of the network, because everything you want to debug now requires a proxy, which add's latency and a potential point of failure. There is also a secondary issue, which is as a corporation you've created a set of encryption key's that all the devices on the network trust. This means if those key's are compromised, someone else can mitm all your corporate devices, even to services outside of the corporate network. This introduces a risk, that most organizations are not setup to appropriately protect from.
- ploxiln 9y ago
  True, it's a bad idea. But we're getting to the heart of the issue now. What enterprises insist on being able to do is at odds with the security the TLS working group is trying to give users (and service providers like Google and Apple). These must-decrypt-tls-traffic enterprises should do it in a way that costs them, in a way that exposes them to risks - not in away that puts risks on other users and service providers. For just debugging, they can have the endpoints which they are debugging dump the plaintext, I agree that's a better way. But let's be honest, they're mostly not debugging, they're trying to deal with intrusions, outbreaks, and untrusted employees.

by JelteF 9y ago

kevin_nisbet 9y ago

Sorry, I miss-understood the part about specifically using a proxy to mitm traffic. However, I would contend using the proxy to be a bad model as well. Depending on the network / architecture, you have to deploy lots of proxies to different area's of the network, because everything you want to debug now requires a proxy, which add's latency and a potential point of failure. There is also a secondary issue, which is as a corporation you've created a set of encryption key's that all the devices on the network trust. This means if those key's are compromised, someone else can mitm all your corporate devices, even to services outside of the corporate network. This introduces a risk, that most organizations are not setup to appropriately protect from.

ploxiln 9y ago
True, it's a bad idea. But we're getting to the heart of the issue now. What enterprises insist on being able to do is at odds with the security the TLS working group is trying to give users (and service providers like Google and Apple). These must-decrypt-tls-traffic enterprises should do it in a way that costs them, in a way that exposes them to risks - not in away that puts risks on other users and service providers. For just debugging, they can have the endpoints which they are debugging dump the plaintext, I agree that's a better way. But let's be honest, they're mostly not debugging, they're trying to deal with intrusions, outbreaks, and untrusted employees.