Reducing the Roots of Some Evil
codeascraft.com
Reducing the Roots of Some Evil
1–9 of 9 posts
Re: Reducing the Roots of Some Evil
#2This is a great post, in which the lead security person at Etsy built a system to determine which HTTPS/TLS CA's actually got used in traffic from their office to the Internet. Less than 29% of the CAs their browser trusted actually saw any use!
This sounds like something to be outraged about but is actually constructive good news: if more people repeat the experiment, someone could invest some engineering time into building a tool that would prune out CAs from browser trust stores. Every CA removed from your browser is one less attack vector.
Re: Reducing the Roots of Some Evil
#3This seems ok if you have a tech-savvy user base that understands how to re-add a root certificate if they later hit a legitimate site using one of the removed root certs. If you user base isn't that savvy, I'm afraid you would just be training them to ignore SSL errors, which is not great.
Also, I assume the OS and browser vendors do some sort of verification before adding a CA to their list of root certs. Is the message that we shouldn't trust their verification efforts? If so, we should probably use something other than popularity to do our own independent verification.
Re: Reducing the Roots of Some Evil
#4This is a great post, in which the lead security person at Etsy built a system to determine which HTTPS/TLS CA's actually got used in traffic from their office to the Internet. Less than 29% of the CAs their browser trusted actually saw any use! This sounds like something to be outraged about but is actually constructive good news: if more people repeat the experiment, someone could invest some engineering time into…
Sounds like a job for the SSL Observatory? https://www.eff.org/observatory
Re: Reducing the Roots of Some Evil
#5This seems ok if you have a tech-savvy user base that understands how to re-add a root certificate if they later hit a legitimate site using one of the removed root certs. If you user base isn't that savvy, I'm afraid you would just be training them to ignore SSL errors, which is not great. Also, I assume the OS and browser vendors do some sort of verification before adding a CA to their list of root certs. Is the me…
It's not about extra verification, it's about reducing the attack surface.
If your browser trusts 100 different CAs, I can MITM you after compromising any one of those 100. If you only actually use 10 of them, then you can remove the other 90 from your trusted list and make my (the attackers') job 10x harder. More-or-less regardless of which individual CAs take security a bit more seriously than the others, since they're all held to a reasonable minimum standard.
Re: Reducing the Roots of Some Evil
#6I have done this by hand by manually "untrusting" all CAs and then enabling them one by one as I go along. I never found a good way to move the lists of CAs across browsers. However for ssl-certificates in Debian propagating the list across different machines was a breeze with etckeeper. Being able to apt-get install cawatch would be a lot easier.
Do you really want to rely on China's CNIC to make the decision if you should trust a certificate?
Re: Reducing the Roots of Some Evil
#7This seems ok if you have a tech-savvy user base that understands how to re-add a root certificate if they later hit a legitimate site using one of the removed root certs. If you user base isn't that savvy, I'm afraid you would just be training them to ignore SSL errors, which is not great. Also, I assume the OS and browser vendors do some sort of verification before adding a CA to their list of root certs. Is the me…
Mozilla and others have done some verification. They verified that the CNNIC root does belong to the chinese government.[1] In light of that verification do you want to allow CNNIC to attest to the validity of the certificate for your favorite vendor/webmail/employer?
[1] http://www.mozilla.org/projects/security/certs/included/#CNN...
Re: Reducing the Roots of Some Evil
#8This seems ok if you have a tech-savvy user base that understands how to re-add a root certificate if they later hit a legitimate site using one of the removed root certs. If you user base isn't that savvy, I'm afraid you would just be training them to ignore SSL errors, which is not great. Also, I assume the OS and browser vendors do some sort of verification before adding a CA to their list of root certs. Is the me…
It's not about extra verification, it's about reducing the attack surface. If your browser trusts 100 different CAs, I can MITM you after compromising any one of those 100. If you only actually use 10 of them, then you can remove the other 90 from your trusted list and make my (the attackers') job 10x harder. More-or-less regardless of which individual CAs take security a bit more seriously than the others, since the…
"since they're all held to a reasonable minimum standard."
Except the ones that are too big to fail right?
Re: Reducing the Roots of Some Evil
#9This seems ok if you have a tech-savvy user base that understands how to re-add a root certificate if they later hit a legitimate site using one of the removed root certs. If you user base isn't that savvy, I'm afraid you would just be training them to ignore SSL errors, which is not great. Also, I assume the OS and browser vendors do some sort of verification before adding a CA to their list of root certs. Is the me…
It's not about extra verification, it's about reducing the attack surface. If your browser trusts 100 different CAs, I can MITM you after compromising any one of those 100. If you only actually use 10 of them, then you can remove the other 90 from your trusted list and make my (the attackers') job 10x harder. More-or-less regardless of which individual CAs take security a bit more seriously than the others, since the…
> then you can remove the other 90 from your trusted list and make my (the attackers') job 10x harder
or possibly infinitely easier if the users become accustomed to accept ssl errors due lacking root certs.