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.

[wolfgang...@gmail.com]

I am not a Mozilla developer, nor have I ever been, but I am a user of what I
consider to still be the free Internet.

I have been in scenarios with silent MITM attacks, primarily corporate
environments as has been mentioned on this thread, and I would _greatly_
appreciate visual indication that my communications are using certificates that
chain up to either a non-standard CA, or are not expected for any other reason.

I believe this will lead to the best experience for an end user: don't black
out my Internet, but do leave me with full information so that I can make an
informed decision either way.

Even on corporate hardware I would like at least a notification that this is
happening.

--
Wolf

[troyc...@gmail.com]

On Thursday, July 18, 2019 at 2:39:51 PM UTC-4, Matthew Hardeman wrote:

> 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 like the banner idea, BUT they could fork because of the banner as well.
This same argument (avoid forks for their security) could be used to say
Mozilla shouldn't have the banner.
Then you can walk that all the way to supporting state MITM.

I'm not picking a fight and I don't have a better idea.
I'm just looking at the logic.

[cmal...@gmail.com]

Appeal to the Mozilla Firefox developers
Hello to all!

I'm Software Engineer and citizen of Kazakhstan. This certificate is not implemented to protect users, but for political reasons. Kazakhstan has a dictatorship. This is done specifically to block "politically incorrect content.".

Look this link: https://www.ohchr.org/EN/NewsEvents/Pages/DisplayNews.aspx?NewsID=24691&LangID=E

The installation of this certificate leads to the leakage of personal data, as well as special services of Kazakhstan will be able to selectively block Internet pages. If it is allowed to install this certificate, the authorities will pursue innocent citizens of Kazakhstan for politically motivated reasons.

That's all I wanted to say.

[muc...@wirade.ru]

Well, then users will just get accustomed to seeing this indication on corporate sites and will ignore it.

Regards,
Mucius.

[nus...@gmail.com]

W dniu czwartek, 7 stycznia 2016 00:08:10 UTC+1 użytkownik Paul Wouters napisał:
> 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

Maybe implement 'in browser' proxychains equivalent - where there will be nested HTTP proxies - one TLS connection trusting GOV CA, second tunel over Amazon/Google/MSFT cloud which they can't block without blocking half of the internet + DNS over HTTPS. We can call that "Gateway CA Certificates.." :)

[Troy Cauble]

On Thursday, July 18, 2019 at 8:26:43 PM UTC-4, wolfgan...@gmail.com wrote:

> Even on corporate hardware I would like at least a notification that this is
> happening.

I like the consistency of a reminder in all cases, but this
might lead to corporate policies to use other browsers.

[Matthew Hardeman]

While possible, that seems unlikely. Corporates are, in general, not
trying to hide when this is being done.

In fact, there are lots of good legal liability reasons why they should
want their users to be constantly reminded.

[andrey....@gmail.com]

I am confused. Since when Mozilla is under obligation to provide customized solutions for corporate MITM? IMHO, corporations, if needed, can hire someone else to develop their own forks of Chrome/Firefox to do snooping on HTTPS connections.

In regular browsers, developed by community effort and with public funds, ALL MiTM certificates should be just permanently banned, no?

[saxp...@gmail.com]

I am no expert at these things, so please forgive me if these are elementary or dumb questions.

What is different about this certificate compared to the tools the KZ government already uses to block individual websites and apps?

Doesn’t the KZ government already have the ability to read almost all internet communications already? Will this cert allow them to do something different?

[effs...@yahoo.com]

They can block websites but cant see what you are doing on those websites because connection is encrypted, by forcing everyone to install their certificate they can bypass the encryption.

[Jakob Bohm]

As someone actually running a corporate network, I would like to
emphasize that it is essential that such mechanisms try to clearly
distinguish the 5 common cases (listed by decreasing harmfulness).

1. A known malicious actor is intercepting communication (such as the
nation state here discussed).

2. An unknown actor is intercepting communication (hard to identify
safely, but there are meaningful heuristic tests).

