Live data from Hacker News

Safari will no longer trust certs valid for more than 13 months

theregister.co.uk

171–179 of 179 posts

Re: Safari will no longer trust certs valid for more than 13 months

#171
post #160

Earlier quoted context omitted.

You can use HTTP instead of HTTPS or you can use a self-signed cert.

Yeah, right - and risk the wrath of your clients when they ask you why their shiny new website can't be accessed because it doesn't implement HTTPS. Face it, folks, the golden age of the internet is long past. Now we have to jump through a bewildering array of "security" hoops just to host a ing web page.

I was replying to someone who was complaining about what to do on "my LAN," no mention was made of clients. HTTPS isn't "security" with sarcasm quotes, it's actual security, it really does what it's supposed to do.

Re: Safari will no longer trust certs valid for more than 13 months

#172
post #162
post #154

Apple is the reason I just switched a handful of certificates from Let’s Encrypt to basic 2 year DV. To support Apple Pay on the web, you have to go to your developer account on the Apple website, and under certificates generate a custom ASN.1 authentication file and upload it to the `/.well-known/` folder on your domain. Once uploaded, you have to click a “Verify” link, to check the file and mark the domain as Apple…

There is some argument for this kind of certificate pinning (though I'm honestly not sold on the idea), but I think that this example is a further argument for scriptable certificate renewal. Most ACME clients allow you to run scripts after the certificate is renewed, so you could (in principle) trigger a script that does this Apple-specific verification process for you (maybe you could even trigger the "verify" butt…

I think this is an argument that while a certain group of server administrators and security professionals love ACME, it still has a number of kinks to work out.

In my case I’m not really setting myself up to forget about the renewal process as I have a script to generate the key and CSR and an ansible playbook to update the cert once sent to me. Certificate vendors are more than happy to email you to remind you of an upcoming renewal, in just the same way Let’s Encrypt does.

On a side note, trying to script out the proper setup/migration of Let’s Encrypt is WAY more involved and fraught with mistakes than a simple certificate upload. The failure case is that the initial certificate issuance succeeds but since the initial setup needs to happen before SSL is configured and working with Nginx, you can’t use the same config before and after the initial setup. Thus you need to have two separate Nginx configs and switch them, or you have to use standalone for the initial issuance and webroot for renewals. Both of these are far easier to mess up than uploading a certificate.

I’ve set up more than 10 different servers with Let’s Encrypt and I don’t think a single one has just worked. I think in every case something got messed up along the way, and you only find out about it 70 days later with the renewal email, IF you are the admin email on the LE account.

Don’t get me wrong, I think there are great things about Let’s Encrypt, but it has plenty of thorns to deal with. I’m glad we haven’t all been forced into three month renewals by the CAB forum (since the certificate vendors have a say and they got feedback from customers before agreeing). I am fairly annoyed that Apple decided to unilaterally change the rules when they were already part of an organization that deals with this topic. I can only imagine browser vendors moving forward will have little to no concern for site/server administrators and how their changes are affecting things.

As it stands now, we are at 400 day certificate lifetime, which means a bad actor can only impersonate for a year, in the name of revocation being performance prohibitive. This is effectively the same as three years from a users perspective. The only meaningful change would be a lifetime of something like a week or a day, but I shudder to think of all the ways that will fail spectacularly.

Re: Safari will no longer trust certs valid for more than 13 months

#173
post #34

Earlier quoted context omitted.

It's basically what has been announced here, though, no? There's no technical impediment to a CA continuing to hand out 2+ year certs. The only reason they would not do so is that webpages will start breaking if they're accessed from Safari.

The criteria are very clear: - Safari - max 398 days

To the owner of the cert, I suppose. But how many browser users are even aware of the existence of certificates, let alone CAs and expiration dates?

Re: Safari will no longer trust certs valid for more than 13 months

#174
post #170
post #164

Earlier quoted context omitted.

Often, this doesn't even work for small projects: - HTTP have no access to a significant part of web APIs added in the last years - and they will be blocked from all APIs that are being added in the future. - Self-signed certs show security warnings that are deliberately confusion and discouraging to click through and will likely become even more so in the future. Show those to other people is no option.

In my opinion this doesn't fall under the "it's only on my LAN and a super small project" category. If you LAN is a company then you should be able to deploy a custom CA to your clients and sign your certs. If it's only your small side project you personally work on, then just trusting the cert locally works out too. If people don't want to use third party providers, they have to do some of the work on their own. Tha…

A small, personal project does not mean that the developer is the only person that uses it. Servers can also be used by friends, family, roommates, etc for which installing and managing custom CAs is a hassle.

I do agree that using Self-signed certs and clicking through security warnings is possible - however, is being made deliberately tedious (e.g. Chrome will forget that you accepted the cert after a while). It also seems to me that this part is actively discouraged by browser vendors, so I'm honestly not sure how long it will stay open.

Self-signed certificates are also unpredictable to do API requests to because no accept UI is shown for such requests.

> That's nothing new (at least to me).

It absolutely is. With HTTP, you could simply run a local web server and have everything interested point their browser towards it - and everything worked. This is not possible anymore unless you want to make recurring payments for a domain and accept that you need an internet connection.

Re: Safari will no longer trust certs valid for more than 13 months

#175

There are two mutually exclusive views of the web. As a set of protocols to allow individual humans to share information about things they love and the web as a set of protocols to make a living. There are real reasons for the for-profit web to want to limited cert lifetimes since revocation doesn't really work in practice. In terms of browser dev the two views are mutually exclusive and the one that funds the coders…

With Let's Encrypt it's cheaper than ever to host a personal website over HTTPS with a certificate that updates itself. Due to Let's Encrypt, free hosting services like Netlify or GitHub Pages are now providing HTTPS certificates and installing it on your own server is pretty painless, if you're into managing your own server. And if your hosting provider doesn't support Let's Encrypt, you can always put Cloudflare in…

NO! Two big reasons, among many others: 1) These are unnecessary third-party entanglements, allowing anyone to be slienced within a year simply by refusing to renew their certificates. 2) It's the 21st century, very soon, most servers will not have administrators - smart IoT devices, if we want them to use SSL/TLS, need certificates. If you think updating these certs on regular servers is a PITA, try it on a an embedded device that has very limited or intermittent Internet access, if it's even connected to the public internet at all!

