On 07/01/2016 22:21, Paul Wouters wrote:
On Thu, 7 Jan 2016, Jakob Bohm wrote:
It would appear from this information, that this CA (and probably
others like it) is deliberately serving a dual role:
1. It is the legitimate trust anchor for some domains that browser
users will need to access (in this case: Kazakh government sites
under gov.kz).
2. It is the trust anchor for fake MITM certificates used to harm
browser users, and which should thus be regarded as invalid.
Thus it would be prudent to extend the trust list format (and the NSS
code using it) to be able to specify additional restrictions beyond
those specified in the CA root itself.
Much easier would be to not allow a CA cert not to engage in such dual
roles.
Unfortunately, we have little power to do that. So if we don't accept
the CA, the users have to install a different browser or install that
CA manually in order to e.g. pay their taxes, but if we do accept it
without filtering, we expose them to the MITM.
- Additional path restrictions. Example 1: The Microsoft internal CA
should only be trusted for a list of Microsoft owned domains.
I'm not sure how to that would work in practise. I know it can be done
using TLSA DNS records to pin each domain. Having that logic elsewhere
seems more dangerous and less transparent.
I seem to have seen "recent" X.509 extensions that can restrict the DNS
domains for which a CA can (directly or indirectly) issue certificates.
Compare the "Technically restricted" subCA clauses in current Mozilla
criteria.
Idea would be to "tack on" additional semantically equivalent
restrictions even where not present in the actual CA cert.
Example 2: Many nation state CAs should only be trusted for sites
under that country cc-tld, and sometimes only for a subdomain
thereunder such as gov.kz).
I have a serious problem with this because the users are not explicitely
agreeing to this and so this is facilitating a MITM no different then
SSL middleware boxes. And those are only allowed to installed manually,
with the user's (or enterprise's) consent.
It's the opposite. Restricting single-country CAs from being trusted
for wordwide URLs while still being trusted for URLs for which it is
appropriate.
For the dual use nation-CA case this means allowing worldwide users to
connect securely to that nations government websites, while protecting
them from MITM attacks.
For the ordinary nation-CS case, the means limiting the scope of trust
to nation addresses. For example "Staat der Neederlanden" would not be
trusted for .com domains such as google.com, thus preventing (if it had
been implemented back then) the DigiNotar breach from affecting Google
users in Iran visiting .com domains.
- Permitted EKU (Extended Key Usage) OIDs. Example, many nation
state eID CAs should be restricted to "e-mail signing" and "client
authentication", even if the CA itself suggests a more wide usage.
Enforcing proper EKU's would be good so nation state CA's meant for
official communication with citizens cannot be abused for MITMing those
same citizens.
Note though that EKUs don't limit the domains or identities for which a
CA issues (real or MITM) certificates, only the protocols and protocol
roles. For example being a HTTPS server is one EKU, being an e-mail
signature is another EKU etc. Hence all my other suggestions.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
