Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

theregister.co.uk

Post reply on HN
Print view View original

161–170 of 179 posts

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

#161

Post by cutler »

Reelin wrote: post #98
jhoechtl wrote: post #79

Earlier quoted context omitted.

I am telling you there is a conspiracy going on to end the open and free web. We should fiercefully start to fight back otherwise those who made the internet great (the open source hackers working on LAMP) will loose everything.

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, ...)

How is the network layer open when legit SMTP servers with proper SPF records are blacklisted by Google and Microsoft with no accountability. The internet is owned by these organisations. It's a fait accompli. It's only a matter of time before sites not hosted on cloud platforms become blacklisted due to the pitfalls of self-hosted certification. Jeeezus.

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

#162

Post by cyphar »

wbond wrote: 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" button click by messing around with cURL -- though it'd be pretty annoying for there to be no API for this process).

By manually getting 2-year certificates you're setting yourself up to forget part of the renewal process. This was the main argument behind Let's Encrypt having such short expiration windows -- it encourages people to script their entire deployments.

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

#163

Post by Reelin »

cutler wrote: post #161
Reelin wrote: 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, ...)

How is the network layer open when legit SMTP servers with proper SPF records are blacklisted by Google and Microsoft with no accountability. The internet is owned by these organisations. It's a fait accompli. It's only a matter of time before sites not hosted on cloud platforms become blacklisted due to the pitfalls of self-hosted certification. Jeeezus.

Refusal of large email providers to properly federate is certainly frustrating, but I was actually referring to the network layer in the OSI model. So long as the raw IP traffic isn't subject to broad and pervasive restrictions by the authorities, new software stacks can be freely invented and used on a worldwide basis (IPFS, for example).

(Speaking of other software stacks, a few Gopher servers remain online today [1] and there's even a DECnet in operation! [2])

[1] http://gopher.floodgap.com/gopher/gw?gopher/0/v2/vstat

[2] http://www.update.uu.se/~bqt/hecnet.html

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

#164

Post by xg15 »

extra88 wrote: post #137
xg15 wrote: post #131

Earlier quoted context omitted.

> Let's Encrypt [...] Netlify [...] GitHub Pages [...] your hosting provider [...] Cloudflare Those are exactly the kind of third-party services the GP was talking about. > if you're into managing your own server One of the core advantages of having a personal server has always been that you can keep it entirely off the internet and run it without any involvement of third-party services. That is not anymore possible.…

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

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.

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

#165

Post by gsich »

diebeforei485 wrote: post #133
gsich wrote: post #109

Earlier quoted context omitted.

>64-bit only how has that benefitted the user? Directly and measureably, no "it's 0.3% faster now" excuses.

Not having to load both 32-bit and 64-bit libraries into memory is an efficiency (and battery life) improvement on the system as a whole.

That would fall into the "it's 0.3% faster now" category.

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

#166

Post by tialaramex »

Reelin wrote: post #150
tialaramex wrote: post #147

Earlier quoted context omitted.

"Standard" is a big ask. If this is a concern then you can proceed as follows: 1. Wait 24 hours or so after securing control over the names. 2. Use the Certificate Transparency logs to determine which certificates if any exist for names you now control and want revoked. 3. Discover the revocation process for the issuer of each cert. 4. Use each process you discovered. All of them should be willing to revoke if you ca…

Thanks for another clear explanation of process! But... the fact that there isn't some standardized automated revocation procedure that all CAs are required to support at this point seems somewhat absurd to me. At a minimum, it seems like such processes based on both proof of domain ownership and proof of private key possession should exist. Moreover, there ought to be a way to specify via DNS which CAs can issue cer…

Getting the CAs to all agree on some particular process is like herding cats. In practice the situation where you'd want this is relatively uncommon, so it's as though you demanded US States all come up with a single unified set of traffic regulations - most Americans do not routinely drive in more than one or two states and so they'd support their home state in insisting that whatever happens it should be spared the expense of changing. It would go nowhere.

You can use CAA to tell CAs whether they're authorised to issue for names in your domain, and since CAA is a DNS resource you can secure it with DNSSEC. But CAA isn't retrospective, it won't magically revoke certificates which already exist, although it could prevent issuance based on stale authorisations because it's supposed to be checked live.

Using DANE here would be pretty fraught even if it was widely deployed which is far from the truth.

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

#167

Post by maxgashkov »

cyphar wrote: post #162
wbond wrote: 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…

> maybe you could even trigger the "verify" button click by messing around with cURL

Good luck with that—some time ago Apple locked down pretty much everything related to developer accounts with 2FA requirement that, of course, works on their proprietary platform via sending codes to logged in Apple devices. Maybe you can snatch it via some Automator kung-fu but I seriously doubt that.

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

#168

Post by OJFord »

ryandrake wrote: post #128
wbl wrote: post #117

Earlier quoted context omitted.

DNS you always needed.

Not strictly necessary, but convenient. All browsers I know of allow you to browse to an IP address.

Well, I tried to respond to GP with a tongue in cheek link of an IP address to lmgtfy or Wikipedia on DNS or something, but every site I tried checked the Host header, (I assume) so it didn't work.

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

#169

Post by luckylion »

labawi wrote: post #123
luckylion wrote: post #54

Earlier quoted context omitted.

> The criteria are very clear: today . Tomorrow they may change to be 397 days, or 39.8 days, or "until the next iPhone is released".

Nope. Today, tomorrow and for 6 more months is 825 days. As of September 1, 2020, it will be 398 days - a change people knew was coming for a long time.

The point is that they can change it any time ("tomorrow"), not that they will literally change it tomorrow. How much time they will give you to prepare doesn't really matter, it's still unilaterally forcing everyone to adapt.

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

#170

Post by Lyrex »

xg15 wrote: post #164
extra88 wrote: post #137

Earlier quoted context omitted.

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

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. That's nothing new (at least to me).
Post reply on HN