Hacker News Reader

Comment by palant | Hacker News Reader

Note: I am the author of this article.

There are semi-legitimate use cases. One is intranets where you might want to have HTTPS on non-public resources. More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic.

And: yes, adding this certificate should normally be a user-initiated action. There is no way of preventing applications from automating it however. E.g. Firefox doesn’t have an API to install root CAs, so these applications package up NSS Tools in their installer, search for Firefox profiles during installation and add their root CA to any certificate database they can find.

View on HN

On a somewhat (un)related note: What has been the reception, if any, from the Korean side in regards to your research? I've lived in Korea on and off for around ten years, and their online 'security' has always both bothered and worried me. It's nice to see someone actually opening up this horrendous and intrusive mess of software and investigating it.

On the individual level, the reception is remarkably positive. I’ve had lots of people thank me for this research, including people working for government agencies.

The news coverage is mixed. Some articles are positive about this and are asking about how to improve this sad state of affairs. Others are parroting statements from the affected companies: not actually bad, difficult to exploit, misunderstanding of the domestic market.

And as to politics, it’s too early to tell I think. This definitely generated much attention. Whether all this attention will actually lead somewhere is impossible to tell at this point.

That's great to hear. Hopefully your Korean colleagues will help bring awareness to this issue as well. I imagine it would probably be hard for politicians to ignore or argue against the consensus of the top minds of the country.

HTTPS on non-public resources isn't doesn't need to use DIY certs, normal certs work fine. If you are afraid of hostnames showing up in CT logs, you can use wildcard certs.

Also TLS traffic inspection and antivirus can be done at endpoints.

Sure, antivirus software does inspection at the endpoints. Guess what: they usually employ their MITM CA for that. :-)

It’s not like I haven’t written about that before. Here is a particularly disastrous implementation: https://palant.info/2019/08/19/kaspersky-in-the-middle--what...

Yep, I think there are ways to do it without a MITM CA but they are more fragile.

There's also this post https://www.securityweek.com/antivirus-software-has-negative...

Both are bad but network level is worse.

>More commonly the company installs their own root CA however so that they can monitor all outgoing traffic. The other use case are antivirus applications – same reasoning here, they want to monitor all traffic.

How does this work with HSTS? There's a growing number of websites that will not load unless their legitimate certificate is present.

You're confusing HSTS with HPKP (key pinning). HSTS only mandates HTTPS but it never address what certificate is the server's. HPKP is the standard detailing certificate pinning (ensuring that the only certs are the correct one), but browsers ultimately decided against its implementation because of the difficulties associated with a hacked site effectivey ransomed by sending a HPKP with attacker-controlled certs.

Edit: since that you might get confused on why HPKP can ransom a site, consider this case:

0. The owner of the website doesn't know about HPKP or decides against implementing HPKP due to its burden.

1. Either the web server, DNS service or BGP corresponding to the IP address of the server is hacked. The attacker can now control the site.

2. The attacker then issues a new certificate. Since that they control the keys, they can send an HPKP header that only locks the key that attackers controlled.

3. Unknowing users visit the site. The site can either be still active (web server hack) or proxied back to the legitimate site (DNS or BGP hijack). HPKP keys are remembered.

4. The owner now realises that their site is hacked and tries to restore it. Let's assume that they have revoked their old cert and issues a new and shiny one which is never in the HPKP header in the first place.

5. Users visit the supposedly now-restored site, but instead of succesfully connecting back it errors out with an HPKP error. The owner can't do anything but to migrate to a new domain name.

We humans are a devious lot, aren't we?

Thank you for the clarification. As a site operator, how should we assure that a visitor's connection cannot be MitM'd? Is this why some apps only use their own internal trusted certificate list, in lieu of offering a webpage?

Can't they inform the HKPK list provider to revoke the old key after they regain control of the domain?

HPKP isn't a centrally managed list, it's remembered by clients who've received HPKP headers when visiting your site (or in this case, the attacker controlled site at your domain).

As dwattttt said, it's not a central list at all. Having a central list defeats the purpose of HPKP (since that governments can just force them to add another authorized key, and even if they only have remove-only policies I'm pretty sure that stripping HPKP defeats its own purpose).

TIL why HPKP dead, looks reasonable. Thanks.

Reply on news.ycombinator.com