381–390 of 955 posts
Earlier quoted context omitted.
I had the same thought, but I still find that absurd. Say they host 500,000 websites with HTTPS. 1,000,000 renewals they save spread across the year, roughly 2 renewals a minute. That is pennies. A t2.medium could handle that type of load increase
A bit OT, but what's up with this usage of Amazon EC2 tiers as a unit of computational power?
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.
Depends on setup, but frequently private keys are inaccessible to the web server worker process. (Which starts as root, loads keys, drops privs, etc.)
To re-enable all disabled non-system addons you can do the following. I am not responsible if this fucks up your install: Open the browser console by hitting ctrl-shift-j Copy and paste the following code, hit enter. Until mozilla fixes the problem you will need to redo this once every 24 hours: // Re-enable *all* extensions async function set_addons_as_signed() { Components.utils.import("resource://gre/modules/addon…
Super useful, thanks. In my case ctrl+shift+j opens a dumb console that only shows messages and doesn't take any input. I had to go to about:addons, hit F12 for the Dev Tools and paste it in the console there. Worked well.
Earlier quoted context omitted.
Having a root process with write-privileges to /etc on production machines and also able to communicate over the Internet definitely is a security risk. To mitigate that you end-up building a series of privilege-restricted jobs flowing from the DMZ back into the internal network. And maintaining that might be more complicated than just manually renewing, depending upon the processes and architecture of the company.
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.
Earlier quoted context omitted.
Depends on setup, but frequently private keys are inaccessible to the web server worker process. (Which starts as root, loads keys, drops privs, etc.)
Most popular ACME (Let's Encrypt) clients allow you to provide a CSR instead of generating the keys themselves. That means a bunch more work for you, but if you're worried about this, that's what you should do. Have your safe (even manual if you insist) process make keys, make CSRs for the keys, and put those somewhere readable. The ACME client will hand them over to the CA saying "I want certs corresponding to these…
Earlier quoted context omitted.
Oof. Would you happen to know if it's the same with the developer edition as well?
The developer edition has its own user profile.
Earlier quoted context omitted.
>nothing ever bad happens. With ads: either it takes me half a second to tell I'm not interested in an ad, or I actually am interested and i follow the ad because I am interested and I want to support the website. You just described something bad.
What's bad about supporting a site you like while learning about something that interests you? If this were really all ads were I wouldn't block them.
Earlier quoted context omitted.
> Still, this type of oversight seems all too common even in large companies. (...) Has anyone developed a tool designed specifically to avoid certificate expiry disasters? LetsEncrypt renewal is supposed to be automated. [1] I know of a company that hosted blogs for thousands of customers. They used LetsEncrypt, but the CTO considered automatic renewals a possible security risk, so they did it manually. Problem is,…
Some shared hosting like Bluehost now provide LetsEncrypt by default for all their sites with auto-renewal (But I don't recommend Bluehost shared plans for anything even closer to serious hobby due to absurd downtimes like most other shared hosting). I used manual renewal for LetsEncrypt for about 4 websites on other shared hosts & renewing them every 3 months was a pain; had to keep reminders and schedules just not…
Another use case for the app I am developing! The basic idea: You can enter an item (i.e. "MyOwnShop Cert") into the list. From that time on, it will be tracked how much time passed since the item was entered or renewed (by clicking the renew button). The item with the longest time since entering/renewing is at the top of the list.
Compared to schedules and reminders it has the advantage that the item is not out of our mind once the reminder or schedule pasts. It just sits there dutifully and its timer keeps increasing.
I use it for keeping up with middle-term contacts ("Wow, I have not written Carl for 3 weeks?") and health-related issues. Logging in stuff that easily spoils would be another use case. And, apparently, cert renewals :)
Earlier quoted context omitted.
>SSL cert renewal is one of the great unsolved problems in computer science Certificate expiry really only exists to make money for CAs. It doesn’t solve any security problem that CRLs don’t already solve (and solve better). There’s lots of unsolved problems relating to ‘how do you make a reliable PKI’, but cert expiry is really just an unrelated business requirement for CAs.
CRLs are not equivalent at all. They are a last-ditch effort to fix a problem when all else (expiry) has failed. CRLs require maintenance and distribution of a list by a 3rd party. Creating an accurate, all-inclusive CRL of all website keys that your browser should reject is far, far from easy. (Case in point: "how many web sites are there?" Is not an easy question. ) Properly propagating such a list to any browser t…
But, this sharing carries a cost for user privacy, if I shard certs 16 ways then each CRL download gives me 4 bits of info about which sites you were visiting.
OCSP effectively takes this to the extreme, each lookup is tiny because it's just for one cert, but it gives away exactly which cert you cared about each time.
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).