https://www.trustico.com/ssltools/create/csr-pem/create-a-ne...
Apparently they decided to keep a copy of the private key.
Edit: Looks like they are having problems atm. A copy can be found at
https://web.archive.org/web/20180217071027/https://www.trust...
Perhaps they’re passing this command to a secured container? I shouldn’t make excuses for them, but passing root commands to the shell seems too far out there.
You haven't been in software too long, have ya? /s
Glibness aside (and I meant the above as a joke, not a personal attack), this is distressingly common to the point of being near-universal in some areas of our industry.
That would indicate they were concerned about shell injection while writing the code. But if that were true, why would they skip the much simpler step of sanitizing/escaping the input?
This would still raise my eyebrows, since root inside a container is still something you should avoid unless absolutely necessary (especially if they aren't using user namespaces). Just because containers add some newer security features to regular processes doesn't mean you should forget the security features (POSIX DAC) that were there in the first place.
It's called the Pwnie Awards.
StartSSL used it, for example, but also allowed you to hand them a CSR of your own making. Although they of course ignored almost everything in the CSR apart from the public key (which is probably a good idea).
(1) IIRC you could even have a smartcard generate the key, at least in theory.
So you could put some other public key in there, add a bogus signature that wouldn't verify and they'd issue certificates for a key you never even controlled.
The bad security implications for that scenario are a bit subtle, and situational, but CAs are supposed to be checking that the CSR is properly signed, that's only a long way down the list because StartCom/ WoSign had so many other serious problems.
Alice has public key A, and Bob has public key B, and everybody trusts Charlie the Certificate Agency to issue certificates, Alice has one binding (Alice,A) and Bob has one binding (Bob,B).
Alice controls a missile she will only accept Major Tom's commands. Bob runs firework displays, he accepts the display organizer's commands.
I want to fire Alice's missile. I impersonate Bob, and I trick Charlie into issuing a certificate (Bob,A) because she doesn't verify that I know the Private Key for A. Then I offer (as Bob) to run a really great firework show for Tom, and I give him the (Bob,A) certificate so he can command firework launching.
When Tom sends me a launch message encrypted to A, I simply deliver it to Alice, who launches the missile as I desired.
Alice was never compromised, neither was Tom. Charlie's only mistake was not verifying that I controlled the Private Key for the cert she issued me. Bob was compromised, but he was just running a firework business, he didn't know this was a matter of national security.
For some reason, I never thought of DV certificates that way. I always took (Bob, A) to mean "I checked with the real Bob and he says it's fine to use key A in his name".
The former is, of course, the more useful guarantee.
[1] I don't want to take away from your good post, it's a good and well explained scenario to illustrate the issue. Personally I found Dominic Tarr's paper on AKEs-as-capabilities quite illuminating when I read it, and the analysis applies to your scenario as well. (The scenario is also a neat demonstration of a bunch of other issues, too)
But in TLS 1.2 and earlier it's murkier to me because there are cases with and without DH, and what gets signed, by who, and when varies. I think you're right, but I started doodling the possible cases out and I filled two A4 pages before I gave up. Certainly even if you're right as to how the protocol is designed it will not astonish me if somebody implements it wrong and doesn't check a signature somewhere given the many cases.
The problem is, people who don't understand the issue will prefer a solution that doesn't require installing some software.
Any of them can capture the generated key.