Hacker News Reader

Comment by jacquesm | Hacker News Reader

A mini audit along the lines of 'builtwith'.

Hm. Good idea, why not go a step further and turn the 'no server signatures' advice on it's head: full disclosure, server signatures on, in fact, list each and every component in the stack so that end users can (through some plug-in) determine whether or not a site is safe to use.

Of course nothing bad could ever come from that. /s

I'm all for making the use of for instance Cloudflare less transparent so that users know who they are really talking to, but I'm confused about how you'd want to establish what a site is running without giving a potential attacker a lot of valuable information.

View on HN

It would have to work without the site's permission, so the browser (or maybe a third party service) would do a basic vulnerability scan. Maybe orange could mean "a script kiddie could pwn this site in under an hour", and yellow would mean "we don't see how your ISP could mitm this, but server side providers (aws, google, azure cloudflare) definitely could."

FWIW, my personal website uses let's encrypt, so it would be yellow or worse.

Anyway, I like the idea of tying the security color in the url bar to an attacker model, since it at least gets people to think about attack models.

> FWIW, my personal website uses let's encrypt, so it would be yellow or worse.

This shouldn't effect your security stance.

There's a common misconception that you trust your private keys with your CA and they can somehow transparently MITM you. But they only have your public key, not your private keys, so they can't do that.

The security threat from trusted CAs is that they can MITM anyone, regardless of if you use them or not. BUT the attack isn't transparent, and things like cert pinning are effective in the real world from preventing attacks.

The attack is definitely transparent if you trust the CA that issued the MITM cert.

If you use cert pinning, like the DigiNotar/Iran/Gmail, you're still protected against a trusted CA, assuming you've communicated in the past, which is realistic for a real world attack.

It's an attack that's difficult to deploy because it's easy to detect if you're looking in the right places, and as soon as it's detected, you know the CA has been compromised, and the attacker loses a large investment.

It's not as difficult to deploy if you can only target specific users, but I agree with you. The problem with cert pinning is that it's hard to do, because, if you make a mistake, nobody can access your site for quite a long time...

Wait, why does letsencrypt allow mitm by server provider?

Domain validation only requires an HTTP response. They can easily MitM that specific response to fake a certificate for your domain.

Yes. This.

In particular, the company operating the data center your server is in can reliably do this, and so can the backbone provider they use, and probably the server's local government. The DNS provider that controls your domain can mitm the ca process too (though with a higher chance of detection).

The argument for making domain validation yellow (and not red) is that domain validation protects against attacks from residential ISPs / coffee shops, and it would also be hard for a foreign government to launch the attack against their own citizens. They basically have to compromise the CA, tamper with your browser, or just randomly break https with "bad certificate warnings".

Over time, I'd hope more bad security practices (crypto related or not) would lead to yellow bars.

For instance, intel secure enclaves help cloud security a lot, but they are still exotic. If they catch on, and you're at a vps that doesn't offer something like that, then you get a yellow bar starting in 2027.

It's hard to say if you're implying this is any different with other validation levels like OV and EV. The validation methods that CAs may use for OV/EV are the same ones they may use for DV. The only difference is that they also validate the organization's information of the certificate requester. In other words, someone with the ability to MitM traffic between the CA and the target's domain could still obtain an OV/EV certificate for that domain, they'd just have to verify they are who they claim they are on top of that (and they don't have to be the domain owner - there's nothing that says "only the legal entity owning the domain may acquire a certificate for that domain").

> The only difference is that they also validate the organization's information of the certificate requester.

Right, but if I go to PayPal.com and the address bar says "Comcast [US]" or "National Security Agency [US]", I'll know something's up.

Most of these issues aren't there with DNS based validation (presuming DNS-sec).

Though, that just shifts the potential problem towards anyone in the DNS-sec chain of trust. Most notably, the controller of the TLD (most often a government) and the registrar.

Thing is, those are also an issue with normal (http based) DV. After all, they could also change the A record for the domain they want a cert for.

I believe the current solution to all this is focused on detection rather than prevention (through certificate transparency and similar proposals). The idea being that any organization that isn't trustworthy will only get to pull of this hack once, in a short time frame before having their trust revoked.

Is there a risk model where you control the network enough to fake domain validation but only if the target initiates the request to Let's Encrypt?

Otherwise it doesn't matter if you use Let's Encrypt as the attacker could just initiate the validation regardless of your CA and end up with a valid certificate (which would still fail cert pinning)

Edit: Oh I see, it's a more about if DV should ever be green.

Got it. But this only happens once when you apply for the cert (or renew it), correct?

I'm not sure if letsencrypt (or other CAs) are willing to give out multiple DV certs for the same domain. I'd guess they do, so anyone that can MitM you and the CA can get a DV cert.

Reply on news.ycombinator.com