Hacker News Reader

Comment by Pannoniae | Hacker News Reader

Even worse, HTTP/2 and HTTP/3 (and basically every new web technology) is only usable over HTTPS. I'm seriously starting to question the agenda behind this, this is not beneficial to the users in any way.

Self-signed certs should fine (if you validate them initially) but browsers make self-signed sites almost impossible to access, relying on Let's Encrypt or being subject to extortion is a shameful state for the web.

Also, what's with the ever-shrinking renewal periods? Why can't a certificate be valid for 10 years? They can revoke it anyway if it's been compromised or whatever.

View on HN

> Also, what's with the ever-shrinking renewal periods? Why can't a certificate be valid for 10 years?

Also, why can't a certificate be valid longer than the certificate(s) above it in the verification chain?

For code signing certificates that is how it works. When checking a given link in the chain for validity the time check is whether or not the upstream certificate was valid at the time the downstream certificate was signed.

It is analogous to how notarization works with physical documents. A notarized document does not cease to be notarized just because years later the Notary Public who notarized it retires lets their notary license expire.

For HTTPS certificates the check is that each certificate in the chain is valid now. In physical document terms it is like if when a Notary Public retires it invalidates all their past notarizations.

CRLs are incredibly expensive to serve, and OCSP isn’t great either. Having short lived certificates makes it cheaper for let’s encrypt to serve the internet since the CRLs don’t need to be as large (you don’t need to maintain a list of compromised expired certificates in your CRL for example).

Has anyone explored using a technique like a Bloom filter or partial hash matching (like haveibeenpwned does) as a preliminary step for CRL lookups? You could do a cheap initial query, and if you get a negative, you're good. You only have to do the full expensive one if you get a positive, to ensure that it's a true positive. Which should be rare since most certs that are presented won't be revoked.

https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...

Honestly? I don't think it makes sense for us to continue down the path where the clients connect to the CA to verify status. While I trust most CAs (like LE), the less information a client has to expose to one the better.

> They can revoke it anyway if it's been compromised or whatever.

When have you last seen anyone revoke a Letsencrypt certificate? I haven't. Ever. I use Letsencrypt all the time and even I'd need to look up how to do it.

Software and web standards are quasi extensions of business policy as of late. It seems that the ones who require you access said sites via https+cert will gladly pivot foot and sell you said certificate when you realize you need it to unlock the full potential of the browser and thus your users eyeballs. Similar locked gardens lately can be seen in the form of Apple's app store. Not to say that secure, encrypted sites are not preferable but the lengths that unnamed parties have gone through to cripple things is not just circumstantial.

You seem to operate under the assumption that certificate revocation does anything on the web. In practice it is only useful in the presence of mandatory OCSP stapling. And mandatory it is not.

Reply on news.ycombinator.com