New trusted root certificates added to Windows in unannounced update
hexatomium.github.io
hexatomium.github.io
There is virtually nil chance that none of the root CAs are compromised or influenced, or at least influenceable by a criminal organisation or group.
I also doubt that all governmental organisations that have the opportunity to legally influence the CAs have full control of all their employees and that they are not vulnerable to criminals.
I also doubt that the governmental organisations of the usual suspected countries involved in government funded industrial espionage are not able to influence CAs - in order to target information in other countries.
Actual lawful interception is inevitably possible - but it's a good thing so it can be ignored. Actual political espionage can also be ignored, as it is unlikely to happen to normal people and companies and nearly impossible to avoid without considerate resources.
But the first three scenarios are probable, and can cause serious economical harm, and can't be fixed without changing the whole current infrastructure.
Doesn't mean we shouldn't try, since we're not getting rid of if anytime soon.
Google's Certificate Transparency is a great approach.
Once the private keys are compromised, all bets are off. No database - whether maintained by Google or anyone else - puts a dent in such a problem. It's one thing to track inauthentic certificates; it's quite another to discover someone silently decrypting traffic with a copy of the private key.
Edit: My response brings up an interesting question I hadn't considered before. With the certificate chain, is it required to have the private keys for the entire chain in order to be able to decrypt the stream? If someone has the certificate authority top-level certificate, can they decrypt a domain's certificate without having its private key as well as any intermediates? If not then it'd be true that the primary concern with a top-level private key being compromised is illegitimate certificates being signed, in which case Google's attempt to combat that with Certificate Transparency isn't half bad.
If you have the CA's private you must sign your own fake certificate and MITM the connection with the fake certificate. In this case, as you pointed out, Certificate Transparency does help because the fake certificate won't be present in the certificate logs.
No security system is invulnerable, and even the slightest inconvenience will prevent a certain percent of behavior.
In light of those two facts, you must speak about specific threats and attacks if you want to say anything about security.
For example: Compromised root CAs have not been found to be used by criminal gangs in bank phishing schemes. Therefore, they seem to provide about the right level of security for that threat.
Compromised CAs have been strongly implicated in government attacks, so they don't provide an adequate level of security in that context.
This doesn't mean they're beyond repair. They work for certain tasks in certain contexts, like your front door, or a safe, or a password, or a security guard.
I should not have said 'beyond repair'.
But the comparison to my front door is adequate. It is mostly of symbolic value. It is possible to gain entry to the house in 30 seconds.
It is at least not possible to just walk in without me noticing when I am at home.
I disagree; indeed, I think the idea that cryptography and security can be flawed-but-useful is itself naïve. If something is breakable, it will be broken; that's why we need to be using the best possible security protocols and standards.
> For example: Compromised root CAs have not been found to be used by criminal gangs in bank phishing schemes.
They've not been found, which means neither that they've never existed nor that they never will exist.
A flawed TLS implementation might only be exploitable by nation states, or only be practical against high value targets. Or perhaps it's known humans are corruptible, but a transparent, auditable root CA is still better than name-your-Chinese-state-CA.
Security is a spectrum. It is not all or nothing. Sure, crypto algorithms should strive for perfect security, but a system with humans will be fallible and must be usable.
Whether it will be broken during the duration of your use by an attacker that you can realistically thwart is the question you must be asking, and that has different answers.
So about as bad as it gets. Worse, because the user is under the impression there is at least some security on the connection which changes their behavior. - for example most users would now not enter financial details on a non https connection.
Does anyone know if there is a log stored in windows 10 of what root authorities were used by different domains?
It also has the potential to wreck your site.
But alas, we always need the concentration so badly for the sake of efficiency.
Note that this is actually unproven. It is a dogma of modern economics, not an established fact.
Yay.
It was a great time, when people could actually use more of their time on computers for doing other things besides chasing the update/upgrade treadmill.
Scary release notes and the opportunity for users to say no are bad for business.
https://krebsonsecurity.com/2016/10/microsoft-no-more-pick-a...
> Yeah, it doesn't look suspicious at all.
Honestly I don't know whether this particular CA addition is a good example of the sorts of backdoors that Microsoft is known to insert on behalf of intelligence and police organizations. I think the parent was perhaps being a bit flippant?
https://technet.microsoft.com/en-us/library/cc754841(v=ws.11...
In particular, it's a volunteer-run organization in which it's not unusual at all to volunteer to maintain a package as part of your day job that uses a package, and where a large amount of discretion is given to the individual package maintainer, until they choose to hand maintenance to someone else. This is perfect for an organization who wants to push security configuration weaknesses. Even if you can't get a back door in, you can certainly default to code that you have privately found vulnerabilities in, or compile with or without certain options, add third-party patches that are pretty questionable, or add CAs that are particularly easy to coerce. None of these actions look weird at all, they just look like someone who is putting work into their package and caring about doing Debian-specific work to make it work well. In particular, until relatively recently, the Debian ca-certificates package included the CAcert root cert, which was in very few other root stores, and the SPI one, which was in no other stores.
It's also the case that Debian accepts binary packages built on the developer's personal machine (and this used to be required until very recently), so it's very easy to straight-up upload a backdoor that isn't in the source. (This might have changed recently, but I believe this was true at least as recently as the last stable release.)
Do you know if the version of OpenSSL in your Debian has any patches to its cipher suite selection algorithm, compared to upstream? (Genuine question; I haven't checked.) If it did, and you saw someone being grumpy on a Debian bug and refusing to remove the patch, would you suspect that they were actually evil? Or just grumpy?
Remember, also, that Debian is the distro that patched their OpenSSL to ludicrously weaken the random-number generator, and the Snowden leaks confirmed that the NSA backdoored a random-number algorithm. I am not at all saying that the NSA was behind the patch (it looked genuinely like an oversight), but if the NSA wanted to be behind a similar patch, no one would think it abnormal.
You think the NSA (or FSB, or whatever) can't pay for someone to maintain nginx or apache?
Outside probably hypotheticals, what we know for certain is that microsoft is attempting to monetize their new windows on the back of user's data.
To get a job at MS, you have to have a real life reputation. Once you get in, there will be others analyzing your code, and your bug may not make it to release.
To insert a bug into Debian, become a packager and you're done. Access to one of the most popular server (the important stuff is here) OSs (Debian, Ubuntu) on the web.
You're busted? Create another account and start over.
Pretty common - many community distros do. Arch Linux too. Worrying for obvious reasons.
At least they're putting in an actual effort at making builds reproducible.
Search for Manage Computer Certificates (Win 8 and up)
This will open an app, look in Trusted Root Certification Authorities
If you should trust an authority is a tricky question. Typically you trust your OS and let them decide (which is what's going on here). See https://technet.microsoft.com/en-us/library/cc751157.aspx and https://technet.microsoft.com/en-us/library/mt171474.aspx for what their process is supposed to be
Most notably for me, the list doesn't show any of the foreign roots, Agencia Notarial de Certificación, Autoridad Certificadora Raíz Nacional de Uruguay, etc. Are they kept anywhere else?
EDIT: According to the author, Manage Computer Certificates will only show you that a trusted root exists after you've used it. Trusted roots that you've never used are invisible: http://hexatomium.github.io/2015/08/29/why-is-windows/
The test he provides still works: "OpenTrust Root CA G3" won't show up in Manage Computer Certificates until you visit https://www.opentrust.com/
So, Manage Computer Certificates is useless for untrusting roots Microsoft trusts for you.
For Windows: Have never done this myself, but the link mentions a tool called RCC that lists root certs and highlights potentially suspect ones I guess? No clue if this is legit, use at own risk: https://www.wilderssecurity.com/threads/rcc-check-your-syste...
Google anything that is not on it (and is not MSFT).
If not, the update will fail.
well half of the list aren't _new_ CAs more like additional root certs.