Nation State MITM CA's ?

[Paul Wouters]

As was in the news before, Kazakhstan has issued a national MITM
Certificate Agency.

Is there a policy on what to do with these? While they are not trusted,
would it be useful to explicitely blacklist these, as to make it
impossible to trust even if the user "wanted to" ?

The CA's are available here:
http://root.gov.kz/root_cer/rsa.php
http://root.gov.kz/root_cer/gost.php

One site that uses these CA's is:
https://pki.gov.kz/index.php/en/forum/

Paul

[Kathleen Wilson]

Kazakhstan has submitted the request for root inclusion:
https://bugzilla.mozilla.org/show_bug.cgi?id=1232689

So, we really do need to have this discussion now.

I will appreciate thoughtful and constructive input into this discussion.

Kathleen

[Peter Bowen]

On Thu, Jan 7, 2016 at 11:00 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 1/6/16 3:07 PM, Paul Wouters wrote:

> Kazakhstan has submitted the request for root inclusion:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1232689
>
> So, we really do need to have this discussion now.
>
> I will appreciate thoughtful and constructive input into this discussion.

Kathleen,

The information in the bug is incomplete by Mozilla's policy. They
indicate that they plan to get a WebTrust audit but have not done so
at this time. They should be informed that they need both a WebTrust
for CA and a WebTrust for BR audit before their application can move
forward.

Additionally all of the documentation (CPS, diagrams, etc) is in a
language that uses the Cyrillic alphabet. I'll guess this is either
Kazakh or Russian, but I'm not sure as I don't read either.

I ran the CPS through an online translator and it appears to only
cover issuance of subordinate CAs. This, combined with their comment
on OCSP responder availability, makes it sound like this is a
'super-CA' (https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs).
This suggests that they need to provide more detail on the
subordinates, including subordinate CA CPS(es) and audits.

Until such time that the provide this, I don't see how they are any
different from the thousands of private PKIs that are run by companies
for their own use. Many of those PKIs may be used to MITM
connections.

All CAs should be held to the same standard when asking for admission
to the Mozilla program, this is no different.

Thanks,
Peter

[Kathleen Wilson]

On 1/7/16 11:15 AM, Peter Bowen wrote:
> <snip>

>
> Until such time that the provide this, I don't see how they are any
> different from the thousands of private PKIs that are run by companies
> for their own use. Many of those PKIs may be used to MITM
> connections.

OK. I suppose that means I should go ahead and start the information
verification process for this request.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

> All CAs should be held to the same standard when asking for admission
> to the Mozilla program, this is no different.

That's very logical.
I was sort of hoping to avoid spending the time doing the Information
Verification if I didn't have to.

Kathleen

[Jakob Bohm]

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.

For example the trust list could state (depending on the known
properties of each CA).

- Additional path restrictions. Example 1: The Microsoft internal CA
should only be trusted for a list of Microsoft owned domains.
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).

- 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.

- Different validity period: Some CAs have made radical changes in
practices and may thus need to be trusted only before/after such
change.

- Issuance date validity period: While not expressible in standard
X.509 certificate formats, it is sometimes meaningful to assign
different trusts based on when a (non-lying, non-compromised) CA made
a policy change. Example: The TDC OCES CA at some date changed from a
regular CA operation to an operation where all keys are kept on a
central server where users log in to sign stuff.

- Ability to list multiple combinations of restrictions for the same
actual CA certificate. For example different path restrictions for
different EKUs.

- Ability to trust or distrust subordinate CAs directly. Example 1:
The DigiNotar incident. Example 2: Sometimes a well-run CA is
technically a subordinate of a non-acceptable CA or a CA that needs
deeper restrictions. Example 3: A root may have too lax a policy for
signing subordinates. Example 4: A CA company may run all its CAs as
subordinates under a single root, but only some of those subCAs meet
Mozilla criteria. Example 5: Some historic roots, such a Equifax,
have been subsequently used as the root CA signing the new CAs as
subCAs.





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

[Paul Wouters]

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.

> - 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.

> 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.

> - 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.

Paul

[David E. Ross]

I suggest deferring any effort on this request other than informing the
certification authority that they need audits both for WebTrust for CA
and for BR. That notice should also indicate that, without PROPER
audits with public-facing audit reports, no action can be taken.

No other effort should be expended on this.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Jakob Bohm]

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.

[Peter Bowen]

On Thu, Jan 7, 2016 at 2:34 PM, David E. Ross <nob...@nowhere.invalid> wrote:
> On 1/7/2016 12:29 PM, Kathleen Wilson wrote:

> I suggest deferring any effort on this request other than informing the
> certification authority that they need audits both for WebTrust for CA
> and for BR. That notice should also indicate that, without PROPER
> audits with public-facing audit reports, no action can be taken.
>
> No other effort should be expended on this.

