| Nation State MITM CA's ? | Paul Wouters | 06/01/16 03:08 م | 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 |
| Re: Nation State MITM CA's ? | Kathleen Wilson | 07/01/16 11:01 ص | Kazakhstan has submitted the request for root inclusion:
https://bugzilla.mozilla.org/show_bug.cgi?id=1232689 So, we really do need to have this discussion now. I will appreciate thoughtful and constructive input into this discussion. Kathleen |
| Re: Nation State MITM CA's ? | Peter Bowen | 07/01/16 11:15 ص | On Thu, Jan 7, 2016 at 11:00 AM, Kathleen Wilson <kwi...@mozilla.com> wrote: > Kazakhstan has submitted the request for root inclusion:Kathleen, The information in the bug is incomplete by Mozilla's policy. They indicate that they plan to get a WebTrust audit but have not done so at this time. They should be informed that they need both a WebTrust for CA and a WebTrust for BR audit before their application can move forward. Additionally all of the documentation (CPS, diagrams, etc) is in a language that uses the Cyrillic alphabet. I'll guess this is either Kazakh or Russian, but I'm not sure as I don't read either. I ran the CPS through an online translator and it appears to only cover issuance of subordinate CAs. This, combined with their comment on OCSP responder availability, makes it sound like this is a 'super-CA' (https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs). This suggests that they need to provide more detail on the subordinates, including subordinate CA CPS(es) and audits. Until such time that the provide this, I don't see how they are any different from the thousands of private PKIs that are run by companies for their own use. Many of those PKIs may be used to MITM connections. All CAs should be held to the same standard when asking for admission to the Mozilla program, this is no different. Thanks, Peter |
| Re: Nation State MITM CA's ? | Kathleen Wilson | 07/01/16 12:29 م | On 1/7/16 11:15 AM, Peter Bowen wrote:
> <snip> >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 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 |
| Re: Nation State MITM CA's ? | Jakob Bohm | 07/01/16 01:10 م | 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 |
| Re: Nation State MITM CA's ? | Paul Wouters | 07/01/16 01:22 م | On Thu, 7 Jan 2016, Jakob Bohm wrote:Much easier would be to not allow a CA cert not to engage in such dual roles. I'm not sure how to that would work in practise. I know it can be done using TLSA DNS records to pin each domain. Having that logic elsewhere seems more dangerous and less transparent. I 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. 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 |
| Re: Nation State MITM CA's ? | David E. Ross | 07/01/16 02:35 م | I suggest deferring any effort on this request other than informing the
certification authority that they need audits both for WebTrust for CA and for BR. That notice should also indicate that, without PROPER audits with public-facing audit reports, no action can be taken. No other effort should be expended on this. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>. |
| Re: Nation State MITM CA's ? | Jakob Bohm | 07/01/16 04:40 م | On 07/01/2016 22:21, Paul Wouters wrote:Unfortunately, we have little power to do that. So if we don't accept the CA, the users have to install a different browser or install that CA manually in order to e.g. pay their taxes, but if we do accept it without filtering, we expose them to the MITM. I seem to have seen "recent" X.509 extensions that can restrict the DNS domains for which a CA can (directly or indirectly) issue certificates. Compare the "Technically restricted" subCA clauses in current Mozilla criteria. Idea would be to "tack on" additional semantically equivalent restrictions even where not present in the actual CA cert. It's the opposite. Restricting single-country CAs from being trusted for wordwide URLs while still being trusted for URLs for which it is appropriate. For the dual use nation-CA case this means allowing worldwide users to connect securely to that nations government websites, while protecting them from MITM attacks. For the ordinary nation-CS case, the means limiting the scope of trust to nation addresses. For example "Staat der Neederlanden" would not be trusted for .com domains such as google.com, thus preventing (if it had been implemented back then) the DigiNotar breach from affecting Google users in Iran visiting .com domains. Note though that EKUs don't limit the domains or identities for which a CA issues (real or MITM) certificates, only the protocols and protocol roles. For example being a HTTPS server is one EKU, being an e-mail signature is another EKU etc. Hence all my other suggestions. |
| Re: Nation State MITM CA's ? | Peter Bowen | 07/01/16 06:19 م | On Thu, Jan 7, 2016 at 2:34 PM, David E. Ross <nobody@nowhere.invalid> wrote: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. |
| Re: Nation State MITM CA's ? | Eric Mill | 07/01/16 07:20 م | For the thread's reference, this is the relevant part of the application
(from attached scanned images, more extended than the text they included inline on the Bugzilla thread) that describes the intended use: https://s3.amazonaws.com/konklone-public/kazakh/kazakh1.png And this section has some additional information about potential uses and their intent to get a WebTrust audit: https://s3.amazonaws.com/konklone-public/kazakh/kazakh2.png -- Eric > _______________________________________________ > dev-security-policy mailing list > dev-secur...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> |
| Re: Nation State MITM CA's ? | Jakob Bohm | 07/01/16 08:32 م | On 08/01/2016 03:19, Peter Bowen wrote:
>... >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). |
| Re: Nation State MITM CA's ? | Gervase Markham | 08/01/16 07:35 ص | On 07/01/16 19:15, Peter Bowen wrote:This seems like the lowest-effort way to punt. I doubt they'd ever get one - and if they did, I'd want to have very careful words with their auditor. Gerv |
| Re: Nation State MITM CA's ? | Phillip Hallam-Baker | 08/01/16 11:45 ص | On Thu, Jan 7, 2016 at 2:00 PM, Kathleen Wilson <kwi...@mozilla.com> wrote: > Kazakhstan has submitted the request for root inclusion:I suggest waiting until they name their auditors before processing the request. |
| Re: Nation State MITM CA's ? | Kai Engert | 08/01/16 12:56 م | 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 |
| Re: Nation State MITM CA's ? | Florian Weimer | 08/01/16 02:32 م | * Jakob Bohm:
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 |
| Re: Nation State MITM CA's ? | Eric Mill | 08/01/16 02:45 م | Correct me if I'm wrong, but I think Mozilla has only actively distrusted
"publicly trusted" certificates -- certificates that could be used to intercept traffic from a device with an unmodified root store. So that includes whenever a publicly trusted CA improperly issues certificates, which can also include forged certificates like the 2008 MD5 collision attack -- but *doesn't* include certificates issued by enterprises or other organizations not represented in the trusted root program, but which Mozilla or its community take moral issue with in some way. This has seemed like an effective line to draw so far. -- Eric |
| RE: [FORGED] Re: Nation State MITM CA's ? | Peter Gutmann | 09/01/16 06:11 ص | Kai Engert <ka...@kuix.de> writes: >Independently of the request for inclusion, this group could discuss if the That would have some pretty bad consequences. With the MITM CA cert enabled, Peter. [0] The personification of the Kazakh CA-enabled MITM, following the pattern |
| Re: Nation State MITM CA's ? | cub...@gmail.com | 09/01/16 08:24 ص | 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 |
| Re: [FORGED] Re: Nation State MITM CA's ? | Kai Engert | 09/01/16 10:22 ص | On Sat, 2016-01-09 at 14:11 +0000, Peter Gutmann wrote: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 |
| Re: Nation State MITM CA's ? | Brian Howson | 11/01/16 07:47 ص | 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 |
| Re: [FORGED] Re: Nation State MITM CA's ? | Jakob Bohm | 11/01/16 10:45 ص | 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. |
| Re: [FORGED] Re: Nation State MITM CA's ? | Phillip Hallam-Baker | 11/01/16 10:58 ص | On Mon, Jan 11, 2016 at 1:45 PM, Jakob Bohm <jb-mo...@wisemo.com> wrote: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. |
| Re: Nation State MITM CA's ? | Jakob Bohm | 11/01/16 11:11 ص | On 08/01/2016 23:31, Florian Weimer wrote: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).
|
| Re: [FORGED] Re: Nation State MITM CA's ? | Kai Engert | 11/01/16 01:41 م | On Mon, 2016-01-11 at 19:45 +0100, Jakob Bohm wrote: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 |
| RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Peter Gutmann | 11/01/16 02:35 م | Kai Engert <ka...@kuix.de> writes: >On Sat, 2016-01-09 at 14:11 +0000, Peter Gutmann wrote: For the MITM to work, Borat will be proxying all traffic out of (and into) the If you allow the MITM cert, only Borat/the proxy can read everyone's traffic. If you disallow the cert and turn off encryption, Borat can still read The "can't connect to the site without TLS" issue isn't really there either, Peter. |
| RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Paul Wouters | 11/01/16 03:04 م | On Mon, 11 Jan 2016, Peter Gutmann wrote:
>>> That would have some pretty bad consequences. With the MITM CA cert enabled, >>> Borat [0] can read every Kazakh user's email, but no-one else can. With the >>> MITM CA blacklisted, Borat can still read every Kazakh user's email, but so >>> can everyone else on the planet. So the choice is between privacy against >>> everyone but one party, and privacy against no-one. >> >> I don't understand why blacklisting a MITM CA would enable everyone to read >> the data that passes through the MITM. Could you please explain? (It sounds >> like there is either a misunderstanding on your or on my side.) > > For the MITM to work, Borat will be proxying all traffic out of (and into) the > country. > > If you allow the MITM cert, only Borat/the proxy can read everyone's traffic. > > If you disallow the cert and turn off encryption, Borat can still read > everyone's traffic, but so can everyone else on the planet. Who said "turn off encryption"? > The "can't connect to the site without TLS" issue isn't really there either, > Borat will connect using TLS so TLS-only sites will continue to work, it's > only the downstream users who don't get any protection. Publishing a DNSSEC signed TLSA record would indicate TLS should be on the connection and which public key to expect. So we'd hope the browser would hard fail here. Paul |
| RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Peter Gutmann | 11/01/16 03:12 م | Paul Wouters <pa...@cypherpunks.ca> writes: >> If you disallow the cert and turn off encryption, Borat can still read If you don't allow the MITM cert, which is needed to enable encryption in the Peter. |
| RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Paul Wouters | 11/01/16 08:08 م | On Mon, 11 Jan 2016, Peter Gutmann wrote:Or we ensure that firefox and chrome refuses to see those sites at all, because they refuse a downgrade attack. Let the nation state basically block all of the sites they want to MITM and see how that works out. Otherwise, allowing this is just the same as backdoored encryption in the browser - and it will be coming to a browser or nation state near us. Paul |
| RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Peter Gutmann | 12/01/16 01:49 ص | Paul Wouters <pa...@cypherpunks.ca> writes: >Or we ensure that firefox and chrome refuses to see those sites at all, So users will switch to whatever browser doesn't block it, because given the >Let the nation state basically block all of the sites they want to MITM and It'll work out just fine for them, because what you're giving users is a Even if every single browser vendor decides to block (which will never happen, Peter. |
| RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Paul Wouters | 12/01/16 06:37 ص | On Tue, 12 Jan 2016, Peter Gutmann wrote:And they'll grab a firefox/chrome from the free world. Not really. But let's just leave it at that we disagree. Paul |
| Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Richard Barnes | 12/01/16 07:18 ص | On Tue, Jan 12, 2016 at 1:48 AM, Peter Gutmann <pgu...@cs.auckland.ac.nz>
wrote: > >Or we ensure that firefox and chrome refuses to see those sites at all,An appropriate example. May I note that Facebook has lately been turning off support for non-encrypted users? So regardless of the browser, a user cannot access Facebook without HTTPS. In any case, I think this thread is getting pretty far off-topic. --Richard
> It'll work out just fine for them, because what you're giving users is a > choice between using the Internet and not using it, and close to 100% will> _______________________________________________ > dev-security-policy mailing list > dev-secur...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > |
| Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Phillip Hallam-Baker | 12/01/16 07:49 ص | 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. |
| Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Jakob Bohm | 12/01/16 08:47 ص | No one (except the MiTM CA itself, possibly) is suggesting that Mozilla
include or authorize any MiTM CA to work in its browsers (or anything else using the Mozilla CA list). The discussion is how to *not* authorize it, without thereby causing too much collateral damage. Questions being seriously discussed: - Should Mozilla add specific mechanisms that prevent the subjects of a police state from obeying police orders to compromise their own browser? This is the most hotly debated topic in this thread. - Should Mozilla find a mechanism to allow only the non-MiTM part of a dual use CA which is being used both as an MiTM CA and as the legitimate CA for accessing government services, such as transit visa applications by foreign travelers planning to cross the territory of the police state on their way somewhere else? - How to most easily reject requests by the MiTM CAs to become globally trusted CAs in the Mozilla CA store. Without causing precedents that would hurt legitimate CAs from countries that happen not to be allies of the USA. So far, the best suggestion (other than to stall them on technicalities) is to find an interpretation of the existing CA rules which cannot be satisfied by any MiTM CA. 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 |
| Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Phillip Hallam-Baker | 12/01/16 09:07 ص | On Tue, Jan 12, 2016 at 11:46 AM, Jakob Bohm <jb-mo...@wisemo.com> wrote: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. 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. |
| Re: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ? | Eric Mill | 12/01/16 02:27 م | 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 > _______________________________________________-- konklone.com | @konklone <https://twitter.com/konklone> |
| Re: Nation State MITM CA's ? | Kathleen Wilson | 13/01/16 12:38 م | 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 |
| Re: Nation State MITM CA's ? | staro...@gmail.com | 18/07/19 08:55 ص | 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 |
| Re: Nation State MITM CA's ? | Wayne Thayer | 18/07/19 09:50 ص | 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 |
| Re: Nation State MITM CA's ? | Wayne Thayer | 18/07/19 10:04 ص | On Thu, Jul 18, 2019 at 10:00 AM Ryan Sleevi <ryan....@gmail.com> wrote:
> 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. |
| Re: Nation State MITM CA's ? | Matthew Hardeman | 18/07/19 11:39 ص | 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 < |
| Re: Nation State MITM CA's ? | Andrew | 18/07/19 12:11 م | 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. |
| Re: Nation State MITM CA's ? | Matthew Hardeman | 18/07/19 12:42 م | 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. |
| Re: Nation State MITM CA's ? | health...@gmail.com | 18/07/19 05:26 م | I like the idea of a non-closable banner below the URL simply stating "Kazakhstan is spying on you, learn more here <link to more info>".
|
| Re: Nation State MITM CA's ? | gewalo...@gmail.com | 18/07/19 05:26 م | 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. |
| Re: Nation State MITM CA's ? | wolfgan...@gmail.com | 18/07/19 05:26 م | 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 |
| Re: Nation State MITM CA's ? | troyc...@gmail.com | 19/07/19 08:25 ص | On Thursday, July 18, 2019 at 2:39:51 PM UTC-4, Matthew Hardeman wrote: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. |
| Re: Nation State MITM CA's ? | cmal...@gmail.com | 19/07/19 08:26 ص | Appeal to the Mozilla Firefox developers
Hello to all! I'm Software Engineer and citizen of Kazakhstan. This certificate is not implemented to protect users, but for political reasons. Kazakhstan has a dictatorship. This is done specifically to block "politically incorrect content.". Look this link: https://www.ohchr.org/EN/NewsEvents/Pages/DisplayNews.aspx?NewsID=24691&LangID=E The installation of this certificate leads to the leakage of personal data, as well as special services of Kazakhstan will be able to selectively block Internet pages. If it is allowed to install this certificate, the authorities will pursue innocent citizens of Kazakhstan for politically motivated reasons. That's all I wanted to say. |
| Re: Nation State MITM CA's ? | muc...@wirade.ru | 19/07/19 08:26 ص | Well, then users will just get accustomed to seeing this indication on corporate sites and will ignore it.
Regards, Mucius. |
| Re: Nation State MITM CA's ? | nus...@gmail.com | 19/07/19 08:27 ص | 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.." :) |
| Re: Nation State MITM CA's ? | Troy Cauble | 19/07/19 08:27 ص | On Thursday, July 18, 2019 at 8:26:43 PM UTC-4, wolfgan...@gmail.com wrote:I like the consistency of a reminder in all cases, but this might lead to corporate policies to use other browsers. |
| Re: Nation State MITM CA's ? | Matthew Hardeman | 19/07/19 08:53 ص | 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. |
| Re: Nation State MITM CA's ? | andrey...@gmail.com | 19/07/19 12:24 م | 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? |
| Re: Nation State MITM CA's ? | saxp...@gmail.com | 19/07/19 12:25 م | 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? |
| Re: Nation State MITM CA's ? | effs...@yahoo.com | 19/07/19 01:06 م | 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.
|
| Re: Nation State MITM CA's ? | Jakob Bohm | 19/07/19 01:23 م | 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. |
| Re: Nation State MITM CA's ? | Jakob Bohm | 19/07/19 01:27 م | On 19/07/2019 21:13, andrey...@gmail.com wrote: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. |
| Re: Nation State MITM CA's ? | andrey...@gmail.com | 19/07/19 02:42 م | 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. |
| Re: Nation State MITM CA's ? | dav...@gmail.com | 19/07/19 02:42 م | 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. |
| Re: Nation State MITM CA's ? | My1 | 20/07/19 06:30 م | 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. if you want to block like half the internet or more which is on the way of HTTPS-only, go ahead. 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 fully agree that this is hard but one also needs to be aware that antiviruses while not unhelpful also provide risks by being VERY deep in the system. an unmonitored MITM action by that could end in disastrous results, in the worst case bank phishing could occur since the user cannot verify the certificate via the browser. one suggestion I think might be helpful is to have the entire data available, while keeping the HTTPS signature, and there could be a machanism that allows anti-virus software to check content before it is executed/loaded and if needed, put a big "do not execute" flag for certain things like script blocks that are clearly malicious or whatever, and the browser can check the signature that no content has been actually changed, but remove that flagged content, while displaying a notification that content has been blocked. that way anti-viruses could only remove elements but not actually change anything. let me go over each of your situations and what I think of those: 1) obviously needs a VERY clear warning including the specific information about the actor like who is the interceptor 2) similar to 1 but obviously it cannot have the specific information that is known about a, well, known actor. 3 and 4 are similar but there should be a "lesser" click-through warning that just informs the user for example once per session that he is on watch (because while these things can filter bad stuff, they can also read sensitive inputs like passwords), while the cert if it can be retrieved from a "trusted" source, for example the active directory, while 4 shouldnt be using classic MITM scenarios at all, see my idea above. I don't know how or even whether or not it is possible to have one client prove to another that site X actually came in via HTTPS and was signed using X, because of all the ephemeral keys and everything, but that way a proxy could be made that securely transmits data from websites to the client, while also flagging content that should not be touched. obviously with a notification if any of these flags occur. 5) is a fairly valid case and in my opinion DANE is a decent way to deal with that, only the browsers need to play along. the only problem with your idea of categorizing these issues is how to differentiate 3 and 4 from 2. in the classic MITM style scenario anything could have installed the MITM CA and in case of 4 the private key is even on that computer. a field day for malware. there would need to be a verifiable source for the MITM CA, to not be seen as 2. for case 4 at least one could make it much less ugly by only transmitting recieved data to the software while inputs stay secret, but in case 3 where we want to scan and filter inputs, this is obviously not possible. Regards, My1 |
| Re: Nation State MITM CA's ? | peri...@dsmouse.com | 20/07/19 06:30 م | It would allow people who are using VPNs and other alternative access strategies to realize that they forgot to turn it on/etc
|
| Re: Nation State MITM CA's ? | sim...@gmail.com | 20/07/19 06:31 م | 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. |
| Re: Nation State MITM CA's ? | My1 | 20/07/19 06:53 م | 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. |
| Re: Nation State MITM CA's ? | Jakob Bohm | 20/07/19 09:44 م | 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. |
| Re: Nation State MITM CA's ? | Jakob Bohm | 20/07/19 10:29 م | On 21/07/2019 03:21, My1 wrote:I believe this is either done, or easy to add. Hence my breakdown and suggestions below, which seem to agree with yours in most cases. As for on-machine antivirus, hence my suggestion to locally (on machine) use a protocol already implemented for corporate users by the larger antivirus companies (ICAP). There are legitimate security programs that remove certain received data, such as removing embedded loads of government pushed tracking beacons. Similar, many higher end personal security packages have features to prevent the less experienced family members from revealing their home address or other such details to physically dangerous people, the appropriateness of such features should be a family decision, not a browser decision. However there should be browser settings to choose the level of scanning entrusted to each local scanner (scan post yes/no, scan file upload yes/no, modify post/upload data yes/no, scan URLs yes/no, modify server replies yes/no). DANE has some unfortunately implementation difficulties, mostly inherited from DNSSEC. It would be unfortunate to limit home or company internal systems to mechanisms essentially different from how the same job is done elsewhere, especially for testing stuff. Ways to recognize type 5 scenarios could include (with combinations occurring in any one situation) could be: - DNS names in the guaranteed non-public TLDs: .local, .lan, .example, .invalid etc. - DNS names outside all TLDs listed in the public suffix list included with the browsers. (for example .somefamilynickname). - DNS names at least 2 levels below public suffixes and not existing on DNS in the public Internet. Need someone highly trusted to check this without revealing the probed DNS names widely. (For example internal.example.com with .com being the public suffix and the example.com DNS servers controlled by the home/company). - IPv4 addresses from the RFC1918 and 127.x.x.x ranges of LAN IPs (in IP subject-alt-names). - IPv6 addresses from the ranges similarly reserved for non-public use. - CAA record somehow matching the private CA and not any of the browser- bundled CAs. - e-mail certificates will be harder to separate as public e-mail certs are kind of unpopular except government citizen CA schemes. Indeed, hence the need for heuristics and countermeasures. #3 would probably become a #2 warning in all but the most strictly identifiable cases. #4 could be transitioned to a cross-vendor AV API, such as ICAP to localhost or a plugin API much simpler than NPAPI.
|
| Re: Nation State MITM CA's ? | h | 22/07/19 09:52 ص | 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. |
| Re: Nation State MITM CA's ? | qm3...@gmail.com | 22/07/19 04:08 م | 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. |
| Re: Nation State MITM CA's ? | Corey Bonnell | 22/07/19 07:20 م | 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 |
| Re: Nation State MITM CA's ? | jfb...@gmail.com | 22/07/19 08:27 م | On Monday, July 22, 2019 at 7:08:19 PM UTC-4, qm3...@gmail.com wrote: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.. |
| Re: Nation State MITM CA's ? | Han Yuwei | 22/07/19 08:32 م | 在 2016年1月7日星期四 UTC+8上午7:08:10,Paul Wouters写道:
> As was in the news before, Kazakhstan has issued a national MITMAdding banner is a acceptable action to hint this kind of attacking. Banning this CA can't solve any problem, because KZ ISP can just block any TLS connections. But maybe we can let websites choose which CA they would use just like HSTS. |
| Re: Nation State MITM CA's ? | Matthew Hardeman | 22/07/19 08:34 م | On Mon, Jul 22, 2019 at 9:20 PM Corey Bonnell via dev-security-policy <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. |
| unk...@googlegroups.com | 22/07/19 08:50 م | <لقد تم حذف هذه الرسالة.> | |
| Re: Nation State MITM CA's ? | whateverus...@gmail.com | 23/07/19 08:32 ص | On Tuesday, July 23, 2019 at 7:34:11 AM UTC+4, Matthew Hardeman wrote: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. |
| Re: Nation State MITM CA's ? | nyx...@gmail.com | 23/07/19 01:34 م | On Wednesday, January 6, 2016 at 5:08:10 PM UTC-6, Paul Wouters wrote:Coordinated blacklisting. We shouldn't incentivize this kind of behavior. |
| Re: Nation State MITM CA's ? | jfb...@gmail.com | 24/07/19 09:43 ص | 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. |
| Re: Nation State MITM CA's ? | Matthew Hardeman | 24/07/19 11:02 ص | 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. > .... |
| Re: Nation State MITM CA's ? | bay...@gmail.com | 26/07/19 08:32 ص | On Friday, July 19, 2019 at 10:53:16 AM UTC-5, Matthew Hardeman wrote: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). |
| Re: Nation State MITM CA's ? | sedri...@gmail.com | 26/07/19 09:54 ص | четверг, 7 января 2016 г., 4:08:10 UTC+5 пользователь Paul Wouters написал:
> As was in the news before, Kazakhstan has issued a national MITMI 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 |
| Re: Nation State MITM CA's ? | vto...@googlemail.com | 27/07/19 10:17 ص | * 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. |
| Re: Nation State MITM CA's ? | RS Tyler Schroder | 07/08/19 08:24 ص | 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 |
| Re: Nation State MITM CA's ? | Wayne Thayer | 21/08/19 12:14 م | Mozilla has announced our response to the Kazakhstan MITM:
https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/ and https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/ Note: we're in the process of adding the "Qaznet" root certificate to OneCRL, but you won't yet find it to be revoked. - Wayne > _______________________________________________ > dev-security-policy mailing list > dev-secur...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > |
| Re: Nation State MITM CA's ? | Wayne Thayer | 21/08/19 12:42 م | (resending because the first attempt was not posted to the list)
|