Hacker News Reader

Comment by vertex-four | Hacker News Reader

The problem is, there’s no way to enforce this. If you are a CA, there is nothing technically stopping you from issuing a certificate for google.com. There’s no infrastructure for the ability to say “this CA is valid only for sites that agree with the risks involved in using it”.

View on HN

Actually, I believe there are. IIRC it's possible for a CA's root cert to be limited to only a certain TLD. There's an extension called "Name Constraints" that limits a Root SSL Cert, and I believe it is honored by chrome.

https://security.stackexchange.com/questions/31376/can-i-res...

It's an optional extension, so a client may ignore it without failing the connection. It needs a lot more adoption. I could, for example, instead of getting a wildcard cert, get LE to sign a CA valid for my domain. That way I can issue certs for my domain myself and put load off of LE.

Actually Firefox for example carries around code to arbitrarily set any restrictions on any of the root CAs in Mozilla's trust store.

These are documented, on a best effort basis, at:

https://wiki.mozilla.org/CA/Additional_Trust_Changes

It is true, however, that no equivalent rules are enforced in most generic TLS clients (e.g. using OpenSSL directly or something like Python).

Protocols allow for namespace restrictions on CA certificates. There could, in concept, be something stopping you from spoofing google.

https://www.ietf.org/rfc/rfc2459.txt - section 4.2.1.11, Name Constraints

Given that I don't think you can actually buy that kind of cert, and the term "CA" is accepted to imply "universal CA", you're correct.

I'm by no means an expert, but I believe Certificate Transparency provides a way to catch that rogue CA after the fact.

Only if the certificate authority doesn't implement a way of not submitting their cert to the CT log servers. Of course, eventually someone might notice (if the certificate is used widely enough - if it's used to attack specific known people, maybe not) and realise that a certificate is being served that doesn't have corresponding CT info, but browsers don't check that.

Browser can check that a cert has an equivalent CT Log entry. Chrome does since 2018. https://tools.ietf.org/html/rfc6962#section-3.3 https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...

The ct-policy link you gave and that section of RFC 6962 are about SCTs. The existence of the Signed Certificate Timestamp does not prove the certificate was actually logged, it just proves that the Log promises to log this certificate within the Maximum Merge Delay (24 hours in the case of the Web PKI). A log might in fact be lying or have suffered a grave technical problem.

Figuring out how best to have browsers check the logs are truly accurate while preserving user privacy (e.g. obviously if you call a log to ask "Did you log this certificate for clown-porn.example ?" it gives them a good idea about your taste in circus-related adult content which you probably don't want them to have) is an ongoing topic of research.

With SCT checks you're in very good shape already today - bad guys would need to compromise several distinct entities to successfully pull this off. It's just not quite "Fire and forget" safe yet.

If the certificate wasn't submitted to an otherwise trustworthy CT log server then there's no way to provide an SCT ("Signed Certificate Timestamp") for a qualified CT log server. Some browsers (including Chrome and Safari) expect to be shown qualified SCTs for certificates issued after a certain date.

The SCT is signed by the log, so if you want them to lie you'd need to control enough logs to get enough qualified SCTs. Bad news, for Chrome that means it must include a Google log, which means now you're asking Google to conspire against themselves.

For now you could sidestep this by issuing bogus certificates with back-dated issuance dates. But that will stop working once those dates are too long ago for a certificate to still be valid. I think that happens some point later this year or in 2021 maybe? If you show Chrome (perhaps other browsers but I've read the code in Chrome) a certificate in which the lifespan (between NotBefore and NotAfter) exceeds the maximum permissible lifespan at that issuance date, it treats the certificate as invalid anyway.

Reply on news.ycombinator.com