jaas

Let's Encrypt | Director of Site Reliability Engineering | United States or Canada | REMOTE

Let’s Encrypt is a free, automated, and open Certificate Authority.

You will lead a relatively experienced six-person team responsible for maintaining and evolving the operational infrastructure for the Let’s Encrypt certificate authority. This includes the physical infrastructure, software deployments, monitoring and alerting, and related policies and procedures that provide secure and reliable service to more than 130 million websites around the world. We expect this number to grow rapidly.

This is one of the most critical technical positions at Let’s Encrypt, and as such it’s a unique opportunity to have an enormous impact on creating a more secure and privacy-respecting Web.

For more information, including how to apply, please visit:

https://letsencrypt.org/jobs/

This comment doesn't add anything that isn't explained in the article more than once by Acton himself.

I disagree, though that was certainly a big factor, particularly in speeding up the pace of user loss.

In any case, it's probably not a healthy perspective for Mozilla or its community to just write this off as Firefox being the victim of a big ad campaign for another browser. Mozilla had real problems and missed opportunities, and that's where their focus rightfully should have been.

"Perhaps Mozilla's biggest blunder was its decision to add support for the closed-source DRM W3C standard Encrypted Media Extensions (EME) in Firefox."

It's hard to imagine a perspective from which this is true that isn't very narrowly constrained to anti-DRM activism.

If anything, implementing DRM was a significant positive for Firefox market share, unpleasant as the decision was. The article says:

"Despite Mozilla's kowtowing to the video streaming industries, Firefox users have continued to switch to other browsers anyway"

Yes - and Mozilla would have lost even more users, faster, if they didn't integrate DRM capabilities. The fact that Mozilla continued to lose users after DRM is not evidence that DRM was bad for market share. DRM stemmed the bleeding a bit.

I understand why people don't like DRM, and I'm sympathetic, but almost nobody actually wants to use a browser without DRM because they'd be cut off from doing what they want to do (e.g. watch Netflix, YouTube). Before Mozilla added DRM directly, it supported Flash, which almost everyone had installed, and that was DRM plus a myriad of stability and security nightmares. Firefox didn't "add" DRM so much as they retained it while throwing the rest of Flash out the window. Firefox is clearly better off now.

Mozilla's biggest mistake is simply that after Firefox 3, Firefox was significantly surpassed in quality for many years by at least Chrome, maybe also Safari. Luckily Mozilla has closed the quality gap and is shipping a great browser today, but that painful period is probably going to continue to haunt them for a long time. They lost a lot of users because they weren't shipping a browser that met modern quality standards. That was probably their single biggest mistake, and that's why their market share is what it is today.

The Firefox bookmarking implementation is unnecessarily complicated and I'm guessing very few features are actually used. It's a maintenance burden, I'm not surprised they want to slim it down.

To give you an example of a maintenance burden in the bookmarking system, the bookmarking system uses a bunch of synchronous APIs. Mozilla is trying to cut down or eliminate use of those APIs, to reduce UI hangs among other reasons, and in order to do that a bunch of bookmarking code needs to be rewritten.

You may have decided that you don't care about this particular kind of bloat, but all unnecessary maintenance burdens distract developers from doing work I'm sure you do care about.

Here is the bug for removing descriptions:

https://bugzilla.mozilla.org/show_bug.cgi?id=1402890

Here is a sub-bug that discusses issues with synchronous APIs.

https://bugzilla.mozilla.org/show_bug.cgi?id=1467996

You can limit that by deploying CAA records for your domain in DNS. All trusted CAs are required to respect those records.

We provide multiple options, including PayPal. The primary option here uses Stripe via DonorBox:

https://letsencrypt.org/donate/

Word is Nvidia overproduced and is sitting on a lot of current gen stock.

Miners bought AMD because AMD cards are usually better at mining for the money. They started buying more Nvidia when AMD didn't make enough cards.

In any case though, the success of Ryzen is the interesting thing, not the mining sales.

I think the answer is that low-interest car loans often come from a finance arm of the auto maker. I once got a 0% loan from Volkswagen to buy a Volkswagen. Seems like a way for them to sell more cars to people with good credit who will almost certainly pay back the loan.

I don't have any particular insight into this industry beyond my own personal experience though, so there's a non-trivial chance that I'm wrong with regards to the general case.

The strategy is/was to do both. We started getting our root into browsers immediately and we sought out a cross-sign to let us operate while the ~7-10 year root inclusion and propagation process happens.

