Hacker News Reader

Comment by 1718627440 | Hacker News Reader

> But if someone is able to perform a man-in-the-middle attack against your website, then he can intercept the certificate verification, too. In other words, Let's Encrypt certificates don't stop the one thing they're supposed to stop.

But the certificate is signed with the key of Let's Encrypt and your own, both of which the private key never leave the server.

View on HN

The author is claiming that a sufficiently capable attacker can MITM the ACME protocol used to automatically renew certificates (and thus get a valid certificate issued for the victim domain with the attacker's private key). This is probably true as far as it goes, but certificate transparency logs make such attacks easy to detect, and browsers will not accept certificates that are not in the logs. Web sites that do not monitor CT logs probably are vulnerable to well resourced attacks of this kind, but I don't think there is a huge plague of them, maybe because attackers with the ability to MITM DNS requests for LE don't want to burn that capability on such easily detected attacks.

Also, if the CA runs the ACME check from five different validation servers that aren't all on the same continent, which Let's Encrypt does and all other CAs will be required to do in a couple years, then it is dramatically harder to simultaneously MITM them all. And if you really want to, you can use DNS-01 with DNSSEC, which means an attacker would have to be able to compromise DNSSEC on top of everything else.

> Web sites that do not monitor CT logs probably are vulnerable to well resourced attacks of this kind

How many web site owner really do that? I mean, even Cloudflare hasn't been running a tight ship in this regard[0] until recently.

[0]: https://blog.cloudflare.com/unauthorized-issuance-of-certifi...

Yeah, the argument apparently doesn't really grok how certificates are issued and why the changes exist.

Manual long term keys are frowned upon due to potential keyleaks, such as heartbleed, or admin misuse, such as copy of keys on lots of devices when you were signing that 10 year key.

Automated and short lived keys are the solutions to these problems and they're pretty hard to argue against, especially as the key never leaves the server, so the security concerns are invalid.

That's not to say you can't levy valid criticism. I'm not sure if the author is entirely serious either though.

p.s. Certbot and Cert-manager are probably fine, but they're also fairly interesting attack vectors

Also MITMing a user is much easier than MITMing Let's Encrypt themselves who perform multiple checks from different locations.

Yeah it reads as if the OP misunderstands the attack vectors of SSL. If there's a misconfiguration, or the server admin is not correctly authenticating the authority, then sure. But skips over what they mean.

Being generous I would say they are referring to if the client has an invalid ssl approved on their local, in which case its a client problem.

To ignore Encryption altogether is a silly idea. Maybe it shouldn't be so centralised to 1 company though.

My IT department performs a man-in-the-middle attack against all my VPN traffic, and issues on-the-fly certificates for all the sites I visit. There is zero warning on my side, and the only way I know of it is because I'm a nerd who looks into certificate chains sometimes. My other nerd coworkers are blissfully unaware.

EDIT: I understand how it works. This wasn’t my point.

Yes, but if you use HSTS a regular browser will flag that. Perhaps your browser is also "MITM"d via a management policy? hehe :S

This only works because you company's endpoints have been configured to trust the company's root CA. Which makes sense, because it's their device and their VPN.

They need to install their root certificate into your work machine's trust store. Which they can only do because they control the machine (or VPN software), and would not be possible for a regular machine.

Many people are using VPNs these days. Nothing prevents vpn-du-jour.com from similarly messing with your traffic. Moreover, any software you install with privileges could also install certificates. In this sense, “a regular machine” is only the one which has no other software installed.

The point (I think) that TLA is trying to make is that encryption isn’t enough. It wouldn’t be a good situation where someone looks at their house burning and says “well at least nobody could ever read my https traffic.”

> Nothing prevents vpn-du-jour.com from similarly messing with your traffic

The browser not trusting the CA that signed the certificate prevents this. As the commenter said above, they would first need to install a certificate into your list of trusted certs for this to work. Your IT department can do that because they have root on your machine, vpn-du-jour.com can not, and neither can anybody else without root.

It's been my belief that, when I download “VPN-du-jour Connector” from vpn-du-jour.com (the one with the green “Connect and Surf Securely” button), I need to give that installer root privileges (so it could “manage my VPN configuration.”)

Also, I believe that when I download “Shoot Your Friends Online” and install that, it also asks for root privileges (in order to make sure that no cheating software runs on my computer that would allow me to “shoot more of my friends quicker.”)

I also think that when I install “Freecell Advanced,” it also comes with “Freecell Advanced Updater” that needs root privileges (in order to “update Freecell Advanced.”)

Do I understand correctly that there is nothing stopping all three of these — running with root privileges — from installing certificates?

Yes, that's why having installers not provided by the OS is a bad idea.

If your threat model is “I am giving root privileges to software I don’t trust”, certificates are the least of your worries.

You don't need to install custom VPN software. If you do, that's kind of a red flag. Wireguard should be built in.

It's fine to still run the software if you trust it, though.

I wonder if you could roll your own VPN tunnel that directly connects to your home internet IP and passes custom encrypted payload that your IT department cannot decode. Would they just drop the connection if they can't inspect what your are sending?

The issue is that they control the device he is using, so they could simply verify it on device.

Reply on news.ycombinator.com