5 ms·

The easier way is to install their own CA in all internal-network devices, proxy/MitM all TLS traffic, and effectively block TLS traffic that does not trust/use

The easier way is to install their own CA in all internal-network devices, proxy/MitM all TLS traffic, and effectively block TLS traffic that does not trust/use their internal CA. (Easier way to guarantee all applications are "in compliance".) They can use TLS 1.3 in this model. So yes, agreed, enterprises could deal with TLS 1.3, but they'd rather the rest of the world use worse crypto instead. They'd always rather do nothing to upgrade/fix their systems. They can't help it - it seems less risky and costly, and it's their job to make an attempt to save that risk and cost. So you need to treat them like a natural phenomenon.

danpalmer 9y ago
That could be easier, but I wouldn't be certain of it. Between BYOD policies and apps certificate pinning it could still be difficult or a non-starter for some applications.
- emmelaich 9y ago
  Yes, certain websites (banks) or specific app endpoints might be whitelisted but for general use I think will give rise to modified browsers. Or versions of ssl libraries will which dump plaintext and/or intermediate for analysis. Either way this is an enormous amount of work for all organisations.
- ploxiln 9y ago
  I think proxy/MitM is perfect when combined with BYOD and app cert pinning. The user needs to opt-in to the end-to-end-security undermining corporate network. An app can opt-out of such networks. In which case you'll just have to use it at home, or over the cellular data connection. An app that is sympathetic to or sold for "enterprise" use will allow use of the user-added MitM CA in the system root CA store. Finally, a "guest network" could be created if the enterprise wanted to enable users to use BYOD and any app as they are normally used. It's just a matter of everyone making an honest choice between end-to-end security and "enterprise" interception. That was always the choice.
kevin_nisbet 9y ago
Sorry, I don't believe your statement to be correct. When using an algorithm with perfect forward secrecy, you negotiate an encryption key for the session with the remote endpoint. The CA's are used just to authenticate the endpoints in the key exchange. This is the reason for the complaint, with forward secrecy, even if you compromise a CA key, you still can't decrypt any traffic.
- 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.

danpalmer 9y ago

That could be easier, but I wouldn't be certain of it. Between BYOD policies and apps certificate pinning it could still be difficult or a non-starter for some applications.

emmelaich 9y ago
Yes, certain websites (banks) or specific app endpoints might be whitelisted but for general use I think will give rise to modified browsers. Or versions of ssl libraries will which dump plaintext and/or intermediate for analysis. Either way this is an enormous amount of work for all organisations.
ploxiln 9y ago
I think proxy/MitM is perfect when combined with BYOD and app cert pinning. The user needs to opt-in to the end-to-end-security undermining corporate network. An app can opt-out of such networks. In which case you'll just have to use it at home, or over the cellular data connection. An app that is sympathetic to or sold for "enterprise" use will allow use of the user-added MitM CA in the system root CA store. Finally, a "guest network" could be created if the enterprise wanted to enable users to use BYOD and any app as they are normally used. It's just a matter of everyone making an honest choice between end-to-end security and "enterprise" interception. That was always the choice.

kevin_nisbet 9y ago

Sorry, I don't believe your statement to be correct. When using an algorithm with perfect forward secrecy, you negotiate an encryption key for the session with the remote endpoint. The CA's are used just to authenticate the endpoints in the key exchange. This is the reason for the complaint, with forward secrecy, even if you compromise a CA key, you still can't decrypt any traffic.

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.