Re: Safari will no longer trust certs valid for more than 13 months

#176
post #174
post #170

Earlier quoted context omitted.

In my opinion this doesn't fall under the "it's only on my LAN and a super small project" category. If you LAN is a company then you should be able to deploy a custom CA to your clients and sign your certs. If it's only your small side project you personally work on, then just trusting the cert locally works out too. If people don't want to use third party providers, they have to do some of the work on their own. Tha…

A small, personal project does not mean that the developer is the only person that uses it. Servers can also be used by friends, family, roommates, etc for which installing and managing custom CAs is a hassle. I do agree that using Self-signed certs and clicking through security warnings is possible - however, is being made deliberately tedious (e.g. Chrome will forget that you accepted the cert after a while). It al…

And this is exactly why SSL everywhere is a really, really, bad idea. (Plus the problems of IoT server certs, mentioned above...)

Re: Safari will no longer trust certs valid for more than 13 months

#177
post #98

Earlier quoted context omitted.

I'll agree that modern mainstream browsers (and devices!) have an increasingly centralized security model that isn't at all conducive to an open web. But given the current state of the FOSS ecosystem, I'm not terribly concerned in the long term so long as the network layer remains open to all. (Consider: QtWebEngine, PinePhone, SiFive, OpenTitan, IPFS, DAT, Solid, ...)

I think the web is already a lost battle. It'll just take time (a lot of it) for the control to fully sink in. But I think that once this control becomes mainstream then there will be something else with more freedom. Some form of an alternate internet that will have barriers to entry. Something like tor. It'll probably be based on p2p.

Gab's rework of Mastodon is starting to look like this.

Re: Safari will no longer trust certs valid for more than 13 months

#179
post #176
post #174

Earlier quoted context omitted.

A small, personal project does not mean that the developer is the only person that uses it. Servers can also be used by friends, family, roommates, etc for which installing and managing custom CAs is a hassle. I do agree that using Self-signed certs and clicking through security warnings is possible - however, is being made deliberately tedious (e.g. Chrome will forget that you accepted the cert after a while). It al…

And this is exactly why SSL everywhere is a really, really, bad idea. (Plus the problems of IoT server certs, mentioned above...)

I understand the rationale behind https-everywhere and I believe it's absolutely necessary for the web at large. The problem of network attackers is certainly real.

However, a side-effect (intentional or not) is that the web is turned into a sort of app store: Either you belong to the platform or you don't, and whether or not you do is decided by third parties. (Who, btw, are not even bound by any kind of public mandate - they are simply private, profit-driven companies)

I also don't think the stated security advantages always make sense: Let's Encrypt will serve network attackers just as easily as legitimate customers. Meanwhile it will lead to a lot of stuff being exposed on the internet than would be necessary otherwise. We also force devices that simply should expose a local web interface to have a cloud service. I don't see how this makes anything more secure.

I guess what I'd want is simply a way to designate a device as "trusted" locally, without depending on third-party services, internet connectivity or anything else and without anything expiring. A way that should be encouraged to be used by non-techical users as well.

Post reply on HN