1408647 - Logius: Staat der Nederlanden CA trust issue (WiV)

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Compliance, task)

Description

[cris.vanpelt]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38

Steps to reproduce:

Accept default trusted certificates.


Actual results:

Became vulnerable to MitM attacks.

The new "Wet op de inlichtingen- en veiligheidsdiensten (Wiv)" (Law for intelligence and security services) has been accepted by the Dutch Government. Provisions authorizing new powers for the dutch intelligence and security services will become active starting January 1st, 2018.

This revision of the law will authorize intelligence and security to intercept and analyze cable-bound (Internet) traffic, and will include far-reaching authorizations, including covert technical attacks, to facilitate their access to encrypted traffic.

Article 45 1.b, explicitly authorizes the use of "false keys" in third party systems to obtain access to systems and data.

The continued inclusion of the "Staat der Nederlanden" Certificate Authority, which is operated by PKIOverheid / Logius, a division of the Ministry of Interior and Kingdom Relations-- the same ministry under which the AIVD intelligence service operates-- in Mozilla products is therefore no longer appropriate.

The full text of the law may be found here https://www.aivd.nl/binaries/aivd_nl/documenten/kamerstukken/2017/08/17/publicatie-in-staatsblad-van-wiv-2017/20170817+Publicatie+Wiv+2017+in+Staatsblad.pdf


Expected results:

Revoke trust for Staat der Nederlanden CA. Allowing the Ministry of Interior and Kingdom Relations to continue operating a trusted CA in a country hosting a major Internet transit point would be detrimental to the security of all Mozilla users.

Comment 1

[Kathleen Wilson]

Mark, Please add comments to this bug to explain this situation.

Comment 2

[Kathleen Wilson]

Changing component to "CA Certificate Mis-Issuance" so it will get tracked in the correct wiki pages. Though, this seems to be a different type of problem.

Comment 3

[Mark Janssen]

Hi Kathleen,

Thanks for bringing this to my attention. 

Since the nature of this bug is not strictly related to ‘running a CA’ I will have to contact the policy advisers from our Ministry of Interior and Kingdom Relations about this. Therefore I will give a response on this bug no sooner than next week. 

Thanks. 

Regards,
Mark

Comment 4

[Jeroen Hellingman]

This is a symptom of a more general issue with certificates based on a hierarchy of trust. Similarly, many other (and often less transparent) governments will be able to compel holders of certificates to issue rogue certificates for law-enforcement purposes, for example, to be used in man-in-the-middle attacks. Withholding trust in this case would be more of a political statement than a really effective way of curbing such legally sanctioned abuses. Furthermore, with the only options being 'trust' or 'don't trust', this is prone to break down the entire certificate system, which, without a proper system in place to replace is not productive.

A better approach here would be:

1. To educate users about the fundamental limits of certificates. For example, you will be forced to trust the producer of your hardware and software to not build in backdoors of any kind. If these are compromised, no certificate system is going to help. Realize that government actors can force such things in many cases.

2. To limit the acceptance of certificates of foreign countries to those domains where you have reason to believe the government has legal access to the resource already. That is, I am perfectly happy to accept a Chinese certificate to warrant the website of a Chinese bank, but definitely want to be alerted if the same certificate is used to "secure" a US bank. The same also works in reverse: If a China-based website is suddenly "secured" by a Dutch certificate, this should raise a red flag. It is fairly simple to implement "Trust CA only for sites within its jurisdiction" I would love to have such an option.

3. Furthermore, you could look into options to have parties sign certificates in multiple jurisdictions, such that no single government is able to force falsified certificates being issued.

4. Finally, integration of methods of reviewing certificate history and observed usage, and tying the issuance of certificates to a blockchain may make it harder to abuse the CA mechanism.

Comment 5

[Guido Leenders]

Great improvement. It resembles the approach taken for establishing credit risk based upon counter party by BIS. For a foreign party, the counterparty's risk (trust) can never be better than that of the national bank of that country (not legislation for most cases, but in general legislation matches country). When both parties are in the same country, the rating of the national bank is considered irrelevant.

Comment 6

[djmaze]

Wouldn't it be better to allow to mark a CA Root "Suspicious" in the Certificate Manager.
And then when you visit a website that has "Suspicious" CA Root you get a message box:

The website "example.com" uses root certificate "Staat der Nederlanden CA" which you marked suspicious.
[Allow] [Report]

Allow: attach domain name to certificate (show warning again when root certificate changes).
Report: sends a trust issue report to Mozilla for investigation


This is also usefull when software tries to inject new certificates in a browser (like virusscanners).

Comment 7

[Ryan Sleevi]

To those commenting: This is not an appropriate venue for your discussion. This is about a specific incident. Please feel free to discuss on the mozilla.dev.security.policy mailing list your concerns and ideas, but please do not do so on Bugzilla.

Comment 8

[Jeroen Hellingman]

Thank you Ryan, will bring up the issue in the appropriate fora. Note that my comment was inspired by the consideration that the original incident may have been reported as a political statement and is not just another technical incident.

Comment 9

[Maxim]

I have removed "Staat der Nederlanden CA" certificates manually. I appreciate any strict security checks.

Comment 10

[Mark Janssen]

Dear Kathleen and community,

With regard to the request in this bug, to revoke trust for Staat der Nederlanden Root CA, I would like to describe the setup and some important checks and balances from PKIoverheid. 

Setup PKIoverheid:
The setup of PKIoverheid has been (since its inception in 2002) that the government is responsible for managing the Staat der Nederlanden Root CA and the 1st intermediate level (Domain CAs), all of which are offline CAs. The Policy Authority is also responsible for setting additional requirements on top of the requirements set forth by browsers like adherence to the BR, specific trust store program requirements and auditing. 

PKIoverheid is managed by Logius, Logius is part of the Ministry of Interior and Kingdom Relations. 
Logius does not issue certificates directly to end-users. Neither does the Ministry. Logius only issues CA certificates to Trusted Services Providers (TSPs). Logius doesn’t own nor has access to the private keys from the TSPs. The PKIoverheid TSPs issue several types of certificates, such as authentication, encryption, non¬repudiation and SSL (OV & EV) to end-users. TSPs can be commercial or governmental organizations.  

Checks and balances:
1.	Logius and the TSPs are both subjected to audits by an independent auditor;

2.	Logius also supervises the RA/CA services from the PKIoverheid TSPs. An example of this can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1391864;

3.	Logius is accountable for our PKIoverheid TSPs and we ensure that our TSPs demonstrably adhere to our documented policies and the audit criteria;

4.	We provide publicly verifiable documentation and proof of annual audits for each TSP that are in compliance with our documented policies and the audit criteria; 

5.	TPS CA certificates issued by the G3 (and newer) Domain CAs include pathLenConstraint=0; This means that TSPs can’t sign a subCA or cross-sign another CA and issue end-entity certificates with it. The PA PKIoverheid can, if needed, revoke TSP CA certificates;

6.	There is full disclosure from our complete PKIoverheid hierarchy in The Common CA Database (CCADB);

7.	There is also supervision on the TSPs by the Agentschap Telecom (the national oversight agency for both wired and wireless communication) which is in turn supervised by the EU regulator;

8.	Since 10/1/2017 Logius has made CT logging mandatory for PKIoverheid TSPs issuing TLS certificates. 

See for additional information: https://bugzilla.mozilla.org/show_bug.cgi?id=1016568 and https://bug1016568.bmoattachments.org/attachment.cgi?id=8504870 

Thanks.

Regards,
Mark Janssen

Comment 11

[cris.vanpelt]

Thank you for your response, Mark.

I feel I should clarify that the trust issue from the original bug report was not with the TSPs, it is with the Tier 1 and Tier 2 Staat der Nederlanden root CA, which is operated by Logius. Your response deals almost exclusively with oversight on Tier 3 TSPs issuing certificates to end-users, which are not the concern of the original report.

> Logius does not issue certificates directly to end-users. Neither does the Ministry. Logius only issues CA certificates to Trusted Services Providers (TSPs).

Replacing the Logius-operated trusted certificates with certificates from TSPs may then be an acceptable resolution. Points 2 through 8 under "Checks and balances" in your response would apply to TSPs, but, given that Logius itself is not a TSP, as it does not issue certificates directly, none of these checks apply to the certificates currently included in the Mozilla Included CA Certificate list.

To reiterate, the concern is that an end-user service, or an intermediate CA, may be incorrectly validated by the PKIOverheid Tier 1 or Tier 2 CA, which are included in Mozilla's trusted CA store. The reason for this concern is that Logius operates directly under the Ministry which has explicitly been granted the legal authority to forge (cryptographic) materials to obtain access to systems and information.

Given that a lot of Internet-traffic is encrypted, having this direct avenue for MitM-attacks available, under its own purview, would greatly increase the Ministry's intelligence services' capabilities to intercept Internet communications. It follows that these increased capabilities, plus the expressed intent to intercept traffic, is very much detrimental to the privacy and security of Mozilla users who may be targeted by the intelligence services. Revoking trust would close this particular avenue.

To summarize;

  1. The oversight on Logius/PKIOverheid is minimal (point 1); in stark contrast to the oversight on TSPs (point 2-8).
  2. The Dutch government, and its intelligence services operating under the same ministry as Logius/PKIOVerheid, have repeatedly expressed an intent to intercept (encrypted) Internet communications.
  3. The new WiV explicitly allows for the Ministry operating PKIOverheid to forge cryptographic keys and other materials to intercept communications (WiV art. 45).

I do not believe these particular concerns have been addressed in your response; there should not be continued trust of any party which has expressed an intent, and has gained the legal authority, to intercept communications.

Comment 12

[Mark Janssen]

Thanks Cris.

>To reiterate, the concern is that an end-user service, or an intermediate CA, may be incorrectly validated by the PKIoverheid Tier 1 or Tier 2 CA, which are included in Mozilla's trusted CA store.

As stated our T1 and T2 are off-line. Signing a (CA) certificate means a key ceremony. Because of #1 we are obliged to notify our independent auditor about this. The independent auditor will witness the key ceremony. If we don’t notify our auditor in such cases than this will lead to a major non-conformity with regard to our WebTrust audit (Tier 1 and 2). 
    
Because of #6 our Tier 1 and 2 are also fully disclosed. Because of #8 this scenario would very quickly be noticed by the browsers and the community through the Certificate Transparency system. Because of #3 the penalty from all the browser vendors would be severe, probably resulting in a complete distrust of the Staat der Nederlanden Root CA hierarchy. This will lead to substantial financial damages for the Dutch Government.     

Frankly, given our checks and balances and the (severe) penalty from browser vendors for PKIoverheid if we don’t adhere to these checks and balances, I don’t see a viable scenario that would lead to the trust issue as described by you. 

Thanks. 

-Mark

Comment 13

[Yuhong Bao]

(In reply to djmaze from comment #6)
> Wouldn't it be better to allow to mark a CA Root "Suspicious" in the
> Certificate Manager.
> And then when you visit a website that has "Suspicious" CA Root you get a
> message box:
> 
> The website "example.com" uses root certificate "Staat der Nederlanden CA"
> which you marked suspicious.
> [Allow] [Report]
> 
> Allow: attach domain name to certificate (show warning again when root
> certificate changes).
> Report: sends a trust issue report to Mozilla for investigation
> 
> 
> This is also usefull when software tries to inject new certificates in a
> browser (like virusscanners).

Netscape used to support this AFAIK.

Comment 14

[Gervase Markham [:gerv]]

Absent actual evidence, or a statement of intent from a government that they intend to use their CA to conduct SSL MITM, I think that we can't take action against government CAs simply because they pass surveillance laws. The difficult definition of "government CA" also comes into play here - some governments are clear that they own the CA, whereas in other countries the line between government and non-government is very blurred; if a CA there claims to be non-government but we are skeptical of this claim, do they get an advantage over a CA in a country where the lines are clear? Also, many governments might engage in surveillance behaviour without bothering to pass a clear law about it; do those governments get an advantage over those who are more up-front about the legal capabilities of their intelligence services?

Removing a CA for this reason seems to me to set up the following incentives for governments:

* Don't be clear about what powers you have given your intelligence services; and
* Don't be clear about whether or not you own and control "your" CA.

Neither of these things seems good to encourage.

Fortunately, the CA ecosystem is evolving more and more transparency and accountability features which make it harder for CAs, governmental or otherwise, to abuse their power even with intent. These, it seems to me, are the best way to be certain of good behaviour. 

Gerv