6 ms·

For folks discovering this: Unfortunately, this isn’t a good idea, and can seriously harm your system. I’ll be the first to tell you that I believe Google and

by sleevi 6y ago

For folks discovering this: Unfortunately, this isn’t a good idea, and can seriously harm your system. I’ll be the first to tell you that I believe Google and Mozilla have done a lot for supervising TLS, but realize that the trust stores contain many other non-TLS purposes, and with the CAs constrained from TLS issuance (e.g. only trust for S/MIME). CryptoAPI, for its warts, is actually beautifully engineered, in that Microsoft has had the ability to add arbitrary constraints and properties to certificates from the very first release (via CERT_PROP_IDs). You don’t really see these in the UI; you only find out about them in WinCrypt.h, or via debugger stepping. However, it means that even if the UI is showing “trusted for TLS”, Microsoft may have disabled trust for TLS via the extended properties, which their APIs respect, and which are delivered through authroots.cab You can see a little bit about this at https://github.com/crtsh/certwatch_db/issues/69 https://github.com/crtsh/certwatch_db/issues/69 and http://unmitigatedrisk.com/?p=259 http://unmitigatedrisk.com/?p=259 Approaches like the OP link fail to take that into consideration, and can easily break core OS services, non-TLS cases like code signing or S/MIME, or even reintroduce trust in CAs that Microsoft has programmatically disabled.

BuildTheRobots 6y ago
> CryptoAPI, for its warts, is actually beautifully engineered, in that Microsoft has had the ability to add arbitrary constraints and properties to certificates from the very first release (via CERT_PROP_IDs). You don’t really see these in the UI; you only find out about them in WinCrypt.h, or via debugger stepping. However, it means that even if the UI is showing “trusted for TLS”, Microsoft may have disabled trust for TLS via the extended properties, which their APIs respect, and which are delivered through authroots.cab I mean no disrespect, but if you need to look through header files or use step-through debugging to actually find out what constraints apply to a certificate, especially when the ones actually reported for the certificate don't actually apply in reality then "beautifully engineered" doesn't seem like the right adjective to use. edit: I don't see this as a documentation issue; when the only interface you provide the user says one thing but stepping through the code reveals that that's entirely not true for certain items in certain circumstances, then having a better ReadMe is not the issue here.
- sleevi 6y ago
  I suppose it’s a question of whether you count “documentation” as engineering. It is elegantly complex and featureful. And (sometimes intentionally) poorly documented, as much of that implementation is seen as “an implementation detail”.
  - munchbunny 6y ago
    Especially when it comes to API's, documentation is 100% part of the engineering. Very few non-trivial API's are self-explanatory because you have to map a complex problem space to an imperfect engineering-focused formulation of the problem domain, and the mapping usually involves introducing design patterns to make the problem space easier to manage in code.
- tasogare 6y ago
  It can be beautifully engineered yet poorly documented. It happens to quite a lot of software actually.
  - beamatronic 6y ago
    I think that more documentation needs to give context about design decisions/principles and why they were made. And hopefully the software is sticking to some principles. If you can learn a small number of orthogonal principles, you can predict the behavior of the software without consulting the documentation, ideally
- GordonS 6y ago
  As someone who's actually had to use the CryptoApi, I think it's unpleasant to use, and often the documentation isn't good enough. There is also usually at least 4 different ways of getting to the same result, which makes things very confusing. And some features are only supported from Windows 7/10. "Beautifully engineered" is not the phrase that comes to mind.
  - munchbunny 6y ago
0xCMP 6y ago
Pretty bad that “trusted” could mean blocked and it was only possible to know this in Windows 10
tialaramex 6y ago
The approach Microsoft took here encourages something we both I think agree is a bad idea, roots used for multiple potentially conflicting purposes. The owner of the multi-purpose root will either make a big fuss when policy changes down the road make that conflict painful or worse they'll persuade themselves that we can't really have meant what we just told them because it's so painful, "obviously" the policy change doesn't apply to their multi-purpose root and they'll ignore it until discovered. If for example Microsoft had separate "Code signing" and "Web PKI" trust programmes then you get two good things for the price of one: Less incentive for CAs to do things we'll regret even if they don't; and clarity for users about the purpose of the trust relationship. Mozilla could do better here too, it's actually not easy to discern from Firefox which built-in CA roots are actually trusted in the Web PKI, and it's outright impossible as far as I know to discover any of the special case restrictions described in https://wiki.mozilla.org/CA/Additional_Trust_Changes https://wiki.mozilla.org/CA/Additional_Trust_Changes from the user interface of the software itself.
- btown 6y ago
  > roots used for multiple potentially conflicting purposes Wouldn't this lead to a proliferation of protocol/purpose-specific roots, to the extent that there might be so many critical roots that administrators become careless about vetting requests to add a root, or audit logs that a root is added? It feels like the solution is a better UI to visualize the many-to-many relationship between roots and protocols/purposes, rather than requiring every root to be single-purpose.
  - sleevi 6y ago
    I think you’re right for questioning the end-state, but you may be missing the current status quo. The current status quo of multi-purpose roots is that supervision of a root, by a browser, auditor, and the CA themselves, constantly has to consider all the purposes a certificate is trusted for when considering the effective policies and design. The classic example I give is that multiple CAs would have policies like “If it’s intended for TLS server auth, we put the domain name in the CN field and make sure it’s a real domain name. If it’s for document signing, we put the company name in the CN field and make sure it’s a real company name”, and with no further distinction between the two. So what happens when you have a company named “pets.com” - did they validate the domain or not? What about if they misissued a TLS certificate. For TLS, you can quantify the impact, and you can move to distrust the CA, only thinking about how TLS works in your application. But what if they also issued certificates for lawyers used in judicial proceedings, and rely on the CA being trusted in the OS? This was the exact problem with DigiNotar, and why it took Microsoft over a month to fully respond, where Google and Mozilla took days. We see similar issues with audits, and CAs having sub-CAs not “intended” to issue a particular type of certificate, but totally doing so. For lack of a better analogy, and since earlier in this post I was talking about API design, the choice of singular trust purposes is like the S in SOLID. You want a single responsibility, clear, and do that well. It makes it easier to change and evolve that API when you don’t have to worry about breaking 30 odd unrelated use cases. And it lets you narrowly focus the supervision to the task at hand.
tinus_hn 6y ago
So it’s hidden magic, yet the EULA states you are responsible for choosing which roots to trust.
scoot_718 6y ago
If you can't even remove CAs from the trust store without breaking it, then it doesn't fucking work, does it?

by sleevi 6y ago

BuildTheRobots 6y ago

> CryptoAPI, for its warts, is actually beautifully engineered, in that Microsoft has had the ability to add arbitrary constraints and properties to certificates from the very first release (via CERT_PROP_IDs). You don’t really see these in the UI; you only find out about them in WinCrypt.h, or via debugger stepping. However, it means that even if the UI is showing “trusted for TLS”, Microsoft may have disabled trust for TLS via the extended properties, which their APIs respect, and which are delivered through authroots.cab I mean no disrespect, but if you need to look through header files or use step-through debugging to actually find out what constraints apply to a certificate, especially when the ones actually reported for the certificate don't actually apply in reality then "beautifully engineered" doesn't seem like the right adjective to use. edit: I don't see this as a documentation issue; when the only interface you provide the user says one thing but stepping through the code reveals that that's entirely not true for certain items in certain circumstances, then having a better ReadMe is not the issue here.

sleevi 6y ago
I suppose it’s a question of whether you count “documentation” as engineering. It is elegantly complex and featureful. And (sometimes intentionally) poorly documented, as much of that implementation is seen as “an implementation detail”.
- munchbunny 6y ago
  Especially when it comes to API's, documentation is 100% part of the engineering. Very few non-trivial API's are self-explanatory because you have to map a complex problem space to an imperfect engineering-focused formulation of the problem domain, and the mapping usually involves introducing design patterns to make the problem space easier to manage in code.