I agree 100%. MITM implies that they are not following BR, as there
is no way they can be validating domain control[1]. This should mean
that they cannot complete a BR audit without having a massive
qualification on the report.

Mozilla gets lots of requests for inclusion which are summarily closed
because the request does not meet the requirements; this should be
treated the same.

Thanks,
Peter

[1] I can imagine exactly one way they could claim to simultaneously
meet the BRs and issue MITM certificates: claim they are using a
practical control method and show that from their vantage point they
have practical control of the Internet. They could even modify HTTP
responses to inject validation tokens and/or modify DNS responses to
do the same. Obviously this is not the intent of practical control
validation but would be an interesting tactic.

[Eric Mill]

For the thread's reference, this is the relevant part of the application
(from attached scanned images, more extended than the text they included
inline on the Bugzilla thread) that describes the intended use:

https://s3.amazonaws.com/konklone-public/kazakh/kazakh1.png

And this section has some additional information about potential uses and
their intent to get a WebTrust audit:

https://s3.amazonaws.com/konklone-public/kazakh/kazakh2.png

-- Eric

On Thu, Jan 7, 2016 at 7:40 PM, Jakob Bohm <jb-mo...@wisemo.com> wrote:

> 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
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

[Jakob Bohm]

On 08/01/2016 03:19, Peter Bowen wrote:
>...

>
> [1] I can imagine exactly one way they could claim to simultaneously
> meet the BRs and issue MITM certificates: claim they are using a
> practical control method and show that from their vantage point they
> have practical control of the Internet. They could even modify HTTP
> responses to inject validation tokens and/or modify DNS responses to
> do the same. Obviously this is not the intent of practical control
> validation but would be an interesting tactic.
>

Could they, hypothetically, simply claim to use the real certificate on
the connection from their MiTM machines to the real server to do
practical control validation? They would have to claim, also, that
they are holding the private key of the MiTM certificate "in trust" on
behalf of the site owners "on whose behalf" the issued the certifiate?
(Just playing devils advocate).

[Gervase Markham]

On 07/01/16 19:15, Peter Bowen wrote:
> The information in the bug is incomplete by Mozilla's policy. They
> indicate that they plan to get a WebTrust audit but have not done so
> at this time. They should be informed that they need both a WebTrust
> for CA and a WebTrust for BR audit before their application can move
> forward.

This seems like the lowest-effort way to punt. I doubt they'd ever get
one - and if they did, I'd want to have very careful words with their
auditor.

Gerv

[Phillip Hallam-Baker]

On Thu, Jan 7, 2016 at 2:00 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 1/6/16 3:07 PM, Paul Wouters wrote:
>>
>>

> Kazakhstan has submitted the request for root inclusion:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1232689
>
> So, we really do need to have this discussion now.
>
> I will appreciate thoughtful and constructive input into this discussion.

I suggest waiting until they name their auditors before processing the request.

[Kai Engert]

I think several separate points need to be discussed.
(a) Inclusion as trustworthy for the global Internet

You might have seen this article, which, to my surprise, can no longer be found
on the site itself, so here is an archived copy:
https://web.archive.org/web/20151202203337/http://telecom.kz/en/news/view/18729

They don't say it explicitly, but it sounds like they intend to inspect all
encrypted Internet traffic that connects to the area outside of Kazakhstan.

Unless they plausibly deny that intention, I hope it's obvious that Mozilla
shouldn't trust them for issuing certificates for domains outside of Kazakhstan.

The suggestions that others have already made in this discussion, which is to
postpone their request for inclusion until they provide more details, seems like
a good reaction at this point.


(b) Including a CA as trustworthy but constrained to the Kazakhstan domain

I don't know if they have requested that yet, or if that might still be an
option, after (a) gets rejected. Separate discussion.


(c) Blacklisting their root certificates

I believe this is what Paul had suggested to do in this initial message.

Independently of the request for inclusion, this group could discuss if the
Kazakhstan's CAs should be blacklisted, by adding them to the Mozilla CA list
using negative distrust flags, which would effectively make it impossible for
them to be used in all software that is able to handle such entries, and that
bases its trust on the Mozilla CA list.

As a result, if a users connection is routed through a MITM system that creates
false certificates for the purpose of inspection, Firefox users would no longer
be able to connect to any sites using https/TLS.

If Kazakhstan intended to route the Internet traffic of all users through a MITM
inspection device, as a result, users of Kazakhstan would no longer be able to
use Firefox to visit web sites outside of Kazakhstan, nor use other software
that also uses the Mozilla CA list.

I think this is a difficult decision.

I assume Paul's idea was that doing natiowide MITM is a bad idea and that it
should be made impossible, by blocking any CAs used for such a purpose.

The question here is, would it help?

