This is technically true, and nobody contested the CABF's focus on HTTPS TLS.
However, eventually, the CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates. Nominally, the CAs are still offering "TLS certificates", but due to the pressure from the CABF, the allowed certificates are getting more and more limited, with the removal of SRVname a few years ago, and the removal of clientAuth that this thread is about.
I can understand the CABF position of "just make your own PKI" to a degree, but in practice that would require a LetsEncrypt level of effort for something that is already perfectly provided by LetsEncrypt, if it wouldn't be for the CABF lobbying.
> CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates.
The restriction is on signing non web certificates with the same root/intermediate as is part of the WebPKI.
There's no rule (that I'm aware of?) that says the CAs can't have different signing roots for whatever use-case that are then trusted by people who need that use case.
Let's Encrypt also provides value by providing signed TLS certificates that are enrolled in all major operating systems, and that can be used to authenticate any TLS server.
This is a significant and important use case that's totally ignored by the "WebPKI" proponents, and there is no alternative infrastructure that would provide that value if WebPKI would e.g. decide to add certificate constraints limiting issued certificates to TCP/433.
The public TLS PKI was never supposed to serve every use case and you know it. But let me point out when it was possible to get a public CA certificate for an XMPP server with SRVname and xmppAddr:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1096750 (0x10bc2e)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
Validity
Not Before: May 27 16:16:59 2015 GMT
Not After : May 28 12:34:54 2016 GMT
Subject: C = DE, CN = chat.yax.im, emailAddress = hostmaster@yax.im
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:chat.yax.im, DNS:yax.im, xmppAddr:chat.yax.im, dnsSRV:chat.yax.im, xmppAddr:yax.im, dnsSRV:yax.im
Ironically, this was the last server certificate I obtained pre-LetsEncrypt.
A federated ecosystem of servers that need to verify each other based on their domain name as the identity is the prime use-case for a public CA to issue domain-verified client certificates. XMPP happens to be this ecosystem.
Rolling out a private PKI for XMPP, with a dedicated Root CA, would be a significant effort, essentially redoing all the hard work of LetsEncrypt, but without the major funding, thus ending up with an insecure solution.
We make use of the public CAs, that have been issuing TLS certificates based on domain validation, for quite a few years now, before the public TLS CAs have been subverted to become public HTTPS-only CAs by Google and the CA/Browser Forum.
That's exactly what prosody is doing, but it's a weird solution. Essentially, they're just ignoring the missing EKU flag and pretend it would be there, violating the spec.
It seems weird to first remove the flag and then tell everyone to update their servers to ignore the removal. Then why remove it in the first place?
I think you're confusing different actors here. The change was made by the CA/B Forum, the recommendation is just how it is if you want to use a certificate not for the purposes intended.
But it does mean that the CA/B requirement change has zero positive effect on security of anything and only causes pointless work and breakage.
Or to put it another way, the pragmatic response of the XMPP community shows that the effect of the change is not to remove the clientAuth capability from any certs but to effectively add it to all serverAuth certs no matter what the certificate says.
Yes, this is what is happening. It isn't happening fast enough, so some implementations (especially servers that don't upgrade often enough, or running long-term-support OS flavors) will still be affected. This is the impact that the original article is warning about.
My point was that this is yet another change that makes TLS operations harder for non-Web use cases, with the "benefit" to the WebPKI being the removal of a hypothetical complexity, motivated by examples that indeed should have used a private PKI in the first place.
It is really great how they write "TLS use cases" and in fact mean HTTPS use cases.
CA/Browser Forum has disallowed the issuance of server certificates that make use of the SRVName [0] subjectAltName type, which obviously was a server use case, and I guess the only reason why we still are allowed to use the Web PKI for SMTP is that both operate on the server hostname and it's not technically possible to limit the protocol.
It would be perfectly fine to let CAs issue certificates for non-Web use-cases with a different set of requirements, without the hassle of maintaining and distributing multiple Roots, but CA/BF deliberately chose not to.
The interop was a nice feature implemented by their engineers, but it violated the lock-in operational principles of the gatekeeper services, so it had to be abandoned. Let's see if the EU Digital Markets Act will bring back XMPP interfaces to the big ones... ;)
The other half of the problem is what to gain from a root shell. You can't influence the stages of the image processing without a PhD in Sony DSP Reverse Engineering, and so what remains is probably hooking into the camera controls and injecting key events to re-invent time-lapse timers or bulb exposures, and removing the 30min video recording limit.
This is where the NX mod project arrived - additional hooks into the camera controls and a few changes to internal registers left over by Samsung engineers for debugging, like silent shutter or the 30min limit.
Sony's full frame machines are so customizable out of the box already, so you don't need anything to begin with, at least for normal photography needs. Maybe focus stacking, but it's a pure new procedure.
30 minute recording limit is already lifted and advanced time-lapse is introduced alongside mammal eye tracking with a firmware update by Sony, and you can customize anything sans preliminary image processing steps, and by customization I mean the parameters of the algorithms or algorithms themselves.
Moreover, Sony's full-frame systems are already distributed systems to begin with. There are at least two DSPs running asynchronously during focus and image capture, so there may be no pathways to influence the DSPs significantly after they boot up, even.
Personally I wouldn't muck with a system designed to do image processing 30FPS even before taking a photo (A7-III) incl. face and eye tracking and focus correction without any hiccups to this day.
From what I understood, these cameras perform a nigh impossible dance within the limits of their hardware to maximize speed and reduce energy consumption. Who am I to disrespect them for doing that. Instead, I prefer to use the thing and get nice photos out of it.
When reverse-engineering some of the Samsung NX camera firmware files, I found USB-PTP code that implements different custom remote commands <https://chaos.social/@ge0rg/114723076401717110> but I'm not deep enough into PTP to make sense of them.
Is there anywhere a group focusing on understanding and re-implementing custom PTP protocols?
The last two generations of Samsung NX cameras were built around Tizen Linux, and it was (and still is) easy to get a root shell on them. They still make great photos and you still can buy them used for a good price.
NX300/NX30/NX2000 had a read-only rootfs, but for NX500 and NX1 there was a persistent mod that extended camera functionality with a menu, and you can actually SSH into them and rsync your photos... while shooting!
Great to see another Samsung NX hacker in the wild! I'm in the process of developing a mod for my NX300 and NX30 (with the NX2000 likely compatible). It doesn't do anything yet, but I've got a lot of work done on hooking ARM code [0] and compiling modern C++ for the cameras.
Personally I think the NX300/30/2000 are the most hackable cameras ever made, even compared to the NX1/500. The read-only rootfs isn't really a barrier, since the software runs a shell script from the SD card on boot (or rather resume from hibernation, it's a pretty clever system). And unlike the newer models, they don't have an RTOS coprocessor, so everything is handled in the easier-to-modify Linux code. It's not a design decision I would have made, but it makes in-depths mods easier.
The older cameras are also easy to unbrick, since the bootloader files used for firmware flashing without a working OS were released in the FLOSS code dump. The availability of some C headers in that dump is the cherry on top.
I'll admit I'd still rather have an NX500, I just bought the NX300 because I'm cheap :)
Regarding the RTOS, I took my NX300 from the shelf some weeks ago to make a few shots for the live demo at https://programm.froscon.org/froscon2025/talk/fc37ae17-9264-... and OH MY FSCKING GOD IT'S SLOW! I made a burst shot of a model train approaching, and the camera was busy processing it for multiple minutes. The NX500 is lightning fast in comparison, and the NX1 is even snappier.
So what do you plan to do with the ARM hook? I've poked at different places of di-camera-binary, but never at the processing pipeline, and there are soooo many things to reverse-engineer, and I'm but one person!
The possibilities are endless, so I need to make sure not to get lost in them and actually get something done :) I have a shortlist of changes to make, from surface-level to harder things:
- Allow configuring the controls. For example, the multi-purpose "focus" ring is great, but is severely hampered by having to press the "iFn" button every time.
- Add bulk upload of photos to Immich (though that could just as easily be an external script).
- Write custom widgets for the LV view, like a RAW histogram or time display. Also hide the bottom buttons that have already burned into my screen.
- Allow full electronic shutter (I already had to change this camera's shutter once).
- Add highlight metering, or rewrite the autoexposure entirely.
- Support outputting raw video.
- Tone down the denoising on out-of-camera JPEGs.
- Play with custom sensor crops, line skipping and other things to get zoomed in videos.
I had the NX1 with all the premium lenses and some photos still seem to be better than what my Sony A7-M4 shoots. But no 10bit 4:2:2 for video and no real flat profile was a bummer. I loved the persistent mod though. Sold all NX1 gear years ago, moved to a Sony A7-M3 and then A7-M4. Full Frame has some great benefits.
Looks like it was invented by two Fujitsu engineers, is free of patents and maybe was optimized for hardware implementation? I've linked some Japanese sources in the post, but I don't speak Japanese and the auto translation is not easy to read.
However, eventually, the CABF started imposing restrictions on the public CA operators regarding the issuance of non-HTTPS certificates. Nominally, the CAs are still offering "TLS certificates", but due to the pressure from the CABF, the allowed certificates are getting more and more limited, with the removal of SRVname a few years ago, and the removal of clientAuth that this thread is about.
I can understand the CABF position of "just make your own PKI" to a degree, but in practice that would require a LetsEncrypt level of effort for something that is already perfectly provided by LetsEncrypt, if it wouldn't be for the CABF lobbying.
reply