3. A local/site/company network firewall is intercepting communications
for well-defined purposes known to the user, such as blocking virus
downloads, blocking surreptitious access to malicious sites or
scanning all outgoing data for known parts of site secrets (for
example the Coca-Cola company could block all HTTPS posts containing
their famous recipe, or a hospital could block posts of patient
records to unauthorized parties). This case justifies a non-blocking
notification such as a different-color HTTPS icon.

4. An on-device security program, such as a local antivirus, does MitM
for local scanning between the browser and the network. Mozilla could
work with the AV community to have a way to explicitly recognize the
per machine MitM certs of reputable AV vendors (regardless of
political sanctions against some such companies). For example,
browsers could provide a common cross-browser cross-platform API for
passing the decoded traffic to local antivirus products, without each
AV-vendor writing (sometimes unreliable) plugins for each browser
brand and version, while also not requiring browser vendors to write
specific code for each AV product. Maybe the ICAP protocol used for
virus scanning in firewalls, but run against 127.0.0.1 / ::1 (RFC3507
only discusses its use for HTTP filtering, but it was widely used for
scanning content from mail protocols etc. and a lot less for
insertion of advertising which is in the RFC).

5. A site, organization or other non-member CA that issues only non-MitM
certificates according to a user-accepted policy. Those would
typically only issue for domains that request this or are otherwise
closely aligned with the user organization. Such a CA would
(obviously) not be bound by Mozilla or CAB/F policies, but may need to
do some specific token gestures to programmatically clarify their
harmlessness, such as not issuing certs for browser pinned domains,
only issue for domains listing them in CAA records or outside public
DNS or similar.

I am aware of at least one system being overly alarmist about our
internal type 5 situation, making it impossible to distinguish from a
type 1 or 2 attack situation.

[Jakob Bohm]

On 19/07/2019 21:13, andrey....@gmail.com wrote:
> I am confused. Since when Mozilla is under obligation to provide customized solutions for corporate MITM? IMHO, corporations, if needed, can hire someone else to develop their own forks of Chrome/Firefox to do snooping on HTTPS connections.
>
> In regular browsers, developed by community effort and with public funds, ALL MiTM certificates should be just permanently banned, no?
>

As others (and I) have mentioned, MitM is also how many ordinary
antivirus programs protect users from attacks. The hard part is
how to distinguish between malicious and user-helping systems.

[andrey....@gmail.com]

> As others (and I) have mentioned, MitM is also how many ordinary
> antivirus programs protect users from attacks. The hard part is
> how to distinguish between malicious and user-helping systems.

Sure, but the question is whether MiTM have reasonable security use cases for ordinary users. If you download a file through https, antivirus can scan it as a file. If somebody is concerned about malicious Flash banners on https webpage, he/she should install an adblock. Allowing MiTM is such a security breach, that I doubt it can be that easily justified. For ordinary users, that is.

[dav...@gmail.com]

Wouldn't it be easier to just decree that HTTPS is illegal and block all outbound 443 (only plain-text readable comms are allowed)? Then you would not have the decrypt-encrypt/decrypt-encrypt slowdown from the MITM.

If you don't want to make everyone install a certificate:
Issue a double-wildcard certificate (*.*) that can impersonate any site, load it on a BlueCoat system, and sell it to a repressive regime:
https://www.dailydot.com/news/blue-coat-syria-iran-spying-software/

Both scenarios end up in the same place: Nobody trusts encryption/SSL or CAs anymore.

[My1]

Hello everyone,

I am new here but also want to share my opinion about some posts here, I know it's a lot of text but I hope it's not too bad.

Am Freitag, 19. Juli 2019 23:42:47 UTC+2 schrieb dav...@gmail.com:
> Wouldn't it be easier to just decree that HTTPS is illegal and block all outbound 443 (only plain-text readable comms are allowed)? Then you would not have the decrypt-encrypt/decrypt-encrypt slowdown from the MITM.

if you want to block like half the internet or more which is on the way of HTTPS-only, go ahead.