If Internet users in Kazakhstan couldn't connect to the Internet without
complying to laws that require mandatory MITM inspection, then users would have
to make the choice whether to avoid using the Internet at all, or to comply.

Those users who decided to comply would have to use a browser or a system that
doesn't block Kazakhstan's CAs. I believe they would still be able to find
software systems that allowed them to do that.

If we decided not to blacklist, but rather, to not include those CAs at all, the
users of default software would still get our usual security warnings, and have
the ability to discover that their connections aren't secure.

Those who decided to comply could modify their software by adding the CA as
trusted themselves (like the cited website above suggests them to do).

Given the text of the above web site, it seems that users are expected to modify
their systems anyway, by installing that CA as trustworthy.

If we blacklisted it, they would simply have to go one step further, by finding
a way to undo the blacklisting. As this currently isn't easily doable in e.g.
Firefox, blacklisting might force users to download specially modified software
that undoes the blacklisting and changes it to active trust, instead of being
able to use default software.

So, as bad as this situation is, and as much as I dislike the idea of a
nationwide MITM CA, which would effectively take away most (if not all) Internet
privacy from citizens, blacklisting the Kazakhstan's CAs could be worse than
simply not including it at all.

If we wanted to do better than silent bystanders, maybe it should be considered to introduce a new kind of user interface feedback into Firefox.

For example, we could maintain a list of major CAs that are known to violate best practices. Whenever a certificate from such a CA is enountered, regardless if the user has added the CA as trusted to their configuration, we could have a persistent big notification bar on the top of the browser content, which could say something like "Your connection is believed to be under active surveillance", and disable the usual security indicators.

Kai

[Florian Weimer]

* Jakob Bohm:

> Could they, hypothetically, simply claim to use the real certificate on
> the connection from their MiTM machines to the real server to do
> practical control validation? They would have to claim, also, that
> they are holding the private key of the MiTM certificate "in trust" on
> behalf of the site owners "on whose behalf" the issued the certifiate?
> (Just playing devils advocate).

I think it's similar to what certain CDNs do: They hold the key
material (both long term and session) on behalf of the server
operator. A TLS interception facility holds the session keys on
behalf of the client.

Both parties claim to increase Internet security. Both are probably
right in some ways, and wrong in others.

Florian

[Eric Mill]

Correct me if I'm wrong, but I think Mozilla has only actively distrusted
"publicly trusted" certificates -- certificates that could be used to
intercept traffic from a device with an unmodified root store.

So that includes whenever a publicly trusted CA improperly issues
certificates, which can also include forged certificates like the 2008 MD5
collision attack -- but *doesn't* include certificates issued by
enterprises or other organizations not represented in the trusted root
program, but which Mozilla or its community take moral issue with in some
way. This has seemed like an effective line to draw so far.

-- Eric

[Peter Gutmann]

Kai Engert <ka...@kuix.de> writes:

>Independently of the request for inclusion, this group could discuss if the
>Kazakhstan's CAs should be blacklisted, by adding them to the Mozilla CA list
>using negative distrust flags

That would have some pretty bad consequences. With the MITM CA cert enabled,
Borat [0] can read every Kazakh user's email, but no-one else can. With the
MITM CA blacklisted, Borat can still read every Kazakh user's email, but so
can everyone else on the planet. So the choice is between privacy against
everyone but one party, and privacy against no-one.

Peter.

[0] The personification of the Kazakh CA-enabled MITM, following the pattern
of Alice, Bob, Mallet, etc.

[cub...@gmail.com]

Hi there,

If I may briefly jump in with a small observation regarding the above certs:
in both, the issuer is different from the subject, which is rather unusual.
Isn't that a problem?

Regards,

Sven Faw
@hexatomium

[Kai Engert]

On Sat, 2016-01-09 at 14:11 +0000, Peter Gutmann wrote:
> That would have some pretty bad consequences.  With the MITM CA cert enabled,
> Borat [0] can read every Kazakh user's email, but no-one else can.  With the
> MITM CA blacklisted, Borat can still read every Kazakh user's email, but so
> can everyone else on the planet.  So the choice is between privacy against
> everyone but one party, and privacy against no-one.

I don't understand why blacklisting a MITM CA would enable everyone to read the
data that passes through the MITM. Could you please explain? (It sounds like
there is either a misunderstanding on your or on my side.)

Thanks
Kai

[bkho...@gmail.com]

Correct, this is because the submitted certificate download URL is wrong:

> http://pki.gov.kz/cert/pki_rsa.cer

If you pull this certificate and look at it's AIA, then pull the authoritative certificate from the url:

> openssl x509 -inform der -in pki_rsa.cer -text -noout
> ..
> Authority Information Access:
> CA Issuers - URI:http://root.gov.kz/cert/root_rsa.cer

