Live data from Hacker News

Chromium and Mozilla to enforce 1 year validity for TLS certificates

chromium.googlesource.com

201–210 of 375 posts

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#201
post #192
post #189

It’s disgusting. It’s not up to them to decide how long a certificate should be valid. Especially when they’re so expensive to buy and complicated to replace.

>Especially when they’re so expensive to buy and complicated to replace. Letsencrypt is free and easy to replace (it's automatic, and takes maybe 5 minutes to set up on a new server). EV certificates might be harder, but I've heard good things about certsimple.

Sadly CertSimple just disappeared all of a sudden. Not much real use for EV certs though - the only thing they can be a little helpful for is if you want to do cert-pinning at the CA-level

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#202

Earlier quoted context omitted.

Why as a vendor would you use a self-signed certificate that causes the browser to scream at the customer when you could just not use TLS, plain old HTTP.

Some features require Secure Context. Browsers just don't enable those features in a context that isn't secure (HTTP is only considered "secure" on the loopback network to your own machine). If it's a Javascript API it returns an error, if it's an HTML or HTTP feature it doesn't work. "Here's a nickel kid, get yourself a secure context". Both Chrome / Chromium and Firefox have explicitly set policy that new features…

I mean yes, browsers have amply demonstrated they don't care about secure local device communication at all. Mostly from ignorance and disinterest. It's their loss, just means everyone has to install an app or that smart lightbulb only talks to the vendor cloud.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#203

Earlier quoted context omitted.

This is silly to use as a blanket statement. There is nothing harmful about hosting a website. Especially personal sites, internal sites, or small businesses who use it as little more than a brochure that serves static content. My roof repair guy is not harming anyone by posting his information on a basic website.

What if I visit your roof repair guy's site and content is injected, informing me that they now take payments online? Or that I can download their special Roof Repair App to manage my bookings? Or it contains an exploit payload? It is extremely uncommon for me to actually visit an HTTP website - I even have HTTPSEverywhere block them by default, so I'd know if I were. That means that I am relatively protected to such…

If I was the bad actor I would simply purchase google ads in the name of the target business sending traffic to my own site with wonderful green padlock - it's cheaper and has bigger reach than trying to hijack TCP/IP traffic.

More to the point - if I am running a collection of Karl Marx works it is highly unlikely that he would request payments.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#204

Earlier quoted context omitted.

Can you describe the kind of person who hosts their own website but cannot easily set up Let's Encrypt automatic renewal?

The whole "Let's Encrypt should solve all your problems" attitude is arrogant and short-sighted. 1) In my experience the user experience even for technical admins is still flakey on at least some popular platforms. In other words, it's not as incredible as you think. 2) It's not available to a host that doesn't connect to the internet but does occasionally get connected to by a local browser (eg. IoT firewalled insid…

How fortunate, then, that LE isn't the only vendor. Not even the only ACME vendor, nor the only free vendor (https://zerossl.com/features/acme/).

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#205
post #19

From the source code: https://chromium.googlesource.com/chromium/src/+/ae4d6809912... // For certificates issued on-or-after the BR effective date of 1 July 2012: // 60 months. // For certificates issued on-or-after 1 April 2015: 39 months. // For certificates issued on-or-after 1 March 2018: 825 days. // For certificates issued on-or-after 1 September 2020: 398 days. The source code also requires certificates issued…

On 30 April 2018 it became a requirement (in Chrome) for all certificates issued after that date to be recorded in a public Certificate Transparency log[0]. A certificate issued on 28 February 2018 could therefore be issued without being logged, while having a validity period of 39 months. Such a certificate would be valid until 28 May 2021. Does that mean that next May, for the first time ever, the domains of all HT…

In practice it's probably already true or very close to true that names from certificates in the Web PKI that are intended to be publicly accessible are all logged. As you observe if the name listed is a wildcard this doesn't tell you which (if any) of the names implied by that wildcard actually exist, and indeed no names for which certificates were issued need necessarily exist, the rule is only that if they did exist they'd belong to the subscriber.

