31–40 of 71 posts
Even if this is just RCE in the script somehow (I doubt it, it can probably do anything the user running it can), it's horrifying. It means the certificate authority could just take your newly generated certificates and upload them anywhere they want. That's a catastrophic compromise in the TLS security model.
Earlier quoted context omitted.
> So the person claiming to be the founder of "QuantumCA" does not possess the private key corresponding to https://crt.sh/?caid=200960 - can we be sure the private key is only accessible by ssl.com's CA system? So the certificates listed here aren't issued by this person, but by the ssl.com's system? https://crt.sh/?Identity=%25&iCAID=200960&exclude=expired&de ... Correct. You can see the Quantum intermediates liste…
I find it troubling that a root CA (ssl.com) is apparently OK with lending their name in a business relationship with an actor that is actively exploiting an acme.sh 0day.
Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me " (until it does). Seemin…
Even if this is just RCE in the script somehow (I doubt it, it can probably do anything the user running it can), it's horrifying. It means the certificate authority could just take your newly generated certificates and upload them anywhere they want. That's a catastrophic compromise in the TLS security model.
Why is distributing the certificate dangerous? It’s public knowledge anyway.
Is this part of Plan 9?
Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me " (until it does). Seemin…
Unfortunately requiring approval and authentication from a random incorporated entity running a CA every 90 days is inherently complex. And all the ACME protocol implementations do is hide that inherent complexity by adding even more. CA TLS HTTP is very fragile but it could be made less so if corporate browsers didn't demand short lifetime certs-- a demand reasonable for businesses but not for human people or things expected to last longer than a few years without being touched.
Everybody makes mistakes people. If this person was trying to be malicious they would have disappeared, not come straight clean about it on the thread.
Earlier quoted context omitted.
I find it troubling that a root CA (ssl.com) is apparently OK with lending their name in a business relationship with an actor that is actively exploiting an acme.sh 0day.
This feels a little bit like doubling down to find ways to implicate the actual CA instead of the reseller. It's clear how mismanagement by a real CA would make a more interesting story than by this random no-longer-existing pseudo-reseller, but I don't think there's evidence to support that story yet.
So QuantumCA == HiCA == exploiters of the acme.sh 0day, it's all the same entity? The intermediate CA could just as well be named "0dayexploitersCA"? Why is it not a huge concern that ssl.com is fine with operating such a "0dayexploitersCA" intermediate?
Am I missing something here?
Sounds about par for the course for folks that think shell is a productively sustainable way of writing secure or reliable software. Not even remotely sorry about that opinion. The gall to claim ACME compat, then force require a single client, all so you can remote execute arbitrary commands. Should be enough to ruin the CA, but we know how people handle things like this "oh, won't affect me " (until it does). Seemin…
Shell is a bad fit for many uses (an ACME client is more ambitious than I would build in shell, personally), but the things it's good at, it's really good at. I have yet to find anything else that's even close to as good for glue code when I have a handful of tools and/or a bunch of files that I need to string together. Unless you're writing in Ada, I promise whatever language you think is better has its own sharp ed…
Earlier quoted context omitted.
Shell is a bad fit for many uses (an ACME client is more ambitious than I would build in shell, personally), but the things it's good at, it's really good at. I have yet to find anything else that's even close to as good for glue code when I have a handful of tools and/or a bunch of files that I need to string together. Unless you're writing in Ada, I promise whatever language you think is better has its own sharp ed…
I usually replace shell scripts with python (using sh module: https://amoffat.github.io/sh/ for calling other scripts/programs).