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

111–120 of 179 posts

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

#111

Post by ericd »

threeseed wrote: post #101
mooibos wrote: post #93

I develop for Apple platforms, and it's absolutely mind-boggling how frequently and regularly they break your code for no tangible benefit. Hopefully their influence doesn't spread to the web too.

There is a tangible benefit. For users. 64-bit only, Project Catalyst, BitCode, HTTPS only connections etc are examples of initiatives which definitely has caused pain to developers but has immensely benefited users as a whole. And if you don't passionately care about users then frankly find another platform to develop on.

64-bit only certainly doesn't benefit me as a user on the balance. There's a lot of software that's useful that has zero need for yearly updates.

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

#112

Post by moneromoney »

Apple's browser is already called "the New Internet Explorer":

https://fabiofranchino.com/blog/css-height-parent-flex-safar...

https://dev.to/nektro/safari-is-the-new-internet-explorer-1d...

https://arstechnica.com/information-technology/2015/06/op-ed...

... and millions similar articles

I developed widgets for web developers and I had to change it to stop using the 'fixed' positioning anywhere, because iOS is the only browser that interpret it differently on all touch enabled devices. They have many other issues as well. I have to spend half of my time to fix their buggy browser!!!!!!!!! Not even the old internet explorer causes that many issues as safari.

They torpedoed progressive web apps and many important web standards. Why? Just because they want you to use their apple store, where they can take 30% from every transaction without doing anything.

I hope Apple will go bankrupt and stop hurting the web community as they successfully did in the past years.

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

#113

Post by zaat »

abdullahkhalids wrote: post #20
lisper wrote: post #16

IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

Can someone chime in with the original intended purpose of the expiration date? The one that I can imagine (without research) is that the issuer knows the quality of their own security practices, and if they says that a certificate will expire by X date, they are saying that they can't guarantee that they will still be the only person with the secret key after that point. Any other explanation?

One effect of expiration dates is shorter revocation lists - if a revoked certificate was originally valid forever, the revocation list should list it since it was revoked to the end of times. Short lived certificates results in shorter CRLs.

Lengthy CRLs have performance cost, they need to be downloaded and processed by clients.

There is also a growing risk correlated to certificates validity length. If CRLs are unavailable to a client, the CRL server might be offline or unreachable or the client's access is maliciously blocked. The client have no knowledge of the reason and need to decide whether to trust the certificate without CRL check or not. If clients would be configured not to trust in such cases, the path to DOS is clear - block access to the CRL server and you effectively block traffic to all services of that CA. If clients are configured to trust certificates when CRLs are unavailable, which I beleive is the default on all OSs currently, blocking access to CRLs allows attacker to fool clients to trust revoked CRLs. With short living certificates, the opportunity window for such attacks is smaller.

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

#114

Post by WillPostForFood »

threeseed wrote: post #107
superkuh wrote: post #99

Earlier quoted context omitted.

>So I don't really understand what you're talking about, That's because you didn't finish reading my post. >Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future.

You mean like how it has been for decades ? You have always needed at minimum hosting, SSL and domain service providers.

You definitely didn’t need, and most sites didn’t use SSL a decade ago.

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

#115

Post by zaat »

lisper wrote: post #16

IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

> The Right Thing is to have the certificate contain a time stamp of when it was issued

Well of course they should, that's why it is right there, called "not before"

> The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

Well, that exaclty is the case. Most clients decided to honor the recommended expiration date, and Apple just announced they won't.

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

#116

Post by richardwhiuk »

Someone wrote: post #80
lisper wrote: post #16

IMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.

”The client should decide whether the certificate is still trustworthy” That’s what is happening now. Except for common sense, nothing stops a browser from trusting a certificate with an expiration date in the past. The expiration date more is a statement from the issuer “I wouldn’t trust this after this timestamp”. Having said that, I think Apple should say “our OSes will stop trusting certificates issued over two y…

Everyone would just issue certificates for two years longer.

This is designed to fix the fact that revocation is utterly broken.

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

#117

Post by wbl »

WillPostForFood wrote: post #114
threeseed wrote: post #107

Earlier quoted context omitted.

You mean like how it has been for decades ? You have always needed at minimum hosting, SSL and domain service providers.

You definitely didn’t need, and most sites didn’t use SSL a decade ago.

DNS you always needed.

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

#118

Post by castillar76 »

Mister_Snuggles wrote: post #44

I have my own mini-CA for internal stuff, built using the xca[0] tool with certificates and private keys distributed manually. I usually make the keys valid for two years so that I don't have to renew and redistribute very often. Most of this started as a way to learn how this stuff works, but it's now turned into a "production" thing as I've started using this to issue user certificates for VPN authentication. Is th…

Step CA (https://smallstep.com/certificates/) is a small, manageable CA designed for private PKI uses, and it now fully supports using ACME to hand out certificates to your endpoints. That means anything like certbot that can speak ACME can pull private certs from a Step-CA instance.

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

#119

Post by castillar76 »

j1elo wrote: post #53

Anybody knows why Safari on iOS will reject using self-signed certificates for WebSocket connections? (doesn't happen on desktop) This is a major annoyance since it is the only browser that does this and won't work with "wss://" URIs even after accepting the mandatory certificate exception. Accessing the page rightfully shows a warning on all browsers, to which the user can click on "Continue" or similar, to ignore t…

Apple recently (last fall) introduced a change that rejects all certificates that are valid for more than two years, whether they're public or private. I would double-check whether the self-signed certificates are valid for longer (many default self-sign processes make ten-year certs, for instance). Failing that, you may have to create a proper private PKI and get users to install the CA, or else use something like Let's Encrypt for certs.

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

#120

Post by labawi »

tialaramex wrote: post #49
Mister_Snuggles wrote: post #44

I have my own mini-CA for internal stuff, built using the xca[0] tool with certificates and private keys distributed manually. I usually make the keys valid for two years so that I don't have to renew and redistribute very often. Most of this started as a way to learn how this stuff works, but it's now turned into a "production" thing as I've started using this to issue user certificates for VPN authentication. Is th…

If you're moving Private Keys you are Doing It Wrong. This is very common in VPN setups (and S/MIME) but still a terrible idea and worth taking the time to figure out how you'll make sure you don't do this.

If you're doing it from the machine where your CA is, and using secure transport, then it shouldn't be less secure than doing the CSR/Sign/Certificate dance.

I mean, it would be nice, especially if you are distributing to other people, but I don't really see a difference if we are talking about uploading cert/keys to servers where you have root access.

Post reply on HN