IdenTrust was initially part of a bank consortium, but by the time we (Let's Encrypt) started talking to them they were just an independent company. Now IdenTrust is a division of HID Global via acquisition.

We switched the Let's Encrypt website from Jekyll to Hugo. We did it primarily for i18n support (Jekyll does not support translation), but it would have been worth it just to avoid Jekyll's ruby dependency nightmare. Hugo is a single static binary, so simple.

I think this is the best answer to your question:

https://www.youtube.com/watch?v=QO15S3WC9pg

So if someone deployed SSLv3 when it was the secure version and left that running for decades, you would describe this as proper and an ideal scenario that we should strive for?

I sure hope that's not a lesson we learn in any decade.

I am not a lawyer or particularly well informed on the subject, but I believe the SCOTUS case you're referencing only applies to public sector unions (i.e. government employees).

It's not useful, it's grossly misleading. People think it means the site is safe when that is not the case.

The problem with the lock is that people think it means a site is safe (i.e. contents are safe). That's not what it means and you're never going to educate enough people about what it really means, nor should you have to.

It's grossly misleading and it needs to go.

If you enable it you will find that the results are very blurry. It's unusable, to me.

I'd say there is a 98% chance this is a bug in some firmware and a 2% chance AT&T is intentionally trying to block Cloudflare DNS.

I get why people are paranoid about ISPs blocking content and net neutrality, but let's not cry wolf prematurely. The technical details here strongly suggest a bug rather than intentional blocking of 1.1.1.1 DNS traffic.

Let's Encrypt does not currently validate from multiple perspectives but we're working on it. We're cooperating with a research team at Princeton to make sure our strategy is an effective mitigation against BGP attacks.

Any given production validation right now may come from one of two of our datacenter locations, but not both.

You may see multiple validation requests if you use our staging servers, but that's just an early version of multi perspective validation which doesn't work well enough to promote to production. There are some performance issues, and the external validation points are all on AWS, which uses the same autonomous system (AS) across datacenters. In order to effectively defend against BGP attacks we're probably going to have to deploy validation servers on 3+ different ASes so that our network perspectives are sufficiently diverse.

If multi perspective validation is effective and nothing is done to significantly improve BGP security (we're not holding our breath) then I expect multi perspective validation to be a requirement for all CAs down the line.

Wildcards are only available via ACMEv2. The post linked to here says that.

It didn't take us years to implement. We didn't internally decide to support wildcards until around May 2017 - it wasn't a foregone conclusion that we would ever support them. We didn't start technical work on wildcards until late 2017.

Specifying and implementing ACMEv2 took a while, that was a lot of work. Adding wildcard support on top of that wasn't trivial but it wasn't nearly as much work.

The reason we haven't announced an EOL for ACMEv1 is that we won't announce one until we are confident we won't cause the kind of meltdown you describe.

I worked down the hall from the XFS team at SGI in 2005. Development had definitely not ceased, and their work did not seem heavily related to Octane systems. They were focused on XFS for Suse and RedHat Linux for enterprise and supercomputing.

"it's a race to the bottom for CAs to perform the absolute minimum work necessary"

I can assure you that we, Let's Encrypt, are not doing the minimum. We are headed in quite the opposite direction. It's not easy to keep things simple while improving security but it can be done.

I hope it's not overly pedantic to point out that what you linked to is not a CAB forum thread. That's a thread on the Mozilla security policy list, which many root programs and CAs make use of for disclosure and discussion.

CAB forum has its own lists elsewhere. A relevant difference is that CAB forum discusses creating and modifying policy but is not involved in enforcement. The root programs typically deal with enforcement.

According to the article the cache was found in 1992.

We've now posted more details about the issue and our plans.

https://community.letsencrypt.org/t/2018-01-09-issue-with-tl...

Haven't put much thought into -02 since nobody actually runs it in production but I suspect the same issue applies.

Josh from Let's Encrypt here. I'm not able to give many more details yet, but here's what I can add now:

1) This isn't a relatively simple issue like a bug in our CA code would be. It's an interaction between the protocol and provider services.

2) Disabling TLS-SNI is a complete mitigation for us, meaning it's no longer possible to get an illegitimate certificate from Let's Encrypt by exploiting this issue.

3) We have not yet reached a conclusion as to whether or not the TLS-SNI challenge will need to remain disabled permanently.

4) At this point we have no reason to believe that the vulnerability has been exploited by anyone other than the researcher who figured it out and reported it to us.

Our focus now is on sharing information with relevant parties and looking for less drastic mitigations that might allow us to restore the TLS-SNI challenge option to people who rely on it.

We will, of course, share more information as soon as we can. That might be as soon as the next few hours, things are moving quickly.