> If you don't want to make everyone install a certificate:
> Issue a double-wildcard certificate (*.*) that can impersonate any site, load it on a BlueCoat system, and sell it to a repressive regime:
> https://www.dailydot.com/news/blue-coat-syria-iran-spying-software/
>
> Both scenarios end up in the same place: Nobody trusts encryption/SSL or CAs anymore.

As far as I remember, certs only allow one wildcard and that only on the very left so they would need at least *.tld and *.common-sub.tld for all eTLDs (*.jp doesnt cover *.co.jp).

Also, you say that this is for not wanting everyone to install a certificate. which Trusted CA in their right mind would actually do this? CT is becoming FAR bigger as time goes on and if any CA is catched going and issuing wildcards for public suffixes, that CA would be dead instantly.

Also browsers could just drop certificates with *.(public-suffix) entirely and not trust them, no matter the source.

> On Friday, July 19, 2019 at 1:27:17 PM UTC-7, Jakob Bohm wrote:

> > On 19/07/2019 21:13, andrey...@gmail.com wrote:
> > > I am confused. Since when Mozilla is under obligation to provide customized solutions for corporate MITM? IMHO, corporations, if needed, can hire someone else to develop their own forks of Chrome/Firefox to do snooping on HTTPS connections.
> > >
> > > In regular browsers, developed by community effort and with public funds, ALL MiTM certificates should be just permanently banned, no?
> > >
> >
> > As others (and I) have mentioned, MitM is also how many ordinary
> > antivirus programs protect users from attacks. The hard part is
> > how to distinguish between malicious and user-helping systems.

I fully agree that this is hard but one also needs to be aware that antiviruses while not unhelpful also provide risks by being VERY deep in the system. an unmonitored MITM action by that could end in disastrous results, in the worst case bank phishing could occur since the user cannot verify the certificate via the browser.

one suggestion I think might be helpful is to have the entire data available, while keeping the HTTPS signature, and there could be a machanism that allows anti-virus software to check content before it is executed/loaded and if needed, put a big "do not execute" flag for certain things like script blocks that are clearly malicious or whatever, and the browser can check the signature that no content has been actually changed, but remove that flagged content, while displaying a notification that content has been blocked.

that way anti-viruses could only remove elements but not actually change anything.

let me go over each of your situations and what I think of those:
1) obviously needs a VERY clear warning including the specific information about the actor like who is the interceptor
2) similar to 1 but obviously it cannot have the specific information that is known about a, well, known actor.

3 and 4 are similar but there should be a "lesser" click-through warning that just informs the user for example once per session that he is on watch (because while these things can filter bad stuff, they can also read sensitive inputs like passwords), while the cert if it can be retrieved from a "trusted" source, for example the active directory, while 4 shouldnt be using classic MITM scenarios at all, see my idea above.

I don't know how or even whether or not it is possible to have one client prove to another that site X actually came in via HTTPS and was signed using X, because of all the ephemeral keys and everything, but that way a proxy could be made that securely transmits data from websites to the client, while also flagging content that should not be touched. obviously with a notification if any of these flags occur.

5) is a fairly valid case and in my opinion DANE is a decent way to deal with that, only the browsers need to play along.


the only problem with your idea of categorizing these issues is how to differentiate 3 and 4 from 2.

in the classic MITM style scenario anything could have installed the MITM CA and in case of 4 the private key is even on that computer. a field day for malware. there would need to be a verifiable source for the MITM CA, to not be seen as 2.

for case 4 at least one could make it much less ugly by only transmitting recieved data to the software while inputs stay secret, but in case 3 where we want to scan and filter inputs, this is obviously not possible.


Regards,
My1

[peri...@dsmouse.com]

It would allow people who are using VPNs and other alternative access strategies to realize that they forgot to turn it on/etc

[sim...@gmail.com]

I think it must be quickly blacklisted by Google, Mozilla and Microsoft all together, because it is known as a state scale MITM affecting citizen "real" life.

The purpose of https is being defeated and such companies who tried to improve network security for past decade have to react (yes, security and privacy on which they work on are political).
If browser editors do blacklist, citizen will be able to rise against this privacy attack.

PS:When a MITM CA is known to be at a company scale, it is not that harmfull imho because citizen still have privacy at home.

