Earlier quoted context omitted.
Why can't they just install their own self signed root ca on all their computers and continue MITM it?
Certificate pinning is used by some very common applications and can break a MITM that relies on a self-signed certificate.
ETS Isn't TLS and You Shouldn't Use It
11–20 of 112 posts
Re: ETS Isn't TLS and You Shouldn't Use It
#12So what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?
You can cover some of the same concern by implementing an agent on every connected computing device but this brings much greater complexity as you are monitoring potentially hundreds to thousands more places and still have to worry if you have complete coverage.
Consider an analogy of going through international customs. Do you employ customs officials at the border who are allowed to sample and inspect private belongings to verify laws are being followed? Or do you employ an official to help pack the belongings of each individual who you think may eventually cross the border? The second example is a bit stretched but hopefully illustrates the scale problem.
Re: ETS Isn't TLS and You Shouldn't Use It
#13Re: ETS Isn't TLS and You Shouldn't Use It
#14So what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?
No opaque data leaves my network
Then this is the only way you can have outbound HTTPS connections. And for e.g. a bank, certain legal firms, or any company that has a lot of sensitive data they either don't want to be leaked, or at least want the option of detecting when it is leaked, that is a somewhat reasonable stance. In the case of banks, this is needed for regulatory compliance regarding insider trading. For legal companies, I imagine this is about ensuring certain confidentiality. I could see the same thing for companies dealing with trade-secrets.
The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them.
This method is considered better than terminating TLS early at a proxy and setting up a separate tunnel to the clients because breaking PFS is passive, rather than active. Thus it is a lot less resource intensive, a lot less vulnerable (no internet facing box that, if broken, has all communication in plaintext), and introduces no extra latency.
It is essentially a 'better' way to do an authorized MitM on everything on your network, and some companies want this authorized MitM. Like any authorized MitM, it introduces a third party who can compromise security, which is not generally desirable, but some companies don't mind being that third party to their own employees.
Re: ETS Isn't TLS and You Shouldn't Use It
#15Earlier quoted context omitted.
Certificate pinning is used by some very common applications and can break a MITM that relies on a self-signed certificate.
Do you have any example of such applications that would be used by a bank?
Adobe Creative Cloud
Amazon Work Spaces
Docusign
GitHub
Google Drive
GoToMeeting
iCloud
Microsoft Office 365 Outlook.com
Microsoft Skype for Business
Salesforce.com
Note this typically refers to native applications and plugins which also connect over TLS and not web applications.Re: ETS Isn't TLS and You Shouldn't Use It
#16Earlier quoted context omitted.
Certificate pinning is used by some very common applications and can break a MITM that relies on a self-signed certificate.
Are those common applications necessary for their business operations though? They could just blacklist them entirely.
Re: ETS Isn't TLS and You Shouldn't Use It
#17So what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?
Disabling PFS and thus enabling the decryption of all TLS sessions should be a conscious decision rather than something that was there 'by default' (and could easily be abused).
Re: ETS Isn't TLS and You Shouldn't Use It
#18So what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?
The other side of the argument is frequently discounted and as an IT security person myself I understand that. However, there is a real challenge for companies who deal with large amounts of very sensitive data. To be able to effectively monitor for data loss it makes a lot of sense to be able to monitor the connection points between your protected network and outside networks. The move to all traffic being encrypted…
Re: ETS Isn't TLS and You Shouldn't Use It
#19Earlier quoted context omitted.
The other side of the argument is frequently discounted and as an IT security person myself I understand that. However, there is a real challenge for companies who deal with large amounts of very sensitive data. To be able to effectively monitor for data loss it makes a lot of sense to be able to monitor the connection points between your protected network and outside networks. The move to all traffic being encrypted…
But since every device needs to trust your CA aren't you forced to pack their belongings in either case?
Re: ETS Isn't TLS and You Shouldn't Use It
#20Earlier quoted context omitted.
There's a whole IT market segment around TLS decryption for corporate LAN. Basically corporate MITM that will decrypt TLS at the gateway / firewall, and with currently used TLS standards, will then re encrypt the traffic back to the client so the browser thinks it has a legit connection. It's used to scan packets for intrusion detection, for malware, to track for data loss like the article talks about.
All of those require your computer to trust a new Certificate Authority or you will get warnings all over the place. If there is a company that claims to be able to do it without trusting the CA or producing warnings I would love to see it. (seriously, I actually would love to see that). And if you are in a corporate environment using a company computer you forfeit your privacy anyway. You can always go somewhere els…