This is uninteresting. CAs are well aware that they have to encode the subject DN and issuer DN identically to maximize interoperability. There are several implementations that require that.
If we were to make a new version of the spec for X.509 certificates, I would hope that we would eliminate all the non-UTF8 encodings so that this would be a non-issue.
To be clear, the differential here occurs because OpenSSL does the wrong thing. Go is correct to fail closed here, and it’s very hard to imagine a setting in which Go failing closed is a relevant security differential.
Just to be clear, OpenSSL isn't doing the wrong thing, based on the description in the blog post. The specification allows and even requires behavior similar to that.
They’re two different fields on different certificates. The issuer on the child needs to match the subject on the parent; every certificate has its own subject and issuer.
> We have been assessing our existing processes (for OpenWrt, and especially the OpenWrt One) against NIST IR 8425A, and are now accelerating those efforts to ensure we can show that routers using OpenWrt are indeed safe and secure, as determined by independent bodies.
It would be awesome to have somebody show that OpenWrt-based routers are safe and secure. I looked into this problem about 10 years ago and my concluding was that stock OpenWrt was really questionable. Like, there is no auto-update story, but at the same time it is a giant (relative to what it should be, IMO) Linux distro full of vulnerability-laden components. This space is in dire need of a minimal security-first-from-the-ground-up alternative with a real trustworthy update story.
> Like, there is no auto-update story, but at the same time it is a giant (relative to what it should be, IMO) Linux distro full of vulnerability-laden components. This space is in dire need of a minimal security-from-the-ground-up alternative with a real trustworthy update story.
I admit I'm not super deeply familiar, but I would have guessed the opposite - that openwrt had no extra software included, not least because it's targeting devices where total disk and RAM are measured in megabytes. What components would you remove/replace that make it "giant"?
The only thing that can reasonably be called "giant" about OpenWRT is the package repository: it has a decent package manager like you'd expect to find on a desktop Linux distro, and it can be used to add functionality to your router, including a fair bit if stuff that goes well beyond what is typically used on routers. But the default install set is not giant, and is typical of what you'd expect for a wireless router.
OpenWRT updates are very much discouraged on an ongoing basis primarily because most devices running it use very cheap flash chips which are small and fail quickly after too many writes. They’re nowhere near the level of SSDs, or even SD cards, that can handle many flash cycles.
Almost as important is the fact that updates do not overwrite the original packages, because those are in a read-only partition. Updates are written to an overlay file system, so every updated package uses twice as much flash space. Installing updates weekly would quickly fill the flash.
But as far as vulnerabilities go, what’s the actual exposure? From the outside there’s no ports open, and on the inside only a few for device management, and basic services like dhcp, etc. Those have been around for decades and are pretty well hardened by now.
My impression was that autoupdate was not the default because the devices it runs on only have so many resources, and there's a non-trivial chance of bricking the device (given how many devices are supported)? It's not like other vendors are doing any better in this space (and I've seen enough things in the "IoT/embedded" space brick themselves with updates to be a bit wary of autoupdates).
Auto-update is also a bad idea unless you can make it really secure, which is hard to do on devices so constrained they don't even have a clock to keep track of what day it is to judge whether a certificate is still valid.
Minimizing the chance of bricking the device with an automatic update requires at a minimum having two copies of the OS, so that the running copy isn't trying to modify itself and can remain as a fallback in case of a broken update. That's not too challenging these days now that most routers are using NAND flash, but for a long time it was common to use very small NOR flash modules with the absolute minimum capacity.
Updates don’t currently have a way to ensure that user installed packages have their configurations updated appropriately, so user installed packages may break on update. Additionally, as a sibling comment pointed out, official images don’t include user packages, so you’d either need a scalable way to build custom images or the updater would need to be smart enough to reinstall packages after update.
It would still be nice to have an official automatic update feature that is opt-in for stock systems.
You also need to rebuild the firmware with the installed packages. Otherwise you end up without your packages installed. That requires a server to build the firmware for your device. Doing this automatically for everyone is resource intensive.
They have the tools and infrastructure for assembling custom firmware images on-demand, and have recently added it to the default images, so they must feel like their infrastructure is ready for significantly increased demand.
I use attended sys upgrade. I've been using OpenWrt for the last 7 years, but I've noticed that attended sys upgrade often fails at release time. And there are often point releases shortly after. I'm just skeptical that their infrastructure would handle mass auto updates at release time. I usually wait a few weeks after release until the masses have reported various device specific bugs before I upgrade.
Pretty much all the routers that are targeted by the ban would be OpenWrt derivatives, AFAICT. It’s basically the Android of routers, except without the Google resources.
Google Wifi Is one of the main lines that aren’t based on OpenWrt.
Just in case anyone else was wondering, it seems that some early products (running AirOS) were modified versions of OpenWRT, but later software/hardware is not.
So yes, this comment is correct, but it threw me since I wasn’t following the company back then and I hadn’t heard of that history before.
[I was at Mozilla during the development of BrowserID but I didn’t work directly on it. I was a huge fan of the effort.]
Besides non-obvious UI issues, there were fundamental issues. One in particular that was very hard to overcome:
Very few people would choose to hide which websites they are logging into from the identity provider. People don’t care whether their IDP can see when/where they are authenticating. That’s assuming they could even understand the issue at all. They have to trust the IDP a lot either way, and this one detail is small, counterintuitive, and even oxymoronic to most people—Trust the IDP 99%, but jump through hoops to avoid trusting them 100%? Why?
There is value in the identity provider knowing when, and from which device, and from which location, and on which websites you are using the identity. Hiding any of this from the IDP hurts security. It is really hard to overcome this in a useable way. A lot of purported solutions implicitly assume users have device and key management abilities that even experts in this area rarely consistently practice.
So, then, are you really better off, i.e. receiving a net positive benefit?
That’s real, yeah. I also remember a couple concerns around that privacy as well. One being that if your IdP controls your email, they could probably figure out what sites your communicating with anyways. And perhaps a timing issue with when relying parties fetch the public key to verify assertions?
For bespoke projects, a lot of the privacy concerns go away once I’m using my own authentication in the first place (I control the full stack). So then the value would come more from federation (which is hard to bootstrap) or developer experience. I do still think BrowserID has something going for it there, potentially.
I do wonder if I’ll miss the centralized session management, though. I’m building this IdP to be modular, so I could try a different protocol on top of the user management core down the road.
The biggest one I’ve come across is the ability to manage and revoke sessions from a centralized location. With BrowserID, you can’t just sign out of your IdP and expect all relying parties’ sessions to invalidate. Instead, BrowserID asserts that you controlled the email at a point in time, and then it’s up to the site to decide how to manage the session afterwards.
3rd party cookie blocking makes this worse, since it’s difficult to silently refresh your session by checking with the IdP behind the scenes. I believe Auth0 uses a hidden iframe for this, which uses 3rd party cookies and looks a lot like a tracking pixel. Without that refresh mechanism, though, relying parties are pushed to have longer lived sessions, which makes the lack of a global revocation worse.
Ah, yes, but that's a problem all IdPs have, no? You have to check in with the IdP every so often. I don't think this is insurmountable, Persona could have just added a mechanism to do that.
Many implementations limit the RSA key size to 8,192 or 16,384 bits (because the maximum bit length determines indirectly how much stack space is required).
Actions have special integration with GitHub (e.g. they can annotate the pull request review UI) using an API. If you forgo that integration, then you can absolutely use GitHub Actions like "a container you run scripts in." This is the advice that is usually given in every thread about GitHub Actions.
If you want to make a CI performant, you'll need to use some of its features like caches, parallel workers, etc. And GHA usability really fall short there.
The only reason I put up with it is that it's free for open source projects and integrated in GitHub, so it took over Travis-ci a few years ago.
Devil's advocate: They could make the github CLI capable of doing all of those things (if it's not already), and then the only thing the container needs is a token.
> For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
At https://rwc.iacr.org/2025/program.php you can see there is a talk scheduled to be given in a couple weeks titled "Testing Side-channel Security of Cryptographic Implementations against Future Microarchitectures" with the following bits in the abstract: "Using this framework, we conduct an empirical study of 18 proposed microarchitectural optimizations on 25 implementations of eight cryptographic primitives in five popular libraries. We find that every implementation would contain secret-dependent leaks, sometimes sufficient to recover a victim’s secret key, if these optimizations were realized. Ironically, some leaks are possible only because of coding idioms used to prevent leaks under the standard constant-time model."
Again, this is just a temporary situation, and a matter of burning down a list of small tasks. Not that the OpenSSL license issue is a big deal for most anyway. Feel free to help; see this issue filed by Josh Triplett: https://github.com/briansmith/ring/issues/1318#issuecomment-...
Yeah, I realize, and I am looking forward to having multiple options to choose from that all have the same license compatibility. It's nice that there's a short-term solution that's available for people who need to ship things soon, and it's nice that there's a longstanding library (ring) that'll long-term will be capable of providing a compatible solution as well.
If we were to make a new version of the spec for X.509 certificates, I would hope that we would eliminate all the non-UTF8 encodings so that this would be a non-issue.
reply