[My1]

but the obvious question is what will happen then? force a custom browser upon the users which has this change negated but probably wont get any security updates?

Don't get me wrong, this cert needs to be stopped, but this thing is generally not easy. although if operating systems start to block these at system level, then it would be quite a bit harder to enforce such a cert since it isnt as easy to get users to change the entire OS, especially when you cannot just modify windows that easily and if windows software is needed, then the gov would shoot itself in the foot quite a bit, when people cannot work anymore because of this. and especially on iOS which you cannot just quickly replace with something else has quite a big impact potential depending on how large their market share over there is.

[Jakob Bohm]

Note that on a technical level, there is no difference between a (small)
company and a home (employees versus family members).

A small company to consider would be doctor or lawyer office, handling
other people's deepest secrets and under an obligation of secrecy from
even the authorities.

A large home to consider could be 4 generations living together, with
8 to 10 children and 4 spouses for each in each generation, but in
relative poverty.

[Jakob Bohm]

On 21/07/2019 03:21, My1 wrote:
> Hello everyone,
>
> I am new here but also want to share my opinion about some posts here, I know it's a lot of text but I hope it's not too bad.
>
> Am Freitag, 19. Juli 2019 23:42:47 UTC+2 schrieb dav...@gmail.com:
>> Wouldn't it be easier to just decree that HTTPS is illegal and block all outbound 443 (only plain-text readable comms are allowed)? Then you would not have the decrypt-encrypt/decrypt-encrypt slowdown from the MITM.
>
> if you want to block like half the internet or more which is on the way of HTTPS-only, go ahead.
>
>> If you don't want to make everyone install a certificate:
>> Issue a double-wildcard certificate (*.*) that can impersonate any site, load it on a BlueCoat system, and sell it to a repressive regime:
>> https://www.dailydot.com/news/blue-coat-syria-iran-spying-software/
>>
>> Both scenarios end up in the same place: Nobody trusts encryption/SSL or CAs anymore.
>
> As far as I remember, certs only allow one wildcard and that only on the very left so they would need at least *.tld and *.common-sub.tld for all eTLDs (*.jp doesnt cover *.co.jp).
>
> Also, you say that this is for not wanting everyone to install a certificate. which Trusted CA in their right mind would actually do this? CT is becoming FAR bigger as time goes on and if any CA is catched going and issuing wildcards for public suffixes, that CA would be dead instantly.
>
> Also browsers could just drop certificates with *.(public-suffix) entirely and not trust them, no matter the source.
>

I believe this is either done, or easy to add.

>
>> On Friday, July 19, 2019 at 1:27:17 PM UTC-7, Jakob Bohm wrote:
>>> On 19/07/2019 21:13, andrey...@gmail.com wrote:
>>>> I am confused. Since when Mozilla is under obligation to provide customized solutions for corporate MITM? IMHO, corporations, if needed, can hire someone else to develop their own forks of Chrome/Firefox to do snooping on HTTPS connections.
>>>>
>>>> In regular browsers, developed by community effort and with public funds, ALL MiTM certificates should be just permanently banned, no?
>>>>
>>>
>>> As others (and I) have mentioned, MitM is also how many ordinary
>>> antivirus programs protect users from attacks. The hard part is
>>> how to distinguish between malicious and user-helping systems.
>
> I fully agree that this is hard but one also needs to be aware that antiviruses while not unhelpful also provide risks by being VERY deep in the system. an unmonitored MITM action by that could end in disastrous results, in the worst case bank phishing could occur since the user cannot verify the certificate via the browser.
>

Hence my breakdown and suggestions below, which seem to agree with yours
in most cases.

As for on-machine antivirus, hence my suggestion to locally (on
machine) use a protocol already implemented for corporate users by the
larger antivirus companies (ICAP).

There are legitimate security programs that remove certain received
data, such as removing embedded loads of government pushed tracking
beacons.

Similar, many higher end personal security packages have features
to prevent the less experienced family members from revealing their
home address or other such details to physically dangerous people,
the appropriateness of such features should be a family decision,
not a browser decision.