Although the Chrome mandate only technically kicked in on 30 April in practice most CAs were considerably ahead of that date, in addition some of the logs are open to third parties uploading old certificates, Google even operates logs that deliberately accept certain untrustworthy certificates, just because it's interesting to collect them.

If you're excited to know what names exist, the Passive DNS suppliers can give you that information for a price today, their records will tell you about names that aren't associated with any type of certificate, and lots of other potentially valuable Business Intelligence. They aren't cheap though, whereas harvesting all of CT is fairly cheap, you can spin up a few k8s workers that collect it all and store it wherever (this is one of the tasks I did in my last job).

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#206

Earlier quoted context omitted.

LE is open standard, any CA can decide to implement it.

The only other CA I know that has this service available is https://www.buypass.com/ssl/products/acme

https://zerossl.com/features/acme/

Free, even.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#207
post #179

Earlier quoted context omitted.

What are some valid reasons not to use LetsEncrypt?

If you accidentally leave DNS pointing at an old IP that gets recycled to someone else, you've authorized LetsEncrypt to issue a certificate to the lucky winner. Most old school CAs do domain validations against the root of the domain, so it's a lot harder to accidentally delegate that. That's not a reason not to use LetsEncrypt, but it's a reason not to include it in certificate pinning.

> If you accidentally leave DNS pointing at an old IP that gets recycled to someone else, you've authorized LetsEncrypt to issue a certificate to the lucky winner.

Yeah, but only for that particular subdomain. Sounds like a pretty contrived attack. For it to work, it needs to be some website that you forgot about, but still have enough users that it's viable to attack it.

>Most old school CAs do domain validations against the root of the domain, so it's a lot harder to accidentally delegate that.

Source for this? If there's even a handful of paid CAs that validate at the subdomain level this is a moot point.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#208
This is a tangent, and I apologize. Is there any good infrastructure for creating self-signed TLS CA/host certificates these days for people who don't sysadmin full time (grok OpenSSL)?

I would like to create a self-signed CA with a name-constraint for certain internal (sub)domains, and have my browser trust the CA. And have it sign end-host certificates. And have httpd use those certificates (or certificate chains) such that the end result is a trusted HTTPS connection I don't have to click-through Advanced every time.

Is there a collection of PKI software that makes this remotely easy to do? OpenSSL objectively does not.

I have a good understanding of public and secret key cryptography as well as hash functions and other primitives, but I don't understand any of how PKI works — it's just crazy complicated for what it seems to do.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#209
post #104

I don't like seeing how the SSL hurdle affects small read-only websites.

Agreed. Talk about sledgehammer to crack a nut. Typical sysadmin solution to a problem assuming every Joe Blogger is going to setup his own VPS and fsck with certbot.

If Joe Blogger can setup LAMP, he can setup ACME. If Joe can't setup LAMP, Joe will use a web host that does all of it for him including HTTPS. If Joe picked a host that's incapable of securing sites, Joe needs to switch to any of the dozens (if not hundreds) of competitors that can get this right.

Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates

#210

Earlier quoted context omitted.

Responsibilities have changed a bit. If you're going to host a website you are going to have to put a modicum of effort into ensuring that you are not harming others by doing so.

>are not harming others How is HTTP harmful when you visit my website about amateur radio? An expired cert is no more harmful than bare http in this non-commercial non-institional personal context. It's the one being discussed in this sub-thread in case you missed it and assumed the normal HN business context. The burden is real and completely unecessary for personal websites. This makes the web more commercial by im…

These days, it's harder to set up a website _without_ SSL/TLS. If you're buying a domain name, they'll likely offer free HTTPS. If you're setting up a site via Shopify / Wix / etc, it'll use HTTPS. From what I've seen, sites without a valid certificate are either ancient and no longer maintained, or are built by devs learning the ropes of web development and haven't bothered to set up certbot on their server just yet.

There was already a fetishism of commercial/institutional security, and LetsEncrypt gave it quite the blow. Now companies that you used to have to pay a yearly fee for a certificate are offering their certificates for free.

It does stink that corporations have to be in the middle in the first place, but that's due to the difficult problem of "trust." I'm not sure it's possible to decentralize it, besides some sort of blockchain solution that would be unworkable in the real world.

Post reply on HN