Honestly, I am not sure what actions would be appropriate.
My initial reaction was - Wikipedia (and all Wikimedia sites) is HTTPS-only, and this undermines HTTPS as such.
So if Wikipedia should only be accessible over (real, no man-in-the-middle) HTTPS, perhaps requests that don't meet this criteria should not be allowed. (Maybe a landing page displayed explaining the security implications).
Another thought that poped up in my mind was to make it read-only over unsecure connections.
I'm not very familiar with the circumstances of the 2015 decision to move to mandatory HTTPS and if that implied being blocked or inaccessible in whole countries as a consequence of this policy. But if that was the case, Kazakhstan perhaps falls into a similar category?
The technical difference (no HTTPS vs a HTTPS only if users allow government man-in-the-middle) is just a technical detail in my opinion, as the effects are the same as if Wikipedia was made only accessible over unencrypted HTTP in Kazakhstan.
Showing warnings is of course an option, but I am not sure if this is an effective security measure if users are forced by the goverment to install a backdoor.
Maybe it's better if Wikipedia would only be accessible over VPN or Tor if direct HTTPS is undermined this way. This would of course only work if users can have a secure connection to a VPN...
Hopefully, browsers do blacklist the certificate. And hopefully, they will not start a cat-and-mouse game by rotating their certificate...
rupert THURNER rupert.thurner@gmail.com writes:
displaying a warning that there is a MITM which reads all passwords and banking information sounds nice, yuri. there even seems to be ways to detect this client-server side: https://www.reddit.com/r/javascript/comments/7ldypq/is_it_possible_to_detect...
you mean something like this would do, yury?
george, the trusted root certificates would be configurable, usually, like for chrome here: https://support.securly.com/hc/en-us/articles/206081828-How-to-manually-inst... companies pay money to get into this list, so they can easier sell their website certificates. closing down the list for sure leads to some anti-trust legal action in other countries.
btw, recently there was a blog post from a developer in iran, saying the same : https://shahinsorkh.ir/2019/07/20/how-is-it-like-to-be-a-dev-in-iran
this had an even more surprising aspect - not only would the country block access to some site - but sites itself decided to remove users having a relationship with that country: "Slack team, decided to join the sanctions. They simply deleted every single user who they found out is Iranian! With no real prior notices! Many people has lost their data on Slack and no one was going to do anything!"
rupert
On Mon, Jul 22, 2019 at 7:05 PM George Herbert george.herbert@gmail.com wrote:
Browser vendors could revoke the root that Kazakh authorities are using for the scheme.
On Mon, Jul 22, 2019 at 5:35 AM Yuri Astrakhan yuriastrakhan@gmail.com wrote:
I don't think browser vendors will block the ability to install a custom root certificate because some corp clients may use it for exactly the
same
reason -- creating an HTTPS proxy with fake certs in order to analyze internal traffic (in the name of monitoring/security).
Browser vendors could make it more difficult to install, so that it would require the corp IT department to do some magic, or even release two versions of the browser - corp and general (with blocked uncertified root certs), but at the end of the day those could be worked around.
The biggest deterrent in my opinion is to educating the users of the dangers such certs would do (i.e. all your passwords and bank info will
be
viewable by ISPs) - thus it would be social rather than purely technical solution.
On Mon, Jul 22, 2019 at 1:33 PM Steinsplitter Wiki < steinsplitter@wikipedia.de> wrote:
That's shocking...
I think this has serious implications for Wikipedia & Wikimedia, as
not
only they would be easily able to see which articles people read,
but
also steal login credentials, depseudonymize people and even hijack admin accounts.
Yes, they can de-crypt the traffic. Hopefully browser vendors will disallow the root certificate. IMHO there isn't much WP can do, expect showing a warning if somebody
is
trying to login from the country in question.
--Steinsplitter
Von: Wikimedia-l wikimedia-l-bounces@lists.wikimedia.org im Auftrag
von
Yury Bulka setthemfree@privacyrequired.com Gesendet: Sonntag, 21. Juli 2019 12:36 An: wikimedia-l@lists.wikimedia.org wikimedia-l@lists.wikimedia.org Betreff: [Wikimedia-l] Universal forced HTTPS backdoor in Kazakhstan
I'm sure many have heard about this:
https://thehackernews.com/2019/07/kazakhstan-https-security-certificate.html
Essentially, the government in Kazakhstan started forcing citizens into installing a root TLS certificate on their devices that would allow the government to intercept, decrypt and manipulate all HTTPS traffic.
Without the centificate, it seems, citizens can't access HTTPS pages
(at
least on some ISPs).
I think this has serious implications for Wikipedia & Wikimedia, as not only they would be easily able to see which articles people read, but also steal login credentials, depseudonymize people and even hijack admin accounts.
Another danger is that if this effort by Kazakhstan will succeed, other governments may start doing the same.
I wonder if WMF has any position on this yet?
Best, Yury.
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
-- -george william herbert george.herbert@gmail.com _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe