Hacker News Reader

Comment by walrus01 | Hacker News Reader

tl;dr: If you install and fully trust a root CA on your client device, of course your TLS traffic can be MITMed.

edit: the problem, obviously, is that this app tricked the non-technical people into installing/trusting the root CA for malicious purposes. Clearly this was malware.

View on HN

That's great for someone reading this forum to be aware of, but moms have no idea what any of the words you just wrote means. So if they were told they get a coupon for installing or some other bit of ridiculous things malware devs use, and yes I'm calling FB software malware. All of if it. Messenger, FB.app, everything. If it's from Meta, it's malicious.

That's a very good point. I have within recent memory installed my own internal CA that I run on Android devices that I own and trust, and the process on android 11+ is sufficiently daunting that 99.5% of peoples' moms could not do it in one or two clicks. You have to go deep into system settings and manually import the CA. This requires first file-transferring the CA file somewhere onto local /sdcard storage and possibly having a file system explorer app installed to be able to view its location on "disk" and pick it.

As is pointed out in the article, I would presume that Google saw the threat from allowing an app to install and trust a root CA as well, and removed the ability for a "one click" install of a root CA:

"KeyChain.createInstallIntent() stopped working in Android 7 (Nougat). A user would have to manually install the certificate. It would no longer be possible to have Facebook's CA cert installed directly in the app."

I would argue that everyone over the age of 8 can do it with sufficient motivation and quality documentation. $10-20 and the promise of more money doing some low-effort "consumer survey" or providing "extra analytics" is pretty enticing to a massive number of people really struggling in this country.

Despite being hard-up I don't think the vast majority of these low-income individuals would agree to being so egregiously wiretapped and data mined for future political ads on youtube or bundled into some other product without better compensation.

Try comparing P2P OTR E2EE vs Non-CA TOFU SSH

hell, even I don't know what the "words" you just used mean!

That got me too for a few seconds whilst my brain cogs whirred... but the latter sounds tastier than the former for some reason!

For those wondering:

  P2P OTR E2EE == Peer to Peer, Off The Record, End to End Encryption
  Non-CA TOFU SSH == Non-Certificate Authority, Trust On First Use, Secure SHell

Any app capable of installing a TLS CA is capable of writing to known_hosts (or authorized_keys, while we're at it).

"the average parent"

So I mean, just taking a quick look at the contents of /etc/ssl/certs and what Firefox shows me when I hit its View Certificates button, I see among dozens of other actors, Amazon, Microsoft, GoDaddy, and the Beijing Certificate Authority. No software has ever asked me if I want to trust any of these guys, they've been silently trusted during a software install I suppose. Does this mean they can all MITM my TLS traffic if they so choose?

Theoretically, yes, they could, I think. However, with Certificate Transparency, the fraudulent certificates these Certificate Authorities could create would have to be published in CT logs to be valid, where they would be quickly noticed, and the CA would (hopefully) lose credibility and be removed from device's trusted CA list.

Not in 2020, no.

HSTS causes your browser to pin the first cert that it sees (from sites opting in to this scheme), so nobody (even the legitimate operator) can swap it out before it expires.

https://en.m.wikipedia.org/wiki/HTTP_Strict_Transport_Securi...

And specifically to the scenario in OP, app clients these days do not use the OS cert store, they will ship a single well-known server cert and only accept that one. This doesn’t help with your Firefox usecase though.

When HSTS is enabled, browsers don't pin the specific cert, just that HTTPS is required. Pinning the cert would mean users would experience outages (because you can't swap the cert early), which would be a terrible experience.

HSTS is https required and it needs to be a validated cert; issued by a trusted CA and not expired (maybe also not before the not before date). And the usual ignore it and move on button is gone.

Doesn't help if you're worried about a trusted CA issuing a cert for your domain without your approval though. Certificate transparency helps a bit with that; Chrome requires certs issued with a not before after april 30, 2018 to be in CT logs[1], so at least you'll be able to know a certificate was issued for your domain. If that happens, you can ask the CA/Browser forum to investigate and there's a good chance the CA will get kicked out if there's not a good explaination of what happened. That's not perfect but it's better than without CT when you could only know about an unauthorized cert if you managed to see it.

[1] I think max validity was two years back then, so all current certs need logs

That’s not sufficient - you also need to intercept traffic somehow which they successfully accomplished by buying this vpn company and using them to proxy victims traffic through their infra

Victims that were being paid to participate?

Edit: Not excusing Facebook here, but feel like this whole thing is in a weird grey area. It is like getting paid to have a Nielsen box monitoring your TV and then complaining when you find out it also knew what you watched on your DVD player.

> Victims that were being paid to participate

I believe you might be referring to what happened in 2019? [1] This is a separate issue. [2]

I do clarify this in the blog post, although it might be better to move the relevant text near the introduction rather then in the middle of the post.

EDIT: I have also added a remark to the post that it is not clear if all users were MITM'd or just a subset

[1] https://techcrunch.com/2019/01/29/facebook-project-atlas/

[2] https://techcrunch.com/2024/03/26/facebook-secret-project-sn...

I think what is missing is a timeline and clarity about the actual steps users had to take.

1) Onavo was a (free?) VPN app acquired by FB in 2014. Facebook used it to collect “market research data.” People chose to download this, but thought it was a security product.

2) At some point (it looks like 2016?) they launched an iOS app called Research, using the same tech, which required users to install a certificate meant for internal Facebook employees. They paid these users to monitor their traffic.

Are you saying that the MITM was happening for users of (1) or (2) or both?

Read the wording on the apk[0] - while it does mention they collect data to improve fb product it sure doesn’t mention the data includes telemetry for competitors’ apps.

[0] https://apkpure.com/onavo-protect-from-facebook/com.onavo.sp...

Unless the TLS traffic uses certificate pinning.

Reply on news.ycombinator.com