Comment by floatingatoll | Hacker News Reader

Comment by floatingatoll | Hacker News Reader

Parent Full thread

This CCADB vote provides the context missing from this link to a Chromium patch. After the CA issuers rejected 2017 and 2019 proposals (Ballot 185, Ballot SC22) to reduce certificate issuance times to ~1 year, Apple announced enforcement of the rejected 398-days limit across all platforms on 01 Sep 2020, the CAs reversed their position while complaining that they were being forced to, and Chromium is now implementing the policy as well.

https://cabforum.org/2017/02/24/ballot-185-limiting-lifetime...

https://archive.cabforum.org/pipermail/servercert-wg/2019-Se...

https://ccadb-public.secure.force.com/mozillacommunications/...

> SUB ITEM 3.1: Limit TLS Certificates to 398-day validity Last year there was a CA/Browser Forum ballot to set a 398-day maximum validity for TLS certificates. Mozilla voted in favor, but the ballot failed due to a lack of support from CAs. Since then, Apple announced they plan to require that TLS certificates issued on or after September 1, 2020 must not have a validity period greater than 398 days, treating certificates longer than that as a Root Policy violation as well as technically enforcing that they are not accepted. We would like to take your CA’s current situation into account regarding the earliest date when your CA will be able to implement changes to limit new TLS certificates to a maximum 398-day validity period.

Nit: It's CA/B Forum (Certificate Authority / Browser Forum, a standing meeting between the major browser vendors - which are also roughly the set of major OS vendors except Mozilla stands in for the Free Unixes - and the major publicly trusted Certificate Authorities). The original purpose of this meeting was to find common ground between these two groups and this has borne considerable fruit over the years in the from of the Baseline Requirements.

CCADB is a totally different service run by Mozilla and Microsoft (using Salesforce, I presume because they both agree this is terrible but neither can accuse the other of using their preferred pet technologies?) notionally open to other trust stores to track lots of tedious paperwork for the relationship with trusted CAs. Audit documents, huge lists of what was issued by who and to do what, when it expires, blah blah blah. Like a public records office it's simultaneously fascinating and a total snooze fest. Mozilla is using it in this case to conduct their routine survey of CAs to check they understand what they're obliged to do, they're not asleep at the wheel and so on.

Sounds like CAs will be forced to keep shrinking cert length until everyone standardizes on 1 month. They no longer have any real power.

A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.

Less labour intensive for whom?

Anyone using email validation now needs to click a link every month, or their cert goes away.

I used to have the unfortunate task of managing a massive SAN cert used for white-label hosting with a bunch of our customer's domains.

Getting every single customer to get their tech person to look at the mailbox and click a link was often a multi-month process.

Less labor intensive than requiring validation and deploying a new signed certificate every month.

>and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day.

If you're in a position to MITM using a stolen certificate, you're probably also in a position to block the CRL response from going through. Since failing to get an updated CRL doesn't result in a security warning, your CRL proposal is essentially useless.

> you're probably also in a position to block the CRL response from going through

Not if the certificate is OCSP-Must-Staple.

One of the arguments that I've seen for shorter-lived certs is that revocations aren't honored particularly well. If we could fix that, then your proposal would make sense (but I'm not sure that's doable)

Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure.

Short cert lives make certain decloaking much, kuch more difficult.

It looks like 84% of sites [1] use forward security with modern browsers, which should mean historic traffic is not vulnerable to a leaked key.

It seems like driving this number up is a better way of dealing with historic traffic than quickly expiring certs. Limiting the duration of leaks of future traffic seems like the right justification for short lived certs.

[1] https://www.ssllabs.com/ssl-pulse/

However in TLS 1.2 and earlier in most cases there is also a potentially long-lived key inside the server to enable faster (1-RTT) resumption. Bad guys who obtain this key get to decrypt all TLS sessions protected with that key, even if the client never used resumption at all. This is fixed in TLS 1.3, where having that long term key only lets you see inside subsequent resumptions that don't redo the DH key exchange.

That recent GnuTLS bug resulted in bad guys not even needing to steal that resumption key for any servers using affected versions of GnuTLS because GnuTLS was just initialising it to zero...

I heard perfect forward secrecy is intended to prevent decrypting past traffic.

Good!

CAs are resting all and every changes because it's easier, it makes sense.

CA's are resisting because the only person to buy from them is someone who can't set up certbot and lets-encrypt. As soon as they cant issue for longer than a year, their market is being whittled away.

> the only person to buy from [CAs] is someone who can't set up certbot and lets-encrypt

Digicert is in the process of migrating their customers to ACME (the issuance protocol used by Let's Encrypt and certbot). Where's your god now? :)

And that's two out of how many?

Will browsers start allowing self signed certificates though?

As long as you first create a root certificate then you can create how many certificates you want.

Assuming non-chained root CAs remain trusted.

I can forsee the browsers eventually treating self-created CAs like they currently treat self-signed certs. if they're not traceable to a trusted root CA then there's no accountability, from a browser perspective, in the event of abuse or breach.

Then people will create their own root CA and use it to sign the existing root CAs. Whatever it takes. Corporate users need internal certificates.

Self-signed certificates are insecure, so, no.

Aren't they allowed already, with a click-thru warning screen? And you can also choose to trust them permanently, aka trust on first use.

No... web of trust is an important aspect to https.

s/web of trust/centralization/

s/centralization/validating ownership

Without centralization I can MITM at the coffee shop and steal passwords.

WoT would fix that, unless the other coffee shop patrons have (directly or indirectly) trusted you.

They should at least allow for local addresses

Reply on news.ycombinator.com