Live data from Hacker News

ETS Isn't TLS and You Shouldn't Use It

eff.org

11–20 of 112 posts

Re: ETS Isn't TLS and You Shouldn't Use It

#11
post #8
post #7

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.

Do you have any example of such applications that would be used by a bank?

Re: ETS Isn't TLS and You Shouldn't Use It

#12
post #2

So 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 and uninspectable breaks this paradigm.

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

#14
post #2

So 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?

If your stance is:

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

#15
post #8

Earlier 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?

I don't work for a bank so I can't speak definitively to their applications. A few sample applications I see listed as certificate pinned in Netskope (a CASB) though include:

  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

#16
post #10
post #8

Earlier 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.

besides, many of those applications depin when you install custom CAs, don't they?

Re: ETS Isn't TLS and You Shouldn't Use It

#17
post #2

So 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?

Corporate environments where "endpoint solutions" snoop through all traffic to detect malware activity. While I understand the use case, I would not support it. What I find unacceptable is, assuming the article is correct, that ETSI is asking NIST to recommend their crippled TLS in their new guidelines rather than TLS1.3.

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

#18
post #12
post #2

So 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…

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

#19
post #18
post #12

Earlier 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?

Hmm, I'm straining my own analogy already so I won't try to beat that horse any deader. :-) I am mostly trying to argue the positives of centralized inspection at network chokepoints in simplicity and guarantee of coverage.

Re: ETS Isn't TLS and You Shouldn't Use It

#20
post #5

Earlier 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…

Correct re: the root cert in my experience at least. They usually get pushed out as part of a Group Policy in Active Directory.
Post reply on HN