Re: Nation State MITM CA's ?

[Wayne Thayer via dev-security-policy]

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

On Wed, Aug 7, 2019 at 8:24 AM RS Tyler Schroder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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

[Wayne Thayer via dev-security-policy]

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

On Wed, Aug 7, 2019 at 8:24 AM RS Tyler Schroder via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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

[RS Tyler Schroder via dev-security-policy]

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
___
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 ?

[vtolkm--- via dev-security-policy]

* 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.
___
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 ?

[sedric2008--- via dev-security-policy]

четверг, 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
___
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 ?

[bayden--- via dev-security-policy]

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).
___
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 ?

[Matthew Hardeman via dev-security-policy]

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-security-policy@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.
>
> 
>
> 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.
>
___
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 ?

[jfb1776--- via dev-security-policy]

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

[nyxtom--- via dev-security-policy]

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

[whateverusernameforme--- via dev-security-policy]

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

[jfb1776--- via dev-security-policy]

On Monday, July 22, 2019 at 11:34:11 PM 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.

You could auto-update everyone in .kz to Tor.
___
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 ?

[Matthew Hardeman via dev-security-policy]

On Mon, Jul 22, 2019 at 9:20 PM Corey Bonnell via dev-security-policy <
dev-security-policy@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.
___
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 ?

[jfb1776--- via dev-security-policy]

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

[Corey Bonnell via dev-security-policy]

On Thursday, July 18, 2019 at 3:42:00 PM UTC-4, Matthew Hardeman wrote:
> 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.
> 
> On Thu, Jul 18, 2019 at 2:11 PM Andrew via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > 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.
> >
> >

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
___
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 ?

[qm3ster--- via dev-security-policy]

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

[h via dev-security-policy]

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

[Jakob Bohm via dev-security-policy]

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.


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.



Am Freitag, 19. Juli 2019 22:23:00 UTC+2 schrieb 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

Re: Nation State MITM CA's ?

[Jakob Bohm via dev-security-policy]

On 20/07/2019 09:31, simc...@gmail.com wrote:

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.



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.

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

Re: Nation State MITM CA's ?

[My1 via dev-security-policy]

Am Sonntag, 21. Juli 2019 03:31:03 UTC+2 schrieb 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.

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

[simchat--- via dev-security-policy]

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

[peridiane--- via dev-security-policy]

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

On Friday, July 19, 2019 at 11:26:43 AM UTC-4, muc...@wirade.ru wrote:
> Well, then users will just get accustomed to seeing this indication on 
> corporate sites and will ignore it.
> 
> Regards,
> Mucius.
> 
___
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 ?

[My1 via dev-security-policy]

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.



Am Freitag, 19. Juli 2019 22:23:00 UTC+2 schrieb 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 

Re: Nation State MITM CA's ?

[davras--- via dev-security-policy]

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.

On Friday, July 19, 2019 at 1:27:17 PM UTC-7, Jakob Bohm wrote:
> On 19/07/2019 21:13, andrey.at.as...@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.
> 
> 
> 
> 
> 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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Nation State MITM CA's ?

[andrey.at.astro--- via dev-security-policy]

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

[Jakob Bohm via dev-security-policy]

On 19/07/2019 21:13, andrey.at.as...@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.




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

Re: Nation State MITM CA's ?

[Jakob Bohm via dev-security-policy]

On 19/07/2019 16:52, Troy Cauble wrote:

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.



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.



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

Re: Nation State MITM CA's ?

[effsfd32f--- via dev-security-policy]

Dana petak, 19. srpnja 2019. u 21:25:05 UTC+2, korisnik saxp...@gmail.com 
napisao je:
> 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?



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

[saxplaya--- via dev-security-policy]

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?
___
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 ?

[andrey.at.astro--- via dev-security-policy]

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?
___
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 ?

[Matthew Hardeman via dev-security-policy]

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.

On Fri, Jul 19, 2019 at 10:27 AM Troy Cauble via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I like the consistency of a reminder in all cases, but this
> might lead to corporate policies to use other browsers.
>
___
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 ?

[Troy Cauble via dev-security-policy]

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

[nusch88--- via dev-security-policy]

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.." :)
___
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 ?

[mucius--- via dev-security-policy]

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

