4 ms·

Root certificates are just one manifestation of a much larger problem, which could be described as follows: 1. Nobody checks the source code of the software in

by agwa 11y ago

Root certificates are just one manifestation of a much larger problem, which could be described as follows: 1. Nobody checks the source code of the software installed on their machines (or that the binaries were actually built from the purported source code). 2. Our software vendors can push new software in automated updates without anyone knowing about it. Suppose that the CA system were replaced with a PGP-style web-of-trust or SSH-style trust-on-first-use system. How would you know that your software vendor has supplied you with a TLS implementation that's correctly and faithfully implemented? Just as they can push out new root CAs, they can push out a new TLS implementation that introduces a bug or backdoor that bypasses all trust checks. So why single out root certificates?

javajosh 11y ago
>So why single out root certificates? Because you can only solve one problem at a time.
dpacmittal 11y ago
If you use Linux, both issues are pretty much sorted. Repositories provide a great way to install trusted software, if you're careful about which repositories you install on your system.
- andrewstuart2 11y ago
  Well, the issue of "nobody checks the source" is not necessarily solved. Just because anyone can check the source doesn't mean anyone actually does. Additionally, just because a repository has been historically trustworthy never means it can't be corrupted. There are real people behind all levels of these projects, and people are vulnerable to corruption, coercion, etc.
  - e12e 11y ago
    True. But with signed source (if you can trust the verifier... turtles all the way down) and projects for reproducible builds, like[1] -- the job of checking can be distributed, and you can trust several different parties to do part of the work. Now, I still think it makes sense to single out the opaque-ness of CA trust. The Raison-de-etre for the whole CA system is trust, more specifically delegating trust. It provides nothing else. Which is why it's so ridiculous that by default the browsers will trust the Chinese and German governments to vouch for Swiss banks, American companies to vouch for wikileaks -- even if the Swiss banks or Wikileaks don't trust those entities. [1] https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds
  - nickpsecurity 11y ago
    Exactly. I'll add that we keep seeing obvious vulnerabilities in open source code that go back years. Hence my essay on different types of Source Sharing and Review that shows the actual assurance is in the review not source sharing agreement. Hard to assess how much review any given FOSS got and obviously harder for most proprietary. Sometimes impossible for both. https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639 https://www.schneier.com/blog/archives/2014/05/friday_squid_...
    - walterbell 11y ago
      Tangent: is there an easy way to find/download all the comments you have posted to Schneier's blog? They would be more accessible in a github Jekyll repo, or any source format which could be converted to a single PDF for offline reading.
      - nickpsecurity 11y ago
        Haven't gotten around to doing that since I've been so busy past few years and... the posts added up to a lot of work. Call it my technical debt. ;) Hadn't thought of PDF. Nice idea. Right now I have two things: textfile with links to many key posts there with headings; a zip file with a good chunk of those in local text copies. I've always used text because it's the safest and most portable format (except on modern devices lol). I can give you a pastebin with the links or a link to the zip with containing the subset I've downloaded so far. Whatever you prefer. Eventually I'll have one link to an actual web site haha.
        walterbell 11y ago
        Zip of local text copies would be great, thanks!
        nickpsecurity 11y ago
        Below is the link to the zip. I included the two indexes that have the links. Most designs are local already but the essays folder has only a tiny amount of my essays. So, look at the essays txt file because there's quite a few great ones (including OPSEC) that I haven't transcribed yet. Download it quick because I take it down in a few days. http://www.adrive.com/public/uxCBKn/select%20schneier%20posts.zip http://www.adrive.com/public/uxCBKn/select%20schneier%20post...
  - jessaustin 11y ago
    If you don't want to trust the Debian maintainers, you don't have to. Trusting them, however, is a valid decision for many people.
- rtpg 11y ago
  so the trust is in Debian or whoever's running your repos instead of MSFT. I don't see how that really changes the dynamic a lot. The problem with most people's complaints and solutions about certificate authorities is that pretty much every proposed solution, when applied at scale, becomes functionally equivalent to the web of trust system we currently have. At one point you have to trust _somebody_.
ised 11y ago
"2. Our software vendors can push new software in automated updates..." Question: Why does the software need to be updated? Vendor: "Bug fixes." Question: Can I look at the source code? Vendor: No. I agree with agwa that this phenomenon of "automatic updates" goes well beyond root certificates and browser authors such as Microsoft. It is pervasive and seems to be growing. Perhaps a related line of thought, I find it interesting that we are seeing some again pushing for enabling browsers to have more control over the user's computer. Simply put, as I see it, a user visits a webpage and someone else gets to run their code on the user's computer. Why stop there? Why not have email attachments that open and execute automatically? Originally there was the "Java applet" idea in the early days of the www. Then there was Adobe Flash. These days the idea it has several different working names. Obviously neither Java nor Flash is the language of choice. And the browser authors have something to try to put users' minds at ease: "sandboxing". But I see no difference in the issues this raises for users. Is there any "sandboxing" for the browser itself? The browser and its authors are inherently trusted? In the same way that root certificates installed on users' computers are "pre-approved"? Who approved them? Are users involved in that approval process? If the certificate/code in question comes from the browser authors then it must be both necessary for and desired by each and every user? The problem with automated updates from my perspective is that there are very few software authors who will not try to give me more than I actually need; if I am not careful I end up with the "kitchen sink". Without user intervention, software is like a gas: it will expand to fill space. As for the CA system, I am my own CA root. The openssl binary is the antithesis of the so-called UNIX philosophy. How many things does it do? Perfect for an example program to include for "testing". This goes to agwa's comment. I use this software but I know it is quality control disaster. Keep those updates coming. In any event, the only certificates I "trust" are ones which I did not obtain over an untrustworthy network, i.e., the internet. That number is of course zero. I will sign a certificate to satisfy a browser, but that does not mean I "trust" any part of the process. In practice, outside of organizational use, I see the whole CA scheme as a joke. (But not that its implementation has impeded the success of e-commerce.) As a user, I play along with SSL/TLS and certificates only to get today's software to work. That's it. A nuisance more than anything else.
- e12e 11y ago