However there should be browser settings to choose the level of
scanning entrusted to each local scanner (scan post yes/no,
scan file upload yes/no, modify post/upload data yes/no,
scan URLs yes/no, modify server replies yes/no).

> I don't know how or even whether or not it is possible to have one client prove to another that site X actually came in via HTTPS and was signed using X, because of all the ephemeral keys and everything, but that way a proxy could be made that securely transmits data from websites to the client, while also flagging content that should not be touched. obviously with a notification if any of these flags occur.
>
> 5) is a fairly valid case and in my opinion DANE is a decent way to deal with that, only the browsers need to play along.
>

DANE has some unfortunately implementation difficulties, mostly
inherited from DNSSEC. It would be unfortunate to limit home or
company internal systems to mechanisms essentially different
from how the same job is done elsewhere, especially for testing
stuff.

Ways to recognize type 5 scenarios could include (with combinations
occurring in any one situation) could be:

- DNS names in the guaranteed non-public TLDs: .local, .lan, .example,
.invalid etc.

- DNS names outside all TLDs listed in the public suffix list included
with the browsers. (for example .somefamilynickname).

- DNS names at least 2 levels below public suffixes and not existing
on DNS in the public Internet. Need someone highly trusted to check
this without revealing the probed DNS names widely. (For example
internal.example.com with .com being the public suffix and the
example.com DNS servers controlled by the home/company).

- IPv4 addresses from the RFC1918 and 127.x.x.x ranges of LAN IPs (in IP
subject-alt-names).

- IPv6 addresses from the ranges similarly reserved for non-public use.

- CAA record somehow matching the private CA and not any of the browser-
bundled CAs.

- e-mail certificates will be harder to separate as public e-mail certs
are kind of unpopular except government citizen CA schemes.

>
> the only problem with your idea of categorizing these issues is how to differentiate 3 and 4 from 2.

Indeed, hence the need for heuristics and countermeasures.

#3 would probably become a #2 warning in all but the most strictly
identifiable cases.

#4 could be transitioned to a cross-vendor AV API, such as ICAP to
localhost or a plugin API much simpler than NPAPI.

>
> in the classic MITM style scenario anything could have installed the MITM CA and in case of 4 the private key is even on that computer. a field day for malware. there would need to be a verifiable source for the MITM CA, to not be seen as 2.
>
> for case 4 at least one could make it much less ugly by only transmitting recieved data to the software while inputs stay secret, but in case 3 where we want to scan and filter inputs, this is obviously not possible.
>
>

[h]

Hello, i'm from Kazakhstan and asking you to ban this certificate. The only reason it's applied are political. The government will force everyone to apply it if it will not be banned. Right now in Kazakhstan thousands of people who a repressed for political views, even mothers are sitting in prisons for expressing their Constituion rights. All real opposition in Kazakshtan are declared as extrimists when by Europian Parliament it is not http://www.europarl.europa.eu/doceo/document/B-8-2019-0207_EN.html
Right now people who are against dictatorship in Kazakhstan could organize only via internet. Hope you understand that accepting this certificate even with notifications will lead to thousands of other repressed people and even totally prevent democracy in Kazakhstan. Maybe i'm incorrect in some technical details, sorry if i am. Hope for you reasoning and making right choice.

[qm3...@gmail.com]

If Kazakhstan MITM certificates could be swiftly banned by all major browsers, it might roll back the requirement (just as it failed in 2016) by paralyzing work.
It is also more likely to cause political action and people learning more about the impact of this "policy".

Governments are very slow, and just forking this out would take them months, at which point it's possible to return to the status quo (with extra banners) to mitigate the use of the inferior fork.

So, socially, this seems like the best course of action, if it can be quickly coordinated.



The real issue is that they can quickly block update servers + instruct the population to disable updates. Which means that banners won't make it through, and the population will stay on today's versions permanently.

[Corey Bonnell]

I don’t think a persistent visual indicator on the browser chrome is a terribly effective solution, for two reasons:

1) This warning will presumably be displayed all the time when the MITM root is installed and browsing from a Kazakh ISP. There’s nothing actionable that the user can do except remove the MITM root (and break your Internet connection, more or less) or leave the country, so it becomes a nag warning. This warning will merely induce warning fatigue for the user, so when another attacker attempts to MITM a connection (perhaps to steal financial information) or otherwise encounters certificate validation errors, the user will be desensitized to these warning messages and click right through the warning interstitial.
2) By the time the persistent visual indicator is displayed, significant damage has already been done, as the browser has completed the intercepted HTTPS connection and sent their HTTP session state (cookies, etc.) to the attacker. This damage is greatly compounded if the user accesses the Internet from a non-Kazakh ISP to visit (or login to) websites that the government disapproves of. When the user returns to using the Kazakh ISP, their previous login sessions that were first established externally will have their session state data (session cookies, etc.) sent to the government, so the government can engage in session fixation attacks or otherwise leverage this information. A persistent visual indicator would not help at all in this scenario.

I was originally thinking that as an alternative to the persistent visual indicator, perhaps some blacklist of known MITM CA certificates can be created and content specific to each certificate explaining the risks of installing each certificate could be displayed in response to the user selecting the CA certificate to be added to the trust store. The user could then see the risks of installing the certificate and make a better-informed choice on whether to proceed with the installation. However, I don’t think this is a very effective solution either, as it requires that the user understand this information despite it being contrary to what the government is directing them to do, so it would merely serve to confuse a lot of users.

I think the optimal solution in terms of user security is to create a blacklist of known MITM CA public keys and simply prevent the installation of certificates containing these public keys in the trust store. If several browsers could coordinate on such an effort, then perhaps that would pressure the government to back down on their demand to intercept TLS communications because their root is would be incompatible with major browsers.

Thanks,
Corey

[jfb...@gmail.com]

On Monday, July 22, 2019 at 7:08:19 PM UTC-4, qm3...@gmail.com wrote:
> The real issue is that they can quickly block update servers + instruct the population to disable updates. Which means that banners won't make it through, and the population will stay on today's versions permanently.

Hello Mozilla. I stumbled upon this thread from a news article.

Yes, that means you will need to be faster than them, instead of dawdling. If they are only blocking HTTPS without the certificate, surely you can have updates delivered over HTTP, and you can check the code signature or whatnot. At least, quickly make an update that vastly increases the number of places it requests an update from. If it's signed you don't even need to control the mirrors.

You aren't going to be able to find a permanent mathematical solution. It's going to be whack-a-mole. But if you do nothing while you can do something, you'll have to sleep with that for a long, long time..

[Han Yuwei]

在 2016年1月7日星期四 UTC+8上午7:08:10，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

Adding banner is a acceptable action to hint this kind of attacking.
Banning this CA can't solve any problem, because KZ ISP can just block any TLS connections. But maybe we can let websites choose which CA they would use just like HSTS.

[Matthew Hardeman]

On Mon, Jul 22, 2019 at 9:20 PM Corey Bonnell via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> I think the optimal solution in terms of user security is to create a
> blacklist of known MITM CA public keys and simply prevent the installation
> of certificates containing these public keys in the trust store. If several
> browsers could coordinate on such an effort, then perhaps that would
> pressure the government to back down on their demand to intercept TLS
> communications because their root is would be incompatible with major
> browsers.
>

It is an interesting question. It essentially becomes a gamble on whether
they'll back down or just fork their own KazakhFox. But if they do push
this all the way with a national browser, then their people are even
further worse off.

[whateverus...@gmail.com]

On Tuesday, July 23, 2019 at 7:34:11 AM UTC+4, Matthew Hardeman wrote:

> It is an interesting question. It essentially becomes a gamble on whether
> they'll back down or just fork their own KazakhFox. But if they do push
> this all the way with a national browser, then their people are even
> further worse off.

Pardon my broken English. I will be referring to "totalitarian governments" in general, not naming a specific country (countries) to be one.

