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

All extensions disabled due to expiration of intermediate signing cert

bugzilla.mozilla.org

Post reply on HN
Print view View original

411–420 of 955 posts

Re: All extensions disabled due to expiration of intermediate signing cert

#411

Post by ww520 »

former_mozzer wrote: post #367
ww520 wrote: post #223

Not sure what kind business processes are practiced in Mozilla. Some organizations have the notation of recurring tasks as part of their business processes. Recurring tasks are just like bug reports except they are created and assigned automatically to task owners on a schedule, such as every month, every quarter, and every year. The goal of recurring task is to get people's attention to review and perform tasks the…

Who at Mozilla is responsible for cert renewal? Is it Mozilla IT or is it the Firefox org? That question has never been answered, and those who asked were often reprimanded. And this is far from the first certificate renewal problem.

Reprimanded for raising the question? That's quite dysfunctional. Sounds like that's an ownership problem.

Re: All extensions disabled due to expiration of intermediate signing cert

#412

Post by nothrabannosir »

needle0 wrote: post #12

I’ll still keep using Firefox since I recognize the importance of browser diversity and the hazards of a Chrome monoculture (that and vertical tabs), but, yikes. Still, this type of oversight seems all too common even in large companies. I remember several cases from Fortune 500 companies in the past few years alone. What would be a good way to automate checking for them? Has anyone developed a tool designed specific…

Realistically: reduce your own cert renewal window to weekly, if not daily. This forces you to have a good renewal system in place and alerts you to failures long before actual expiration.

Quixotically: make cert failure a randomised number, linearly related to how long ago the cert expired. This slowly introduces more and more failures, over a certain “grace period”, which makes the problem less of an extinction level event. It’s not a solution but it definitely would help.

Re: All extensions disabled due to expiration of intermediate signing cert

#413

Post by Whitestrake »

rocqua wrote: post #384
Whitestrake wrote: post #317

Earlier quoted context omitted.

Why would a process need to run as root or have write privileges to /etc in order to automate LetsEncrypt renewals? I run Caddy (which uses acme-go/lego as its ACME provider) as a non-root user with no access to /etc at all. It seems to be running fine.

Using http renewal requires listening on port 80 which, by default, requires root.

This is technically true, but contextually lacking.

acme-go/lego doesn't use HTTP validation unless you disable just about every other form of validation first. TLS-ALPN validation is much more likely, so port 443.

That said, it is very easy to allow software to bind to privileged ports without providing it root access; this has been solved for a very, very long time.

Re: All extensions disabled due to expiration of intermediate signing cert

#415

Post by hum6ug »

weavejester wrote: post #48

There's a workaround that involves going to about:config and setting xpinstall.signatures.required to false. However, if you're running the Stable or Beta version, it will only work under Linux. On Windows and MacOS you'll need to download Nightly or the Developer Edition. To fix this on MacOS I did the following: 1. Downloaded and installed Firefox Nightly 2. Ran /Applications/Firefox\ Nightly.app/Contents/MacOS/fir…

This does not work with Firefox 66.0.3 in Arch Linux ...

Re: All extensions disabled due to expiration of intermediate signing cert

#416

Post by [deleted] »

rocqua wrote: post #384
Whitestrake wrote: post #317

Earlier quoted context omitted.

Why would a process need to run as root or have write privileges to /etc in order to automate LetsEncrypt renewals? I run Caddy (which uses acme-go/lego as its ACME provider) as a non-root user with no access to /etc at all. It seems to be running fine.

Using http renewal requires listening on port 80 which, by default, requires root.

[deleted]

Re: All extensions disabled due to expiration of intermediate signing cert

#417

Post by tialaramex »

lvh wrote: post #199
human20190310 wrote: post #140

Earlier quoted context omitted.

I agree. What can be done to prevent developers from adding a certificate dependency without monitoring during the move-fast-and-break-things days of early development, which then sits for X years as developers come and go, and nobody notices until it fails?

Certificate Transparency works pretty darn well for most usecases, we (Latacora) have found while trying to solve exactly this problem (or at least the figure out which certs exist that aren't being regularly re-issued part) :-)

Caveats:

Certificates that aren't from the Web PKI almost invariably won't be logged. Most logs explicitly refuse everything except certs from the Web PKI so as not to be burdened storing garbage. So this won't find certs issued by the custom OpenSSL CA on that one guys Linux laptop.

Not all Web PKI certs are logged. There is no BR obligation and no root store programme rule that requires logging. The only things in place that strongly encourage logging are the Chrome and Safari policies. For systems that aren't designed to be accessed with a web browser or, much more rarely, enterprises that have persuaded themselves only IE is authorised anyway, the certs might deliberately not be logged. Yes there are (small) CAs doing this in the Web PKI, on purpose, in 2019.

Re: All extensions disabled due to expiration of intermediate signing cert

#419

Post by egwor »

swalladge wrote: post #399
Grue3 wrote: post #390

What kind of idiot thought that the add-ons I have personally installed on my browser need to have a capability to be remotely disabled despite literally nothing being changed. This is absolutely inexcusable. I want to see everyone being responsible for this "verified add-ons" fiasco fired from the team (after they roll it back of course).

Exactly. If me/firefox has verified the signature (or approved the download) when downloading or updating the addon, that should be all that's necessary. Why does firefox have to check signatures constantly?

in case it was revoked? Seems fairly reasonable approach

Re: All extensions disabled due to expiration of intermediate signing cert

#420

Post by dschuetz »

lucb1e wrote: post #409

If everyone's add-ons are disabled, I wonder why mine are not. My computer has been running over night (coincidentally, first time in years) and my add-ons are intact. Does it take a browser restart? Or might I have a setting that prevents this from happening? My system time is correct. Edit: am on Firefox 66, Linux (Debian Buster/testing), using Firefox from Mozilla directly (not through repositories), and my intern…

Are you on nightly build?
Post reply on HN