You can then verify its fingerprint, startdate and enddate match the inclusion request (adjusting for Alma-Ata local time which us UTC+6).

Also no test URL is provided. (https://wiki.mozilla.org/CA:Information_checklist #11).



Brian

[Jakob Bohm]

He is obviously referring to the fact that refusing to encrypt using
the MiTM certificate would force users to access their e-mails (etc.)
using unencrypted connections (plain HTTP, plain IMAP, plain POP3
etc.), thus exposing themselves to wiretapping by parties other than
the government in question.

[Phillip Hallam-Baker]

On Mon, Jan 11, 2016 at 1:45 PM, Jakob Bohm <jb-mo...@wisemo.com> wrote:
> On 09/01/2016 19:22, Kai Engert wrote:
>>

> He is obviously referring to the fact that refusing to encrypt using
> the MiTM certificate would force users to access their e-mails (etc.)
> using unencrypted connections (plain HTTP, plain IMAP, plain POP3
> etc.), thus exposing themselves to wiretapping by parties other than
> the government in question.

That does not concern me. What does concern me is that a user of the
Web believes that their communications are encrypted when they are not.

The browser should break when communication is not possible without
interception by a third party. In this particular case the party has
demonstrated its intention to use the CA to create MITM certificates.
I suggest that as soon as evidence of such certificates is seen, the
CA be blacklisted.

[Jakob Bohm]

On 08/01/2016 23:31, Florian Weimer wrote:
> * Jakob Bohm:
>
>> Could they, hypothetically, simply claim to use the real certificate on
>> the connection from their MiTM machines to the real server to do
>> practical control validation? They would have to claim, also, that
>> they are holding the private key of the MiTM certificate "in trust" on
>> behalf of the site owners "on whose behalf" the issued the certifiate?
>> (Just playing devils advocate).
>
> I think it's similar to what certain CDNs do: They hold the key
> material (both long term and session) on behalf of the server
> operator. A TLS interception facility holds the session keys on
> behalf of the client.

Not quite. CDNs are voluntarily hired by the site owners to
(essentially) provide additional web server computers for the site.
They are (if properly using the site's domain name) not really
different from any other web host.

A Corporate MiTM affecting only itself is not holding anything on
others behalf. It would be morally advisable though for employees
to have a legitimate way to carry out personal communication (such as
arranging doctors appointments) during work breaks or similar. Similar
to a factory (in older times) having a payphone in a hallway.

A nation state MiTM is on the other hand overriding the individual
authority of its citizens and legitimate foreign visitors.

However my (hypothetical) bad argument for a MiTM CA issuing
certificates involve acting on behalf of the (non-consenting) foreign
web site owners to hold private keys that purport to identify the
holder as said foreign site owners (who are in no way subjects of that
state).

>
> Both parties claim to increase Internet security. Both are probably
> right in some ways, and wrong in others.
>
> Florian
>

[Kai Engert]

On Mon, 2016-01-11 at 19:45 +0100, Jakob Bohm wrote:
> He is obviously referring to the fact that refusing to encrypt using
> the MiTM certificate would force users to access their e-mails (etc.)
> using unencrypted connections (plain HTTP, plain IMAP, plain POP3
> etc.), thus exposing themselves to wiretapping by parties other than
> the government in question.

Thanks for the hint!

Nowadays many Internet services no longer offer the choice to connect without
TLS. Many popular sites accessed using http immediately redirect to https.

So, blacklisting the CA would have a mixed effect. Forced plaintext for those
services that still allow plaintext, and blocked connectivity for those that
require TLS (affecting all software that doesn't allow to override blacklisted
certificates, such as Firefox).

Kai

[Peter Gutmann]

Kai Engert <ka...@kuix.de> writes:

>On Sat, 2016-01-09 at 14:11 +0000, Peter Gutmann wrote:
>> That would have some pretty bad consequences. With the MITM CA cert enabled,
>> Borat [0] can read every Kazakh user's email, but no-one else can. With the
>> MITM CA blacklisted, Borat can still read every Kazakh user's email, but so
>> can everyone else on the planet. So the choice is between privacy against
>> everyone but one party, and privacy against no-one.
>
>I don't understand why blacklisting a MITM CA would enable everyone to read
>the data that passes through the MITM. Could you please explain? (It sounds
>like there is either a misunderstanding on your or on my side.)

For the MITM to work, Borat will be proxying all traffic out of (and into) the
country.

If you allow the MITM cert, only Borat/the proxy can read everyone's traffic.

If you disallow the cert and turn off encryption, Borat can still read
everyone's traffic, but so can everyone else on the planet.

The "can't connect to the site without TLS" issue isn't really there either,
Borat will connect using TLS so TLS-only sites will continue to work, it's
only the downstream users who don't get any protection.

Peter.

[Paul Wouters]

On Mon, 11 Jan 2016, Peter Gutmann wrote:

>>> That would have some pretty bad consequences. With the MITM CA cert enabled,
>>> Borat [0] can read every Kazakh user's email, but no-one else can. With the
>>> MITM CA blacklisted, Borat can still read every Kazakh user's email, but so
>>> can everyone else on the planet. So the choice is between privacy against
>>> everyone but one party, and privacy against no-one.
>>
>> I don't understand why blacklisting a MITM CA would enable everyone to read
>> the data that passes through the MITM. Could you please explain? (It sounds
>> like there is either a misunderstanding on your or on my side.)
>
> For the MITM to work, Borat will be proxying all traffic out of (and into) the
> country.
>
> If you allow the MITM cert, only Borat/the proxy can read everyone's traffic.
>
> If you disallow the cert and turn off encryption, Borat can still read
> everyone's traffic, but so can everyone else on the planet.

Who said "turn off encryption"?

> The "can't connect to the site without TLS" issue isn't really there either,
> Borat will connect using TLS so TLS-only sites will continue to work, it's
> only the downstream users who don't get any protection.

Publishing a DNSSEC signed TLSA record would indicate TLS should be on
the connection and which public key to expect. So we'd hope the browser
would hard fail here.

Paul

[Peter Gutmann]

Paul Wouters <pa...@cypherpunks.ca> writes:

>> If you disallow the cert and turn off encryption, Borat can still read
>> everyone's traffic, but so can everyone else on the planet.
>
>Who said "turn off encryption"?

If you don't allow the MITM cert, which is needed to enable encryption in the
browser, you don't get any encryption. Disallowing the MITM cert has the
effect of turning off encryption.

Peter.

[Paul Wouters]

On Mon, 11 Jan 2016, Peter Gutmann wrote:

Or we ensure that firefox and chrome refuses to see those sites at all,
because they refuse a downgrade attack. Let the nation state basically
block all of the sites they want to MITM and see how that works out.

Otherwise, allowing this is just the same as backdoored encryption in
the browser - and it will be coming to a browser or nation state near
us.

Paul

[Peter Gutmann]

Paul Wouters <pa...@cypherpunks.ca> writes:

>Or we ensure that firefox and chrome refuses to see those sites at all,
>because they refuse a downgrade attack.

So users will switch to whatever browser doesn't block it, because given the
choice between connecting to Facebook insecurely or not connecting at all,
about, oh, 100% of users will choose to connect anyway.

>Let the nation state basically block all of the sites they want to MITM and
>see how that works out.

It'll work out just fine for them, because what you're giving users is a
choice between using the Internet and not using it, and close to 100% will
choose to use it no matter what. We've already got real-world stats on that
for several countries, for example 700M Chinese folks use the Internet despite
intrusive government monitoring.

Even if every single browser vendor decides to block (which will never happen,
who's going to consciously cut off their user base like that?), all Borat has
to do is distribute a patched version of whatever browser or browsers they
like and/or distribute a small installer that injects Borat's CA cert, and
everything's fine, with or without the browser vendors' cooperation.

Peter.

[Paul Wouters]

On Tue, 12 Jan 2016, Peter Gutmann wrote:

>> Or we ensure that firefox and chrome refuses to see those sites at all,
>> because they refuse a downgrade attack.
>
> So users will switch to whatever browser doesn't block it, because given the
> choice between connecting to Facebook insecurely or not connecting at all,
> about, oh, 100% of users will choose to connect anyway.

And they'll grab a firefox/chrome from the free world.

> It'll work out just fine for them, because what you're giving users is a
> choice between using the Internet and not using it

Not really. But let's just leave it at that we disagree.

Paul

[Richard Barnes]

On Tue, Jan 12, 2016 at 1:48 AM, Peter Gutmann <pgu...@cs.auckland.ac.nz>

wrote:

> Paul Wouters <pa...@cypherpunks.ca> writes:
>

> >Or we ensure that firefox and chrome refuses to see those sites at all,
> >because they refuse a downgrade attack.
>
> So users will switch to whatever browser doesn't block it, because given
> the
> choice between connecting to Facebook insecurely or not connecting at all,
> about, oh, 100% of users will choose to connect anyway.
>

An appropriate example. May I note that Facebook has lately been turning
off support for non-encrypted users? So regardless of the browser, a user
cannot access Facebook without HTTPS.

In any case, I think this thread is getting pretty far off-topic.

--Richard

>
> >Let the nation state basically block all of the sites they want to MITM
> and
> >see how that works out.
>

> It'll work out just fine for them, because what you're giving users is a

> choice between using the Internet and not using it, and close to 100% will
> choose to use it no matter what. We've already got real-world stats on
> that
> for several countries, for example 700M Chinese folks use the Internet
> despite
> intrusive government monitoring.
>
> Even if every single browser vendor decides to block (which will never
> happen,
> who's going to consciously cut off their user base like that?), all Borat
> has
> to do is distribute a patched version of whatever browser or browsers they
> like and/or distribute a small installer that injects Borat's CA cert, and
> everything's fine, with or without the browser vendors' cooperation.
>
> Peter.

[Phillip Hallam-Baker]

It really isn't a good idea for Mozilla to try to mitigate the
security concerns of people living in a police state. The cost of
doing so is you will set precedents that others demand be respected.

Yes providing crypto with a hole in it will be better than no crypto
at all for the people who don't have access to full strength crypto.
But if you go that route only crypto with a hole will be available.

[Jakob Bohm]

No one (except the MiTM CA itself, possibly) is suggesting that Mozilla
include or authorize any MiTM CA to work in its browsers (or anything
else using the Mozilla CA list).

The discussion is how to *not* authorize it, without thereby causing too
much collateral damage.

Questions being seriously discussed:

- Should Mozilla add specific mechanisms that prevent the subjects of a
police state from obeying police orders to compromise their own
browser? This is the most hotly debated topic in this thread.

- Should Mozilla find a mechanism to allow only the non-MiTM part of a
dual use CA which is being used both as an MiTM CA and as the
legitimate CA for accessing government services, such as transit visa
applications by foreign travelers planning to cross the territory of
the police state on their way somewhere else?

- How to most easily reject requests by the MiTM CAs to become
globally trusted CAs in the Mozilla CA store. Without causing
precedents that would hurt legitimate CAs from countries that happen
not to be allies of the USA. So far, the best suggestion (other than
to stall them on technicalities) is to find an interpretation of the
existing CA rules which cannot be satisfied by any MiTM CA.

[Phillip Hallam-Baker]

On Tue, Jan 12, 2016 at 11:46 AM, Jakob Bohm <jb-mo...@wisemo.com> wrote:
> On 12/01/2016 16:49, Phillip Hallam-Baker wrote:
>>

> No one (except the MiTM CA itself, possibly) is suggesting that Mozilla
> include or authorize any MiTM CA to work in its browsers (or anything else
> using the Mozilla CA list).
>
> The discussion is how to *not* authorize it, without thereby causing too
> much collateral damage.

Yes, that is the issue we should be considering. The issue of
collateral damage isn't just limited to one set of governments though.
Anything we allow a police state, the FBI will demand and of course,
vice versa which is one of the reasons for rejecting the FBI demands.

> Questions being seriously discussed:
>
> - Should Mozilla add specific mechanisms that prevent the subjects of a
> police state from obeying police orders to compromise their own
> browser? This is the most hotly debated topic in this thread.
>
> - Should Mozilla find a mechanism to allow only the non-MiTM part of a
> dual use CA which is being used both as an MiTM CA and as the
> legitimate CA for accessing government services, such as transit visa
> applications by foreign travelers planning to cross the territory of
> the police state on their way somewhere else?
>
> - How to most easily reject requests by the MiTM CAs to become
> globally trusted CAs in the Mozilla CA store. Without causing
> precedents that would hurt legitimate CAs from countries that happen
> not to be allies of the USA. So far, the best suggestion (other than
> to stall them on technicalities) is to find an interpretation of the
> existing CA rules which cannot be satisfied by any MiTM CA.

Not accepting a demand, making clear a demand will never be accepted
is not the same as giving a refusal.

On the other questions, let us return to what the original basis for
the WebPKI was: Process.

There are existing precedents for revoking certificates that are
demonstrated to be malicious. One of the purposes of the CAA extension
was to provide an objective definition of malicious behavior. There
are at least two parties that have infrastructure that is capable of
detecting certificates that violate CAA constraints.

At the moment we don't have a very large number of domains with CAA
records. The more domain name holders we can persuade to deploy CAA,
the sooner an objective default will be detected.

[Eric Mill]

The Mozilla Trusted Root program can and should police violations of the
Mozilla Trusted Root program, and any other fraudulent *publicly trusted*
certificates. That's non-controversial.

Policing violations of more general social norms -- by choosing to actively
distrust non-publicly-trusted certificates -- I wonder how effective that's
going to be at mitigating the threat, and how quickly a less
black-and-white case will arise that will put Mozilla in a much tougher
spot.

Peter Bowen explained earlier how nation-state MITMs inherently violate the
Baseline Requirements:

> I agree 100%. MITM implies that they are not following BR, as there
> is no way they can be validating domain control[1]. This should mean
> that they cannot complete a BR audit without having a massive
> qualification on the report.

And that the only way they could argue otherwise is to say that they have
practical domain control from their nation-level vantage point. That sounds
like an absurd counter-argument to me, but if there's any weakness in the
BRs or Mozilla policies that allows that counter-argument to be non-absurd,
then proposals to make clear in the BRs or Mozilla policies that "domain
control" means something global would be helpful.

-- Eric

On Tue, Jan 12, 2016 at 12:07 PM, Phillip Hallam-Baker <
ph...@hallambaker.com> wrote:

> On Tue, Jan 12, 2016 at 11:46 AM, Jakob Bohm <jb-mo...@wisemo.com>
> wrote:
> > On 12/01/2016 16:49, Phillip Hallam-Baker wrote:
> >>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Kathleen Wilson]

On 1/7/16 12:29 PM, Kathleen Wilson wrote:
>> Until such time that the provide this, I don't see how they are any
>> different from the thousands of private PKIs that are run by companies
>> for their own use. Many of those PKIs may be used to MITM
>> connections.
>
> OK. I suppose that means I should go ahead and start the information
> verification process for this request.
> https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
>
>
>> All CAs should be held to the same standard when asking for admission
>> to the Mozilla program, this is no different.
>
> That's very logical.
> I was sort of hoping to avoid spending the time doing the Information
> Verification if I didn't have to.


Thanks to all of you who are thoughtfully considering this ongoing
discussion about MiTM and Government CAs.

I did go ahead and start the Information Verification for the request to
include the Government of Kazakhstan's root certificate. The following
is copied from a comment I added to the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=1232689#c11
~~
(In reply to Kathleen Wilson from comment #6)
> Created attachment 8705877 [details]
> 1232689-CAInformation.pdf
>
> I have entered the information for this request into Salesforce.
>
> Please review the attached document to make sure it is accurate and
> complete, and comment in this bug to provide corrections and the
additional
> requested information (search for NEED in the attached document)

I would like to point out a few things...

1) The need for the Baseline Requirements (BR) audit is listed in the
attached CA Information document.
Completing a successful BR audit would mean that the auditor ensured the
CA meets the requirements for validating that the certificate subscriber
owns/controls the domain name(s) to be included in the certificate.
(i.e. a BR audit should fail if the CA issues MITM certificates)
Reference: https://cabforum.org/baseline-requirements-documents/

2) All documentation, including the audit statements must be public-facing.

3) This CA might be a super CA. If it is, then we would need to take the
approach described here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs
"Some CAs sign the certificates of subordinate CAs to show that they
have been accredited or licensed by the signing CA. Such signing CAs are
called Super-CAs, and their subordinate CAs must apply for inclusion of
their own certificates..."
~~

Thanks,
Kathleen

[staro...@gmail.com]

Sorry for bumping this old thread, but the Government of Kazakhstan has already started to use the certificate for MITM. Some information in news (on Russian):
https://tengrinews.kz/internet/spetsialnyiy-sertifikat-poprosili-ustanovit-smartfonyi-374216/
https://tengrinews.kz/internet/problemyi-dostupom-internetu-mogut-poyavitsya-astanchan-374068/
https://www.nur.kz/1805169-problemy-s-dostupom-k-internetu-mogut-poavitsa-u-zitelej-nur-sultana.html

Our internet providers via SMS inform us about the need to install this certificate that can be downloaded from their websites:
http://qca.kz
https://www.kcell.kz/ru/product/3585/658
https://www.beeline.kz/almatinskaya-obl/about/press-center/press/news/details/sertifikat-bezopasnosti/

Just to note, this certificate is not the same with the one that was published in this thread. Current one is issued by "Qaznet Trust Network"/"Security Certificate".

At the moment, providers started to use the certificate in the capital of Kazakhstan - Nur-Sultan (ex. Astana).

Did Mozilla have any way to prevent such attacks?

--
Thanks,
Pavel

[Wayne Thayer]

For everyone's reference, here is a link to the old thread:
https://groups.google.com/d/msg/mozilla.dev.security.policy/wnuKAhACo3E/ujxPTWTlCQAJ

To be clear, the Kazakhstan government CA's root inclusion request
referenced in that thread was denied:
https://bugzilla.mozilla.org/show_bug.cgi?id=1232689#c11

However, a bug has been filed proposing to blocklist the current, untrusted
CA certificate being used by the Kazakhstan government:
https://bugzilla.mozilla.org/show_bug.cgi?id=1567114

In reading through the old thread, consensus seemed to be that blocklisting
this CA certificate isn't a good idea.

The old thread mentions the idea of adding a visual indicator to Firefox
when a root that is not included in our default root store is being used.
Somewhat coincidentally, this was added in Firefox 68:
https://bugzilla.mozilla.org/show_bug.cgi?id=1549605

Finally, I'll point out that Firefox implements public key pinning via a
preloaded list of sites, so the reported MITM will fail for those:
https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status

- Wayne

[Wayne Thayer]

On Thu, Jul 18, 2019 at 10:00 AM Ryan Sleevi <ryan....@gmail.com> wrote:

>
> On Thu, Jul 18, 2019 at 12:50 PM Wayne Thayer via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Finally, I'll point out that Firefox implements public key pinning via a
>> preloaded list of sites, so the reported MITM will fail for those:
>>
>> https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status
>
>

> Wayne,
>
> I don't believe this is correct. Locally-installed trust anchors bypass
> pinning, as they're indicators of explicit user action (or coercion) to
> configure. As a consequence, unless the pinning mode is set to 2. Strict
> (which will typically preclude the use of a number of anti-virus products,
> for better or worse), which it is not by default, the MITM will not fail.
> From the Firefox point-of-view, it's completely transparent whether the
> MITM is being done by local security software or a nation-state
>

Yes, I had just realized that - in the default state, pinning in Firefox
will not block this type of MITM.

[Matthew Hardeman]

If the government of Kazakhstan requires interception of TLS as a condition
of access, the real question being asked is whether or not Mozilla products
will tolerate being used in these circumstances.

Your options are to block the certificate, in which case Mozilla products
simply become unusable to those subject to this interception, or not block
the certificate.

I certainly think that Mozilla should not distribute the MiTM root or do
anything special to aid in its installation. I believe policy already
makes clear that NO included root (commercial or government) is allowed for
use in MiTM scenarios and I believe that policy should be held firm.

I do believe that as it is manually installed rather than distributed as a
default that it should continue to override pinning policy.

This is an accepted corporate use case today in certain managed
environments. The dynamic is quite different for an entire people under an
entire government, but the result is the same:

One has to choose whether to continue serving the user despite the adverse
and anti-privacy scenario, or if one simply won't have their products be
any part of that.

Much has been said about the TLS 1.3 design hoping to discourage use cases
like this, but the reality is what I always suspected: some enterprises or
governments actually will spend the money to do full active MiTM
interception.

Let's posit what might happen if Mozilla made their products intentionally
break for this use case.

Further, let's stipulate that every other major browser follows course and
they all blacklist this or any other nation-state interception certificate,
even if manually installed.

Isn't the logical outcome that the nation-state forks one of the
open-source browser projects, patches in their MiTM certificate, and
un-does the blacklisting? I think that's exactly what would happen. The
trouble is, there's no reason to expect that the fork will be maintained or
updated as security issues are discovered and upstream patches are issued.
We wind up with an infrequent release cycle browser being used by all these
users, who in turn get no privacy AND get their machines rooted
disproportionate to the global population.

I do definitely support a persistent UI indicator for MiTM scenarios that
emphasizes on-screen at all times that the session is being protected by a
non-standard certificate and some sort of link to explain MiTM and the
risks.

On Thu, Jul 18, 2019 at 12:04 PM Wayne Thayer via dev-security-policy <

[Andrew]

I agree a persistent indicator is a good idea. From what I understand Firefox does already have an indicator hidden in the site information box that appears when you click the lock icon in the address bar ( https://bugzilla.mozilla.org/show_bug.cgi?id=1549605 ). This should be more visible in my opinion. Maybe add an asterisk next to the lock icon or something.

Beyond that, I also think the work Mozilla is doing with Project Fusion ( https://wiki.mozilla.org/Security/Fusion ) is a good first step towards combating this type of surveillance (to the extent that's even possible given that this is a technological solution to a social problem). I'd also like to suggest that once Tor proxy integration _does_ come to fruition in Firefox, that a button to activate it be added to the "MITM Indicator" mentioned in my previous paragraph. It might also make sense to integrate a more traditional VPN client into Firefox with similar UI nudges for users experiencing government MITM attacks.

[Matthew Hardeman]

Regarding indicators, I agree that it should be more apparent. Perhaps a
dedicated bar that occupies an entire edge-to-edge horizontal area.

I would propose that it might have two distinct messages, as well:

1. A message that an explicitly known MiTM certificate exists in the
certificate chain being relied upon. This would allow for explicit warning
about known MiTM infrastructures and would allow tailoring any "more info"
resource to explicitly call out that it is known that interception is being
performed.

2. A message that indicates that a non-standard certificate chain is being
presented, which might mean corporate interception, private websites within
an organization, etc, etc.

[health...@gmail.com]

I like the idea of a non-closable banner below the URL simply stating "Kazakhstan is spying on you, learn more here <link to more info>".

[gewalo...@gmail.com]

While this is a technical discussion, it's important to note that a decision made here *will* have consequences on real people, which adds an essential moral component.

Kazakhstan is a nation state known for its poor human rights record. Journalists critical of the government have been prosecuted, minorities were attacked with little legal repercussions, and citizens are intimidate for their voting choices. This isn't an issue of casual loss of privacy. Information collected by the government through the use of this certificate will be used to prosecute real people.