I plea that doing nothing or implementing an easily dismissable warning will be an equivalent of a green light for mass-scale government-sanctioned MiTMs and further political persecutions based on the collected data. While a ban of the CA will be a warning for any totalitarian state that such measures have a hidden cost and complications that they are not ready to take - even if they will make a "TruthFox" and it will turn out to be less secure, the only added risk on top of it will be a slight increase of a chance of a trojan infection.

We know that MiTM is not just blocking access - MiTM also means collection of information. Between staying free/alive and a not working hard drive (or loss of personal data/money that is not comparable to a lengthy prison sentence with a criminal record or a *loss of life*) everyone will chose the first, not the second - ergo, the end user will be harmed more if no action/insufficient action is taken.

With all due respect, all theoretical measures that a totalitarian government might take to negate CA ban in all major browsers will require them to spent *even more resources* and complicate the spying process even further. Speaking generally, corrupt governments like to spent resources "on security", but will become rather stingy when it will turn out that a significant sum of money will be spent out of their pockets. In turn, it will lead to pushing all of the support on third parties while increasing the levels of corruption, miscommunication, non-compliance and etc., breaking the process down and postponing it/cancelling it entirely. Since all of that can not be done instantly, all of this will happen on the background of increasing civil unrest, where the totalitarian government's actions will be to blame to "messing with the internet" and the suffering from it commercial sector will be very active in lobbying for the repeal of the law.

I believe that the Russian anti-blogger law of 2014 has practically fallen apart in 2017 exactly due to a non-compliance of foreign parties and a feeble implementation in general - such a thing wouldn't happen if major social platforms didn't treat it as a slight and easily ignorable nuisance.

I ask everyone opposing taking drastic measures to reconsider - it's not the time to worry about the market share of the browser, comparing it to legitimate activities of a commercial sector or thinking of all theoretical ways the government might defeat the taken measures. Today is Kazakhstan, tomorrow - Russia (I believe we almost did the similar thing too, but it was thrown away due to encryption licensing complications - don't quote me on that, I haven't checked updates on this topic), the day after it might be your country (remember all proposals (or even the accepted laws) against encryption in major Western countries). Even little "sticks in the wheel" help and warn everybody else against doing the same.

[nyx...@gmail.com]

On Wednesday, January 6, 2016 at 5:08:10 PM UTC-6, Paul Wouters wrote:
> 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

Coordinated blacklisting. We shouldn't incentivize this kind of behavior.

[jfb...@gmail.com]

The government sending out SMSes to tell users to install the certificate don't (until the certificate is installed) know what browser the user is using.

So, in addition to blacklisting the certificate, have it pop up a big, horrible message "Your government wants to use this to spy on you. It does not actually increase your security." complete with refutations for all counter-arguments.

In this dialog, it might not hurt to also check the Windows certificate store and offer to remove it if the user would so desire.

If only 10% of the populace hears what's going on directly, that gets the word out a whole lot better than 0%. People talk. It might be enough to get them to stop. *Because* they don't *yet* know which browser. Nobody wants to be sending out "Hey, install this so you can immediately be told about my corruption!" to their entire populace.

[Matthew Hardeman]

This is not at all a safe assumption. If they care to know and have active
MITM infrastructure in place, the last time I looked at the issue,
identifying which browser was in use (and generally speaking which
operating system or set of operating systems) was fairly trivial by
fingerprinting the characteristics of the TLS negotiation.

On Wed, Jul 24, 2019 at 11:43 AM jfb1776--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> The government sending out SMSes to tell users to install the certificate
> don't (until the certificate is installed) know what browser the user is
> using.
>

> ....

[bay...@gmail.com]

On Friday, July 19, 2019 at 10:53:16 AM UTC-5, Matthew Hardeman wrote:
> While possible, that seems unlikely. Corporates are, in general, not
> trying to hide when this is being done.
>
> In fact, there are lots of good legal liability reasons why they should
> want their users to be constantly reminded.

FWIW, we had folks who make TLS interceptors *explicitly* ask us for this notification/display capability in Internet Explorer circa 2009 because they had customers in regulatory environments (aka Europe) where there's a specific legal requirement that users be notified when their connections are being monitored, and it was felt that indicating this plainly in the browser's security UX was a natural place to do it. (We did not, ultimately, deliver on such a feature).