Regards,
Mucius.


On Friday, July 19, 2019 at 3:26:43 AM UTC+3, wolfgan...@gmail.com wrote:
> 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

___
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 ?

[cmalikz.h--- via dev-security-policy]

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=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.
___
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 ?

[troycauble--- via dev-security-policy]

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

[wolfgang.richter--- via dev-security-policy]

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
___
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 ?

[gewalopdrbat--- via dev-security-policy]

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

[healthyelijah--- via dev-security-policy]

On Thursday, July 18, 2019 at 12:42:00 PM UTC-7, Matthew Hardeman wrote:
> 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.
> 
> On Thu, Jul 18, 2019 at 2:11 PM Andrew via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > 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.
> >
> >

I like the idea of a non-closable banner below the URL simply stating 
"Kazakhstan is spying on you, learn more here ". 
___
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 ?

[Matthew Hardeman via dev-security-policy]

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.

On Thu, Jul 18, 2019 at 2:11 PM Andrew via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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

[Andrew via dev-security-policy]

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

[Matthew Hardeman via dev-security-policy]

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 <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Jul 18, 2019 at 10:00 AM Ryan Sleevi 
> wrote:
>
> >
> > On Thu, Jul 18, 2019 at 12:50 PM Wayne Thayer via dev-security-policy <
> > dev-security-policy@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.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
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 ?

[Wayne Thayer via dev-security-policy]

On Thu, Jul 18, 2019 at 10:00 AM Ryan Sleevi  wrote:

>
> On Thu, Jul 18, 2019 at 12:50 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@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.
___
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 ?

[Wayne Thayer via dev-security-policy]

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



On Thu, Jul 18, 2019 at 8:55 AM starosekpd--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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

[starosekpd--- via dev-security-policy]

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
___
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 ?

[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

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

RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

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

Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

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

Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

[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 
> wrote:
> > On 12/01/2016 16:49, Phillip Hallam-Baker wrote:
> >>
> >> 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.
> >>
> >
> > 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.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

[Phillip Hallam-Baker]

On Tue, Jan 12, 2016 at 11:46 AM, Jakob Bohm  wrote:
> On 12/01/2016 16:49, Phillip Hallam-Baker wrote:
>>
>> 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.
>>
>
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

[Peter Gutmann]

Paul Wouters  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Nation State MITM CA's ?

[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

___
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 ?

[bkhowson]

On Saturday, January 9, 2016 at 11:24:31 AM UTC-5, cub...@gmail.com wrote:
> On Thursday, January 7, 2016 at 12:08:10 AM UTC+1, 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
> 
> 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


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


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

Re: [FORGED] Re: Nation State MITM CA's ?

[Phillip Hallam-Baker]

On Mon, Jan 11, 2016 at 1:45 PM, Jakob Bohm  wrote:
> On 09/01/2016 19:22, Kai Engert wrote:
>>
>> On Sat, 2016-01-09 at 14:11 +, 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.)
>>
>
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Nation State MITM CA's ?

[Jakob Bohm]

On 09/01/2016 19:22, Kai Engert wrote:

On Sat, 2016-01-09 at 14:11 +, 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.)




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.

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

Re: Nation State MITM CA's ?

[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




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

RE: [FORGED] Re: Nation State MITM CA's ?

[Peter Gutmann]

Kai Engert  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Nation State MITM CA's ?

[Kai Engert]

On Sat, 2016-01-09 at 14:11 +, 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

___
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 ?

[cubaguy]

On Thursday, January 7, 2016 at 12:08:10 AM UTC+1, 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

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
___
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 ?

[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 ?

[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 ?

[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

Re: Nation State MITM CA's ?

[Peter Bowen]

On Thu, Jan 7, 2016 at 2:34 PM, David E. Ross  wrote:
> On 1/7/2016 12:29 PM, Kathleen Wilson wrote:
>> On 1/7/16 11:15 AM, Peter Bowen 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.
>>
>> Kathleen
>>
>
> 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.
___
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 ?

[Kathleen Wilson]

On 1/7/16 11:15 AM, Peter Bowen 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.


Kathleen

___
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 ?

[Jakob Bohm]

On 07/01/2016 00:07, 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


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
___
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 ?

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