Iran temporarily blocks the Farsi language edition of Wikipedia
Over the last days, between 2nd to 3rd March 2020, OONI measurements collected from 6 different networks in Iran showed that access to the Farsi edition of Wikipedia (fa.wikipedia.org) was temporarily blocked by means of DNS tampering and SNI filtering.
In this post, we share relevant OONI data.
Blocking of Farsi Wikipedia and Wikinews
In the past, Iran mainly blocked the HTTP version of specific Wikipedia articles. But over the last years, this probably wasn’t very noticeable because Wikipedia used HTTPS with HSTS enabled, meaning that Iranian internet users could easily access the censored pages.
On 2nd and 3rd March 2020, Iran blocked access to the entire Farsi language edition of Wikipedia – not just specific articles.
When websites are hosted on HTTPS (thereby encrypting connections), censors cannot limit the blocking to specific web pages. Instead, they need to make a choice: either block the entire website, or not block it at all. Often, governments around the world choose the latter, as blocking access to an entire website can result in public backlash (especially if that site is popular!). Over the last few days, Iran blocked access to the whole Farsi edition of Wikipedia, but the block didn’t last long, as it was lifted the next day.
The following chart illustrates the blocking of the Farsi versions of Wikipedia (fa.wikipedia.org) and Wikinews (fa.wikinews.org) on 6 different networks in Iran between 2nd to 3rd March 2020.
Source: OONI measurements collected from Iran (download the CSV used to produce the chart)
The block on Wikipedia appears to have been temporary, as all OONI measurements
collected from the same 6 networks in Iran from 13:29 UTC on 3rd March 2020
onwards show that https://fa.wikipedia.org
was
accessible
thereafter.
The Farsi edition of Wikinews (fa.wikinews.org) has remained blocked, but the site hasn’t been updated much over the last years. Locals in Iran informed us that fa.wikinews.org has been blocked for years, but this cannot be confirmed with OONI data since the site has only been tested with OONI Probe from 2nd March 2020 onwards. If the site has been blocked all along, that could potentially explain why the site has received significantly fewer updates in recent years.
It’s worth highlighting that the mobile version of the Farsi language edition of Wikipedia (fa.m.wikipedia.org) remains accessible, as does the English version of Wikipedia (en.wikipedia.org).
DNS tampering
OONI measurements show that both https://fa.wikipedia.org and https://fa.wikinews.org were blocked by means of DNS tampering.
The example below (taken from an OONI measurement)
shows that when the hostname fa.wikipedia.org
was looked up Iran,
the DNS answer contained the private IPv4 address
10.10.34.35
, which is commonly used to serve the Iranian
blockpage.
Source: OONI measurement testing fa.wikipedia.org in Iran
The same IP is also returned when looking up fa.wikinews.org
, as can
be seen from the following OONI measurement.
Source: OONI measurement testing fa.wikinews.org in Iran
While most OONI measurements clearly show that fa.wikipedia.org and
fa.wikinews.org were blocked by means of DNS tampering, some OONI
measurements present an HTTP failure
(instead of a DNS inconsistency error). This is likely due to the fact
that the real DNS query answer reached the end user faster than the
spoofed 10.10.34.35
one, therefore leading to a successful DNS
resolution. The fact that, although the DNS query succeeds, the
measurement still shows a block is an indication that SNI filtering may
be occurring, which we confirmed by running some manual tests (discussed
in the following section).
SNI filtering
In order to determine if fa.wikipedia.org
was also blocked by means of
SNI filtering, we ran some manual tests using dig and curl from a
vantage point located inside Iran.
As we can see from the following dig test results, this host is experiencing DNS based filtering, similarly to what is observed in the OONI Probe test results discussed previously.
dig fa.wikipedia.org @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3100
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;fa.wikipedia.org. IN A
;; ANSWER SECTION:
fa.wikipedia.org. 1 IN A 10.10.34.35
;; Query time: 75 msec
;; WHEN: Mon Mar 02 12:46:27 EST 2020
;; MSG SIZE rcvd: 50
dig fa.wikipedia.org @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17890
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;fa.wikipedia.org. IN A
;; ANSWER SECTION:
fa.wikipedia.org. 1 IN A 10.10.34.35
;; Query time: 58 msec
;; WHEN: Mon Mar 02 12:47:33 EST 2020
;; MSG SIZE rcvd: 50
When we circumvent the DNS filtering by using DNS over TCP and attempt to establish a connection to fa.wikipedia.org using curl, we notice that the connection is interrupted during the TLS handshake, as soon as the Client hello is sent.
curl -v https://fa.wikipedia.org
* Expire in 0 ms for 6 (transfer 0x56317b8c2f50)
[ SNIP ]
* Expire in 4 ms for 1 (transfer 0x56317b8c2f50)
* Trying 91.198.174.192...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x56317b8c2f50)
* Connected to fa.wikipedia.org (91.198.174.192) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to fa.wikipedia.org:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to fa.wikipedia.org:443
If instead we set the SNI to dyna.wikimedia.org and attempt a connection of fa.wikipedia.org, it goes through.
curl -vH "Host: fa.wikipedia.org" https://dyna.wikimedia.org
* Expire in 0 ms for 6 (transfer 0x5621e6548f50)
[ SNIP ]
* Expire in 200 ms for 1 (transfer 0x5621e6548f50)
* Trying 91.198.174.192...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5621e6548f50)
* Connected to dyna.wikimedia.org (91.198.174.192) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Wikimedia Foundation,Inc.; CN=*.wikipedia.org
* start date: Nov 12 00:00:00 2019 GMT
* expire date: Oct 6 12:00:00 2020 GMT
* subjectAltName: host "dyna.wikimedia.org" matched cert's "*.wikimedia.org"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5621e6548f50)
> GET / HTTP/2
> Host: fa.wikipedia.org
> User-Agent: curl/7.64.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 301
< date: Mon, 02 Mar 2020 12:47:02 GMT
[ SNIP ]
< location: https://fa.wikipedia.org/wiki/%D8%B5%D9%81%D8%AD%D9%87%D9%94_%D8%A7%D8%B5%D9%84%DB%8C
[ SNIP ]
* Connection #0 to host dyna.wikimedia.org left intact
This suggests that fa.wikipedia.org
was blocked by means of SNI
filtering, similarly to what we previously observed in Iran when Instagram was blocked in 2018 amid protests.
By running a similar curl based test, we can also see that the same
pattern of blocking is affecting fa.wikinews.org
(which remains blocked).
# curl -v --connect-to ::www.kernel.org: https://fa.wikinews.org
* Expire in 0 ms for 6 (transfer 0x55f763d10f50)
* Connecting to hostname: www.kernel.org
[ SNIP ]
* Trying 136.144.49.103...
* TCP_NODELAY set
* Expire in 149911 ms for 3 (transfer 0x55f763d10f50)
* Expire in 200 ms for 4 (transfer 0x55f763d10f50)
* Connected to www.kernel.org (136.144.49.103) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to fa.wikinews.org:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to fa.wikinews.org:443
In this case, when we attempt to establish a TLS connection to an unrelated domain name (www.kernel.org), SNI blocking is closing the connection during the ClientHello stage.
Further testing
Internet censorship in Iran is sophisticated and non-deterministic, changing on an ongoing basis. To more accurately measure internet censorship over time, larger volumes of longitudinal measurements are necessary.
As this study was carried out through the use of free and open source software (OONI Probe) and open data, it can be expanded upon by researchers in Iran and around the world (though participating in censorship measurement research can be risky).
Through the use of the OONI Probe mobile app, you can test 28 Wikipedia sites by tapping on the following button.
WikipediaUnless you opt-out in the OONI Probe app settings, all measurements will be openly published.
We thank all OONI Probe users in Iran for contributing measurements and making this study possible.