Worst-case-scenario: Risk of using Let’s encrypt (or another CA).
“Worst-case scenario”- hypothetical question here:
What do you consider the risks if some external malicious third party would be able to gain access/steal to the Let’s encrypt private root certificate key (and then possibly its consecutive intermediate certificates)?
Hypothetically, assuming that this worst case scenario happens successfully, a/my Server (i.e. a Synology NAS or other Servers) receive such “malicious” signed certificates from Let’s encrypt after another 90-day renewal period:
-What would the clients “see”/what would the browser show if they connected to such “malicious” certificate running on a server?
-Would the connecting clients see some error message?
-Could a malicious third party easily run Man-in-the middle or other attacks? Which ones exactly?
-Could a malicious third party easily gain access to client’s username/Password combinations transmitted to the server running such malicious certificate?
I am just trying to summarize which implications are to be expected in such worst case scenario.
Ideas/ specific knowledge welcome!
Thanks you!
All CA's are trying their best not have those scenarios.
However, if that really happens, the first thing they would do is revoke the Root CA, and request all platform distrust it first.
Until they distrust the cert, access to sites issued under this CA would be normal.
(I'm not sure what will chrome do since they don't use OCSP to verify Cert validity.)
----- Questions -------
They would have regular access to the site as if nothing happens.
Also please note that all DV certificcate only can verify that the connection between server and the client is secure, not the site information. (aka site is safe, controled by the right person etc..)
If the root/intermediate certificate is revoked, they will see error message saying the connection is not secure. (regularly)
That depends on what they choose to do.
An example of third party mitm (not attack) is Bitdefender SSL Scan. (WHich will replace all site with either "Bitdefender Trusted CA" or "Bitdefender Not Trusted CA"
If the client connects to an "identical" site and inputs their username password, of course, the site owner can see the password.
I don't really think it will happen. However, i believe if this happens, all CA will have to do the same thing though.
Compromise of the root key (or even the intermediate CA keys) should be impossible, as they’re stored in hardware security modules, from which it’s (at least theoretically) impossible to retrieve them. That is, nobody can retrieve them (good guy or bad guy); the keys are locked into the modules, and any cryptographic operations requiring those keys are done within those modules.
That doesn’t do much to address the “what if”, but the probability of the “what if” scenario is extremely low.
One tricky thing in general is that you’re not only exposed to risk from a CA by using that particular CA, but simply by having a web site at all!
For example, when the DigiNotar attacks happened, sites that didn’t use DigiNotar were attacked using misissued certificates from DigiNotar. You didn’t have to be a DigiNotar customer at all in order to be affected by the misissuance. If Let’s Encrypt is ever compromised, attackers will be able to use its issuance capabilities to attack non-Let’s Encrypt customers as well as Let’s Encrypt customers.
A technology to mitigate this particular risk is HPKP
but unfortunately Google is planning to remove support for it (!).
Not sure I’d call removing HPKP support “unfortunate,” considering that even minor screw-ups in implementing and maintaining HPKP can result in your entire web site being knocked offline. When folks like Ryan Sleevi and Scott Helme start jumping ship, that’s when I jump, too. (And I have: I killed HPKP on my personal sites this month.)
HPKP is far too aggressive and has effectively zero safeguards or methods for undoing mistakes—the deployment guides are almost universally terrifying with how they lay out warnings. Ultimately, the security provided by HPKP came with caveats and problems that made it far, far more likely to cripple your site and knock you offline than almost any attacker. It was a good idea, but it’s just not usable in its released form.