Re: Nation State MITM CA's ?

2016-01-08 Thread Phillip Hallam-Baker
On Thu, Jan 7, 2016 at 2:00 PM, Kathleen Wilson  wrote:
> On 1/6/16 3:07 PM, 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
>
>
>
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Nation State MITM CA's ?

2016-01-08 Thread 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Nation State MITM CA's ?

2016-01-08 Thread 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy