Hacker News Reader

Comment by opqpo | Hacker News Reader

What does "trojans at ISPs" even mean? TLS works end-to-end and ISPs can do absolutely nothing to see the plaintext. It's unless the CAs at users-side are manually replaced with fake ones nothing can be done. I've never used Windows since I was a kid but I am sure this is pretty much impossible on Linux for example since adding CAs require root privilege.

View on HN

Presumably, Germany would have little trouble compelling at least one root CA to sign any TLS certificates they wanted. Just a cursory search shows that Google Chrome, on Linux, trusts, e.g.

> CN = D-TRUST Root CA 3 2013 > O = D-Trust GmbH > C = DE

There is certificate transparency and pinning and so on, and they would be caught (probably, maybe) if they abused this carelessly and at scale, but in practice, for a small number of targets, it would be trivial to wait for users to connect to a less secured TLS site or even a plain-HTTP site (plenty still exist), and then use a browser exploit as the stage 1, followed by whatever escalation of privilege exploit and rootkit is needed. TLS is really good at preventing always-on dragnet surveillance of everyone's internet traffic, but not a counter measure against targeted nation state level attacks.

Well. That is the reason for Certificate Pinning. And these days there is no excuse to not enable it server-side. Helped me detect some MITM-Interceptions. Not that the content was malicious (OpenDNS just rerouted my requests to a "This site is blocked page", but the certificate was signed by Cisco, and thus valid. Certificate Pinning still picked it up. Little hint: It was an Archlinux-site.).

Here [1] it says that Chrome stopped supporting HTTP Public Key Pinning (HPKP) with Chrome 72. There are other debates on it. See the discussions for excuses.

Or is cert pinning something different than HPKP?

- [1]: https://security.stackexchange.com/questions/213410/did-goog...

Google, Mozilla, et al. should make a commitment to revoke the trust of any CA that is found to partake in behavior like that. Even retroactive revocation of existing certificates shouldn't be off the table if the offense is egregious enough.

It's actually pretty scary seeing just how many CAs are in the list of trusted CAs on any given device. While no government is beyond reproach, I do wish there were a way for me as a user to say "don't trust anything signed by CAs outside of these few countries, since it's most likely a hijack, phishing, or in the rare case that I did try to visit some random site, I can approve it manually."

You could, for example, use the Certificate Manager in Firefox to delete specific authorities you do not trust.

Browsers blacklisted Kazakhstan government certificate used for MITM which was not even trusted. It is absurd to expect anything less than blacklisting such a CA immediately. Certificate transparency is required for all certificates since April, 2018, so you can't really issue rogue certificate.

Here's the Bugzilla report where they actually request their root be added to Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1232689

The answer is basically "no".

AFAIK they used different certificate for MITM. Currently they are using certificate mentioned in that bug to issue certificates for government websites (like https://elicense.kz/ ), so actually a lot of citizens who need to use government services have to install that certificate as a root anyway.

I don't think that they would use that certificate for MITM. They're not fools and they understand that it would lead to blacklisting it which would halt a lot of operations in the country.

Does the browser check?

> It is absurd to expect anything less than blacklisting such a CA immediately.

Is it, though? Germany has a lot more economic leverage than Kazakhstan. Suppose they pass a law requiring any browser sold or otherwise offered on the German market to have the government certificate in the chain of trust... how many large companies would cave?

Thanks for this very insightful comment. I'm sure that wasn't obvious to many. It certainly wasn't to me.

FinFisher has "drive by infection" packages for sale called FinFly that require traffic injection, according to their brochure. How exactly those work today, i do not know. For example: until 2011 they used a bug in the self update code of iTunes. Having a network level man in the middle can benefit many complex exploit chains.

I hope someone sees this and can enlighten us on how the technique currently works with TLS being more prevalent.

The "Trojan" is simply the rhetorical framework chosen by German authorities. Their initial successful push for computer surveillance was in the form of the "state trojan", a piece of malware proposed to be installed on the systems of suspected criminals. Successive pushes have aimed at expanding out from there, using the existing capabilities as justification.

For many things there isn't really need to get the payload. Get the IP addresses, DNS lookups and TLS SNI information and correlate to information gathered from elsewhere and you can derive a lot.

+1 Hopefully DNS over tls and new sni encryption standards will put an end to all this in next 5-10 years

+1 for the optimism, but unfortunately even with those mitigations it is not enough. Using a VPN in combination with DoT/H is currently best practice I believe.

Even multi-layer VPNs or Tor leak data via global correlation attacks. We need VPNs and Tor to start doing network bandwidth padding.

Yes, I agree. Is there anything we can do in the meantime?

You can derive a lot just from the set of IP addresses accessed, even if those IPs are cloud/CDN providers:

"What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf

That is a good question.

Looking at some of Citizen Lab’s excellent reporting on FinFisher shows that victims were redirected to regular unencrypted http downloads when the malware was installed.

One of the examples given was when a user tried to download Avast antivirus from a well-known software hosting site and the download was done over http.

There are several security sites that have downloadable packet captures of malware infections where you can see in Wireshark that redirects are commonly used.

Browsers should phase out and block executable downloads from HTTP sources in 12 months.

They should not.

They should maybe give bigger warnings, but lets not break all of the old web just to protect a few more people against themselves.

Any untouched, unpatched, unmaintained executables from 2007 should not be ran today, period.

Conceivably: If you have MITM and can inject... you'd next need web browser 0day exploit chain w/ sandbox escape and then a stealthy trojan to install. This would obviously be quite the capability and require a lot of maintenance to work cross-browser, cross-OS, and evade security products / built-in security features. It is definitely possible however.

The law only requires an ISP to redirect traffic to a target specified by the Verfassungschutz (Constitutional Protection Office) or BND (Federal Information Office), for the purposes of listening in or modifying traffic. It doesn't seem to require installing or providing TLS cracking.

Well they can still see (to some extent) which websites you visit, and how often. And how much data you upload or download.

think mobile - isp are the place to conduct baseband attacks from.

Think storage - in a snowglobe kind of way, networking is just a dynamic storage pool (or tamperable storage in this case).

No-frills data means a lot nowadays.

Reply on news.ycombinator.com