Earlier quoted context omitted.
If you sell certs, you're a company in a security-related context. I don't care who you are, I care if you do your job. Saying that, that quote sounds way too long to not be BS.
The quote sounds like SEO.
CEO SEO?
How not to run a CA
171–180 of 255 posts
Re: How not to run a CA
#172Earlier quoted context omitted.
If the server was rooted, couldn't an attacker silently intercept and swap out a csr with their own during domain validation, and thus get certificates approved based on fraudulent csr where the corresponding private keys are controlled by the attacker? Maybe even throw in a few "oops, please retry validation" to hide the fact that a different public key was signed in the certificate and the real customer would be no…
No. The CSR is tied to the key and the resulting certificate as well. Verifying that the CSR belongs to the key would be he CAs job, not the servers. If the server was rooted, an attacker could probably just use it to create an arbitrary new certificate - but revoking the legitimate cert won’t fix that.
1. User validates domain and submits csr
2. Rootkit swaps out csr with one of its own whose private key is under its control and submits upstream to the CA
3. CA signs a cert because the domain was validated
4. Rootkit receives valid cert for its own private key
5. Rootkit presents a bogus error to enduser
6. Enduser tries again and rootkit lets it through
End-result: there are now two certs and private keys for the domain, one of which is compromised?
Just a though experiment. I'm not familiar with the domain validation flow this reseller site was using.
Re: How not to run a CA
#173Earlier quoted context omitted.
The remaining 27k certificates are probably the ones which were generated on and which never left the customer's premises. The only thing which could be siphoned in these cases is the CSR, which is harmless (it contains essentially the same info as the certificate, which is public).
If the server was rooted, couldn't an attacker silently intercept and swap out a csr with their own during domain validation, and thus get certificates approved based on fraudulent csr where the corresponding private keys are controlled by the attacker? Maybe even throw in a few "oops, please retry validation" to hide the fact that a different public key was signed in the certificate and the real customer would be no…
Wouldn't that attack mean that the cert the domain owner got wouldn't work on their webserver, since they didn't have the correct private key for it?
Re: How not to run a CA
#174In related news, Trustico's site is down apparently due to users being able to run commands as root on their webserver. I wonder if this was used to extract some private keys? https://twitter.com/svblxyz/status/969220402768736258 https://twitter.com/Manawyrm/status/969230542578348033
I am aware this is not contributing to the thread but... the only way I can summarize my feelings on that is 'holy fuck'. I just spent a minute just muttering 'holy fuck' to myself. They are running the good old php shell of " ". As root. As a security company. This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?
I choose to believe that this is performance art. The world is a better place that way.
Re: How not to run a CA
#175Earlier quoted context omitted.
If the server was rooted, couldn't an attacker silently intercept and swap out a csr with their own during domain validation, and thus get certificates approved based on fraudulent csr where the corresponding private keys are controlled by the attacker? Maybe even throw in a few "oops, please retry validation" to hide the fact that a different public key was signed in the certificate and the real customer would be no…
Wouldn't that attack mean that the cert the domain owner got wouldn't work on their webserver, since they didn't have the correct private key for it?
Yes, but you could fool the user with an error message so the user tries again and let it through unmodified? (Hide the fact that a cert was actually issued already)
Re: How not to run a CA
#176Earlier quoted context omitted.
I am aware this is not contributing to the thread but... the only way I can summarize my feelings on that is 'holy fuck'. I just spent a minute just muttering 'holy fuck' to myself. They are running the good old php shell of " ". As root. As a security company. This entire company is just blowing my mind at the moment. What's next, are they running their services on a notebook in the office?
On the plus side, a notebook doesn't have connection to the internet...
In some languages (German for one) the common word for laptop is translated to notebook in English.
Re: How not to run a CA
#177I think we should use ssh instead of SSL and also ssh instead of username/password pairs. If somebody is doing a distributed chat/social system, I would use ssh if I were them. By ssh I don't mean execution commands but rather encryption/authentication framework.
ssh is, by default, Trust on First Use which is a significantly different model than a Trusted Thirdparty (CAs). There are some well known trade-offs, namely that having everyone manually verify fingerprints on initial connect and again on any server change is a large burden. I don't particularly want to have to go into my bank's local office and verify in person the fingerprint is correct each time they need to rota…
They could just put the relevant information on all their communications, your credit card, statements and so on, also accounting for future rotations.
For banks, it could work quite well. Most other people and organizations aren't that lucky, though.
Re: How not to run a CA
#178Earlier quoted context omitted.
No. The CSR is tied to the key and the resulting certificate as well. Verifying that the CSR belongs to the key would be he CAs job, not the servers. If the server was rooted, an attacker could probably just use it to create an arbitrary new certificate - but revoking the legitimate cert won’t fix that.
1. User validates domain and submits csr 2. Rootkit swaps out csr with one of its own whose private key is under its control and submits upstream to the CA 3. CA signs a cert because the domain was validated 4. Rootkit receives valid cert for its own private key 5. Rootkit presents a bogus error to enduser 6. Enduser tries again and rootkit lets it through End-result: there are now two certs and private keys for the…
Like I said: If you compromise the Trustico servers which are a reseller, you could trick the CA into believing that a CSR is valid for a domain. This would get you a certificate with a key under your control. But revoking the certificate with the key under the owners control won’t fix this. The illegitimate certificate would still be under the attackers control and remain valid.
Re: How not to run a CA
#179Earlier quoted context omitted.
I think it works much better for contacts. You have to verify contact once and then you are assured that it's still the same person.
> You have to verify contact once Only if users never replace their keys, which puts them at significant risk in the event of a key compromise.
Replace your key by signing a message announcing your new key?
Re: How not to run a CA
#180Earlier quoted context omitted.
I don't understand why they'd need the Private Keys for revocation. Isn't one of the reasons to revoke because you've lost the private key?
You don't need the private keys for revocation, and you're right that compromise of the private key is one of the best reasons to revoke a cert. I can't figure out why the Trustico CEO emailed the private keys to DigiCert. It doesn't make sense.
The Trustico CEO intentionally compromised the private keys to force DigiCert to revoke the certificates. DigiCert wouldn't do this otherwise on his request; it's the actual owner of the certificate who needs to request revocation.