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

31–40 of 179 posts

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

#31

Post by wool_gather »

hannob wrote: post #27
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.

That is... a very absurd idea. You really don't want a situation where webpages may work or not work based on some completely unclear criteria.

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.

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

#32

Post by brirec »

mamon wrote: post #4
reaperhulk wrote: post #3

Earlier quoted context omitted.

The goal is to promote automation and continue lowering certificate lifetimes as operations get better. This ultimately will allow for lifetimes short enough to be useful. As for the other browsers, Google originally proposed SC22 ( https://cabforum.org/pipermail/servercert-wg/2019-August/000... ) last year and all the browsers voted for it. CAs voted it down at the time but there were rumblings via various back chan…

How will that automation verify that certificate is issued to the legal owner of the web site and not a hacker? Are the challenges used by Let's Encrypt secure? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless. EDIT: to clarify - there are two bad things about Let's Encrypt: 1. It's automated 2. It's free The fact th…

In regards to your edits, let me also mention that Let’s Encrypt does not offer (and indeed can not offer) “Extended Validation” certificates, due to things related to the two “bad things” you mention. However, extended validation certificates don’t in fact prevent fraud the way they are intended to — indeed, a security researcher managed to get ahold of a certificate for Stripe, Inc. simply by legally registering a corporation under that entity name elsewhere and purchasing a certificate for that legal company.[1] This issue with EV certificates — the fact that they are issued to a company as opposed to just a domain name — cause them to potentially pose a greater risk to web users.

[1] https://arstechnica.com/information-technology/2017/12/nope-...

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

#33

Post by njsubedi »

nicolas_t wrote: post #30
iso1210 wrote: post #28

Earlier quoted context omitted.

Without certificate transparency how do you know nobody has issued a certificate for your server? Surely that's a far higher risk than knowing a domain?

oh, I completely agree that certificate transparency is beneficial for that and we have an alert setup. But, that still leaves me not wanting to leak every single subdomain we use internally. Hence using wildcard certificates.

Wouldn't it be a better idea to use alternate domains instead of subdomains? You could use something like [any subdomain].atdie8e73bhdbdie93ruhe.[any tld] for obfuscation?

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

#34

Post by tambre »

wool_gather wrote: post #31
hannob wrote: post #27

Earlier quoted context omitted.

That is... a very absurd idea. You really don't want a situation where webpages may work or not work based on some completely unclear criteria.

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

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

#37

Post by simias »

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?

Without an expiration date the only way to retire a certificate would be to explicitly revoke it. That'd be a bit heavy handed IMO.

Forcing certificates to expire means that domain ownership gets re-validated every time. Nobody would risk buying 2nd-hand domains for anything sensitive if the previous owners could have a permanently valid certificate stashed somewhere. Or you'd have to contact all the CAs that could've issued a certificate for that domain and ask them to revoke it if they did.

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

#38

Post by X-Istence »

nicolas_t wrote: post #15

While I agree that it is better from a security perspective not to issue long lived certificate and that automation would be best, I dislike the fact that the subdomain of any certificate I issue becomes public due to Google's certificate transparency project. By making every subdomain public, it makes the job easier for any attacker wanting to try and find smaller servers to target. It's not that I believe in securi…

You could automate the generation of the wildcard certificate and push it out with chef to all your servers. Instead of replacing it once a year, you replace it every 90 days.

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

#39

Post by superkuh »

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 gets it's way. Especially with the W3C marginalized and a mix of corporations and corporate-centric standards groups running things now. 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.

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

#40

Post by JoshTriplett »

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?

If a certificate never expires, revocation lists have to grow without bound forever.

If a certificate expires, revocation lists only have to hold revoked certificates that haven't expired.

Post reply on HN