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

21–30 of 179 posts

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

#21

Post by detaro »

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…

CAs are free to come up with more complicated schemes for customers that think they need them, including systems that include humans in the loop if that's what is requested. It's kind of embarrassing that hasn't happened yet, but apparently "just buy long-term certificates instead of bothering to improve things" wins out unless there is external pressure.

That said, many CA verification processes are just less-standardized variants of the things LE does. If you can get LE to give you a fraudulent cert, you will also find another CA you can fool.

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

#22

Post by tmpz22 »

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?

Millions of dollars in IT consultation work. Target in 2014, 2019 (it was a 5 year certificate), Microsoft Teams 2020, etc.

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

#23

Post by duskwuff »

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…

> The fact that it's automated results in less human intervention along the way...

Let's Encrypt is far from unique in being heavily automated. If anything, its verifications are more stringent than those used by other major CAs.

> The fact that it's free means that there's no credit card number or other info that would help identify actual person that requested certificate issuance

Payment details are basically useless in terms of tracking abuse. Attackers have no lack of access to untraceable or fraudulent payment methods.

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

#24

Post by marcosdumay »

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?

Well, it's the one that works in practice. The issuer is the one that known when he will renew the certificate. If every client decided for himself, half of the internet would be broken at each time.

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

#26

Post by FireBeyond »

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?

1. As an analogue for password expiration (with all the commentary that entails).

2. Recurring revenue models for CAs.

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

#27

Post by hannob »

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.

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

#28

Post by iso1210 »

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…

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?

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

#29

Post by wool_gather »

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?

> the issuer [...] are saying that they can't guarantee that they will still be the only person with the secret key after that point.

It's not quite clear what you mean here.

The issuer should never have the private key for the end-entity cert (the one representing the domain or whatever). Only the owner should have the private key.

EDIT: Hmm, according to another comment here, some CAs will offer to generate both halves of the keypair for the end user. Yikes.

If you are talking about the CA's own private key...if that ever leaks, then no certificates signed by it should ever be trusted again; expiration date has no relevance here.

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

#30

Post by nicolas_t »

iso1210 wrote: post #28
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…

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.
Post reply on HN