tasogare 6y ago
It can be beautifully engineered yet poorly documented. It happens to quite a lot of software actually.
- beamatronic 6y ago
  I think that more documentation needs to give context about design decisions/principles and why they were made. And hopefully the software is sticking to some principles. If you can learn a small number of orthogonal principles, you can predict the behavior of the software without consulting the documentation, ideally
GordonS 6y ago
As someone who's actually had to use the CryptoApi, I think it's unpleasant to use, and often the documentation isn't good enough. There is also usually at least 4 different ways of getting to the same result, which makes things very confusing. And some features are only supported from Windows 7/10. "Beautifully engineered" is not the phrase that comes to mind.
- munchbunny 6y ago

0xCMP 6y ago

Pretty bad that “trusted” could mean blocked and it was only possible to know this in Windows 10

tialaramex 6y ago

The approach Microsoft took here encourages something we both I think agree is a bad idea, roots used for multiple potentially conflicting purposes. The owner of the multi-purpose root will either make a big fuss when policy changes down the road make that conflict painful or worse they'll persuade themselves that we can't really have meant what we just told them because it's so painful, "obviously" the policy change doesn't apply to their multi-purpose root and they'll ignore it until discovered. If for example Microsoft had separate "Code signing" and "Web PKI" trust programmes then you get two good things for the price of one: Less incentive for CAs to do things we'll regret even if they don't; and clarity for users about the purpose of the trust relationship. Mozilla could do better here too, it's actually not easy to discern from Firefox which built-in CA roots are actually trusted in the Web PKI, and it's outright impossible as far as I know to discover any of the special case restrictions described in https://wiki.mozilla.org/CA/Additional_Trust_Changes https://wiki.mozilla.org/CA/Additional_Trust_Changes from the user interface of the software itself.

btown 6y ago
> roots used for multiple potentially conflicting purposes Wouldn't this lead to a proliferation of protocol/purpose-specific roots, to the extent that there might be so many critical roots that administrators become careless about vetting requests to add a root, or audit logs that a root is added? It feels like the solution is a better UI to visualize the many-to-many relationship between roots and protocols/purposes, rather than requiring every root to be single-purpose.
- sleevi 6y ago
  I think you’re right for questioning the end-state, but you may be missing the current status quo. The current status quo of multi-purpose roots is that supervision of a root, by a browser, auditor, and the CA themselves, constantly has to consider all the purposes a certificate is trusted for when considering the effective policies and design. The classic example I give is that multiple CAs would have policies like “If it’s intended for TLS server auth, we put the domain name in the CN field and make sure it’s a real domain name. If it’s for document signing, we put the company name in the CN field and make sure it’s a real company name”, and with no further distinction between the two. So what happens when you have a company named “pets.com” - did they validate the domain or not? What about if they misissued a TLS certificate. For TLS, you can quantify the impact, and you can move to distrust the CA, only thinking about how TLS works in your application. But what if they also issued certificates for lawyers used in judicial proceedings, and rely on the CA being trusted in the OS? This was the exact problem with DigiNotar, and why it took Microsoft over a month to fully respond, where Google and Mozilla took days. We see similar issues with audits, and CAs having sub-CAs not “intended” to issue a particular type of certificate, but totally doing so. For lack of a better analogy, and since earlier in this post I was talking about API design, the choice of singular trust purposes is like the S in SOLID. You want a single responsibility, clear, and do that well. It makes it easier to change and evolve that API when you don’t have to worry about breaking 30 odd unrelated use cases. And it lets you narrowly focus the supervision to the task at hand.

tinus_hn 6y ago

So it’s hidden magic, yet the EULA states you are responsible for choosing which roots to trust.

scoot_718 6y ago

If you can't even remove CAs from the trust store without breaking it, then it doesn't fucking work, does it?