[sedri...@gmail.com]

четверг, 7 января 2016 г., 4:08:10 UTC+5 пользователь 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

I believe there's no need to be aggressive or political in this matter. This is a very technical question. Imposed self-issued certificates are a threat to user's privacy. But there's other side of the question. Looking from the outside, the whole country becomes somewhat toxic to entire Internet infrastructure. If there's definite possibility that all traffic from this country might be forged, re-encrypted or otherwise modified, it poses a threat to a whole bunch of Internet services (actually, all of them), such as social media, business resources and so on, because they have no knowing who they are dealing with - real user or his forged identity. To mention only one example, it makes KYC procedures highly problematic - there might be no sane way to perform them in this case.
Critical business services, such as cloud providers (Amazon, Google, Microsoft and so on), are also in danger as there's no more certainty who's using their services. Not to mention infinite possibilities for bots and troll factories in this case (social media are in the same danger).
So I believe that Mozilla has to considerate both sides of the question: 1) User's privacy and 2) Global security of Internet (imagine totally plausible option of certificate's private keys leaked to some anonymous hackers). And blacklist this and all other possible initiatives of Kazakhstan government.

P.S. Just to clarify on the level of usual governmental security procedures in this country (as I am a citizen of a mentioned state). Until recent time when you had your governmental digital signature issued (which is used to sign documents on governmental sites such as egov.kz), passphrase was limited to 8 symbols. You were not allowed to have more than 8 symbols in your passphrase! Recently their lifted this prohibition, though. So I wouldn't trust them such complex things as cryptography and security.

Ivan

[vto...@googlemail.com]

* whatever the legislation of a sovereign state it can hardly be a browser's remit to govern the state's citizen by hard coding a block, preventing those not participating in this panel discussion to install the certificate(s) if they would desire to do so (for whatever reason that may be and that may seem inexplicable/controversial to anyone petitioning for a hard coded block)
* whether the relatively few opinions, compared to the electorate of a state, in this panel discussion are (a) representative (majority) of said electorate is debatable
* if this becomes a test case for defying the legislation of a sovereign state and a hard coded block is elected then it will have to be replicated so without bias for any other state that aspires a similar measure, regardless of such state's state of domestic affairs. Else it would taint the renown instilled in the trust lender (certificate store)
* are there any such petitions made to other vendors, or panel discussions held with such vendors, that provide certificate stores, such as Google, Apple, Microsoft?
* what would be the measurable impact in terms of users if only Mozilla implements a hard coded block?
* and if this discussion is meant to put a spotlight on MitM (at least the the topic's subject would imply as such and if not then please pardon/ignore the digression) as well then perhaps consider that the majority of users is blisfully unaware when their TLS connections are being termniated (decrypted) midair whilst reaching a host that is being served through reverse proxy providers (cue SNI). Here the remote host allows the reverse proxy to decrypt the traffic at its edge server and thus all the traffic is accessible in the clear to the reverse proxy provider (MitM). Whether the intentions of a reverse proxy provider are more sublime than a state probably lies in the eye of the beholder and likely vary as much.

[RS Tyler Schroder]

News reports[1][2] are now showing that the certificate has been "cancelled". I do not have a way to verify that it has been revoked independently at this time.

Sources:
[1] https://tsarka.org/post/national-certificate-cancelled
[2] https://www.reuters.com/article/us-kazakhstan-internet-surveillance/kazakhstan-halts-introduction-of-internet-surveillance-system-idUSKCN1UX0VD

[Wayne Thayer]

Mozilla has announced our response to the Kazakhstan MITM:
https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/
and
https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/

Note: we're in the process of adding the "Qaznet" root certificate to
OneCRL, but you won't yet find it to be revoked.

- Wayne

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

[Wayne Thayer]

(resending because the first attempt was not posted to the list)

Mozilla has announced our response to the Kazakhstan MITM:
https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/
and
https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/

Note: we're in the process of adding the "Qaznet" root certificate to
OneCRL, but you won't yet find it to be revoked.