by agwa 11y ago

javajosh 11y ago

>So why single out root certificates? Because you can only solve one problem at a time.

dpacmittal 11y ago

If you use Linux, both issues are pretty much sorted. Repositories provide a great way to install trusted software, if you're careful about which repositories you install on your system.

andrewstuart2 11y ago
Well, the issue of "nobody checks the source" is not necessarily solved. Just because anyone can check the source doesn't mean anyone actually does. Additionally, just because a repository has been historically trustworthy never means it can't be corrupted. There are real people behind all levels of these projects, and people are vulnerable to corruption, coercion, etc.
- e12e 11y ago
  True. But with signed source (if you can trust the verifier... turtles all the way down) and projects for reproducible builds, like[1] -- the job of checking can be distributed, and you can trust several different parties to do part of the work. Now, I still think it makes sense to single out the opaque-ness of CA trust. The Raison-de-etre for the whole CA system is trust, more specifically delegating trust. It provides nothing else. Which is why it's so ridiculous that by default the browsers will trust the Chinese and German governments to vouch for Swiss banks, American companies to vouch for wikileaks -- even if the Swiss banks or Wikileaks don't trust those entities. [1] https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds
- nickpsecurity 11y ago
  Exactly. I'll add that we keep seeing obvious vulnerabilities in open source code that go back years. Hence my essay on different types of Source Sharing and Review that shows the actual assurance is in the review not source sharing agreement. Hard to assess how much review any given FOSS got and obviously harder for most proprietary. Sometimes impossible for both. https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_424.html#c6051639 https://www.schneier.com/blog/archives/2014/05/friday_squid_...
  - walterbell 11y ago
    Tangent: is there an easy way to find/download all the comments you have posted to Schneier's blog? They would be more accessible in a github Jekyll repo, or any source format which could be converted to a single PDF for offline reading.
    - nickpsecurity 11y ago
      Haven't gotten around to doing that since I've been so busy past few years and... the posts added up to a lot of work. Call it my technical debt. ;) Hadn't thought of PDF. Nice idea. Right now I have two things: textfile with links to many key posts there with headings; a zip file with a good chunk of those in local text copies. I've always used text because it's the safest and most portable format (except on modern devices lol). I can give you a pastebin with the links or a link to the zip with containing the subset I've downloaded so far. Whatever you prefer. Eventually I'll have one link to an actual web site haha.
      - walterbell 11y ago
        Zip of local text copies would be great, thanks!
        nickpsecurity 11y ago
        Below is the link to the zip. I included the two indexes that have the links. Most designs are local already but the essays folder has only a tiny amount of my essays. So, look at the essays txt file because there's quite a few great ones (including OPSEC) that I haven't transcribed yet. Download it quick because I take it down in a few days. http://www.adrive.com/public/uxCBKn/select%20schneier%20posts.zip http://www.adrive.com/public/uxCBKn/select%20schneier%20post...
- jessaustin 11y ago
  If you don't want to trust the Debian maintainers, you don't have to. Trusting them, however, is a valid decision for many people.
rtpg 11y ago
so the trust is in Debian or whoever's running your repos instead of MSFT. I don't see how that really changes the dynamic a lot. The problem with most people's complaints and solutions about certificate authorities is that pretty much every proposed solution, when applied at scale, becomes functionally equivalent to the web of trust system we currently have. At one point you have to trust _somebody_.

ised 11y ago

"2. Our software vendors can push new software in automated updates..." Question: Why does the software need to be updated? Vendor: "Bug fixes." Question: Can I look at the source code? Vendor: No. I agree with agwa that this phenomenon of "automatic updates" goes well beyond root certificates and browser authors such as Microsoft. It is pervasive and seems to be growing. Perhaps a related line of thought, I find it interesting that we are seeing some again pushing for enabling browsers to have more control over the user's computer. Simply put, as I see it, a user visits a webpage and someone else gets to run their code on the user's computer. Why stop there? Why not have email attachments that open and execute automatically? Originally there was the "Java applet" idea in the early days of the www. Then there was Adobe Flash. These days the idea it has several different working names. Obviously neither Java nor Flash is the language of choice. And the browser authors have something to try to put users' minds at ease: "sandboxing". But I see no difference in the issues this raises for users. Is there any "sandboxing" for the browser itself? The browser and its authors are inherently trusted? In the same way that root certificates installed on users' computers are "pre-approved"? Who approved them? Are users involved in that approval process? If the certificate/code in question comes from the browser authors then it must be both necessary for and desired by each and every user? The problem with automated updates from my perspective is that there are very few software authors who will not try to give me more than I actually need; if I am not careful I end up with the "kitchen sink". Without user intervention, software is like a gas: it will expand to fill space. As for the CA system, I am my own CA root. The openssl binary is the antithesis of the so-called UNIX philosophy. How many things does it do? Perfect for an example program to include for "testing". This goes to agwa's comment. I use this software but I know it is quality control disaster. Keep those updates coming. In any event, the only certificates I "trust" are ones which I did not obtain over an untrustworthy network, i.e., the internet. That number is of course zero. I will sign a certificate to satisfy a browser, but that does not mean I "trust" any part of the process. In practice, outside of organizational use, I see the whole CA scheme as a joke. (But not that its implementation has impeded the success of e-commerce.) As a user, I play along with SSL/TLS and certificates only to get today's software to work. That's it. A nuisance more than anything else.

e12e 11y ago