Egypt: Media censorship, Tor interference, HTTPS throttling and ads injections?
Probed ISPs: Noor (AS 20928), TE Data (AS 8452), Vodafone (AS 24835)
Censorship method: DPI, network throttling, TCP injections
OONI tests: HTTP Requests, Web Connectivity, Vanilla Tor
Measurement period: 2016-08-27 - 2016-10-26
We recently noticed network anomalies in Egypt and performed a study in an attempt to understand the situation.
Our findings indicate that the Tor anonymity network appeared to be interfered with in Egypt, while HTTPS connections to DigitalOcean’s Frankfurt data centre were throttled. We also found that access to porn sites appeared to be interfered with via in-band TCP packet injections of advertisement and malware content, and that the blocking of The New Arab website led to the blocking of specific content (such as images) of other sites that are hosted on the same Content Distribution Network (CDN).
Below we present our findings based on network measurement tests performed over the last two months.
The New Arab website www.alaraby.co.uk
and its mirror website
has been blocked in Egypt since 2016-01-05 according to the Guardian
news outlet. Similarly, the domain
pointing to the same website (
www.alaraby.co.uk) has also been blocked. The
ISPs have not redirected the visitors to any block page or any resource that
explains the reason of the block. Instead, they appear to have used Deep
Packet Inspection (DPI) equipment to censor the content of the website. When
requesting the HTTP version of the websites
http://www.alarabyaljadeed.co.uk a response from the middlebox is triggered
containing a blank webpage as is shown by the following two OONI measurements
collected on 25th of October 2016:
The request for the HTTPS version of the websites (
https://www.alarabyaljadeed.co.uk) times out and no response is received, as
shown in the following measurement:
In addition to the censorship of the media website The New Arab, this blocking has caused some collateral damage to other websites hosted on the same Content Delivery Network (CDN).
The screenshots below illustrate how these websites appeared from an Egyptian vantage point (right-side) and when accessed via Tor Browser (left-side):
Throughout August 2016 we noticed that HTTPS connections to a number of services using DigitalOcean’s Frankfurt data centre appeared to be presenting network connectivity issues from two Egyptian vantage points: Noor ADSL (AS20928) and Vodafone Egypt (ex-RAYA Telecom, AS24835).
As part of our research we found that one way to consistently reproduce a
network interference is by sending HTTPS requests to the network sub-nets
belonging to DigitalOcean’s Frankfurt data center (including, but not limited
AS201229). Our experiment showed consistent
and heavy throttling of HTTPS services located in the network: only 3% of TCP
connection attempts succeeded.
Our latency analysis suggests that all the packets that the client was receiving were timeout-based TCP re-transmissions and that a network device was consistently dropping the first occurrence of each TCP packet.
Non-encrypted protocols on the other hand, like plain HTTP, which hosted services in the same sub-nets were not affected. This indicates that only HTTPS connections were throttled, while insecure HTTP connections to DigitalOcean’s Frankfurt data centre were successful.
Based on our tests, the last sample of throttling that we observed occurred on 2016-09-01 12:30 UTC.
The complete and detailed technical analysis can be found here.
The HTTPS throttling of services hosted by DigitalOcean’s Frankfurt data centre led to the inaccessibility of various URLs. These include the following:
As well as the following URLs:
https://alexmerkel.xyz. The raw JSON OONI
measurements file (25Mb size) of these URLs can be found
The above lists however are not exhaustive and more websites may have been affected which are not listed here.
Two days ago, tests were run to examine the reachability of the Tor anonymity network. The collected measurement data indicates that the Tor process bootstrap was disrupted by blocking requests to directory authorities, which are designed to help Tor clients learn the list of relays that make up the Tor network.
One of the requests that were found to be blocked is a request to download a
“consensus” document from Tor directory authorities. That request is a plain
HTTP request to the URL:
http://18.104.22.168/tor/status-vote/current/consensus.z from a networking
point of view. Connections to directory authorities are intercepted and
blocking is performed by injecting a packet that terminates the connection
abruptly (a TCP RST packet). This happens right after the server acknowledges
The injected RST packets share the same static IP identification (IP ID) value of
0x3412 as the
injected RST packets used to block aforementioned websites that we have found to be
blocked. Usage of the same IP ID implies that the blocking infrastructure used
to censor Tor is the same (or similar) to that used to block other websites
(see the in depth technical analysis of
in-band TCP content injections).
In our testing we found 7 out of 9 directory authority consensus file requests to be blocked:
We also found access to the now discontinued Tor directory authority urras to
.We did not test the accessibility of the recently added
directory authority, nor do we have samples regarding the potential blocking of
Also, it’s just the set of consensus URLs that are blocked, for example, the
/tor/status-vote/current/lack-of-consensus.z produces ordinary
404 Not found error. That implies that the blockage is explicitly targeting
Another type of request that is blocked is the Onion Router handshake sent to
ORPort of the well-known Tor router. They appear to be blocked in the same way:
the TCP connection is interrupted by terminating the connection (with a TCP RST
packet) during the TLS handshake (after the first
Client Hello from the
The blocking appears to only be targeting Tor in a default configuration. This means that it’s possible to easily circumvent such censorship by using any Tor Bridge, including non-obfuscated ones. Given the fact that the blocking of connections doesn’t happen all the time, a client should be able to bootstrap a Tor connection successfully with enough retries. This however can, in some cases, take up to a half an hour. Moreover, OR connections are only blocked to some subset of the public Tor network, meaning that if a client has already bootstrapped and has a cached version of the consensus and descriptors it is likely to work properly. The connection is not throttled as soon as it is established successfully.
This sort of Tor blockage seems to still be active in the moment of the publication of this report.
But this is not the first time we noticed interference with the Tor network in Egypt. Earlier this month, users reported that they couldn’t connect directly to Tor from Egypt and had to use bridges to access it. Tor Metrics statistics illustrate that direct connections to Tor were reduced on 2nd and 25th October 2016, while the use of bridges increased, indicating that Tor might have been blocked. It’s probably worth noting though that only around 30% of Tor users appear to have used bridges to circumvent potential censorship.
The following graphs below illustrate the estimated number of directly-connecting clients and the estimated number of clients connecting via bridges.
Through our research we found false content deliberately injected by at least one ISP in Egypt: TE Data. This ISP accounts for 65% of the market share and controls over 70% of the Egyptian internet bandwidth TE Data appears to be using DPI or similar network equipment to conduct a man-in-the-middle attack and transparently inject content for gaining profit (affiliate advertising) or malicious purposes (serving malware).
Our experiment showed that there was a 10% probability that mobile device users
connected via Wi-Fi to TE Data ADSL would get redirected when visiting some
porn websites. The redirection injected the URL
http://marketing-sv.com/mads.html, which serves at least two different static
web-pages redirecting to
directly or via static pages from
utextads.com subdomains. This
PopUp/PopUnder advertisement network is known to be used by malware authors to
During our October 2016 investigation the injector was mostly targeting mobile
User-Agents. It was not limited to
iPhone and Android platforms, but also targeted BlackBerry and Symbian devices.
In August 2016 ooniprobe also captured a similar
in the TE Data network. The injection was redirecting the user to
http://go.ad2upapp.com/afu.php?id=723454 that further redirects to
http://go.deliverymodo.com/afu.php?id=723454, a different advertising website
but with the same affiliate ID (723454). We also received user complains about
similar injections in transit traffic of Vodafone 3G
(AS36935) and Noor ADSL
(AS20928) pointing to the
We also discovered at least one malware sample served by the chain of web redirects starting with the aforementioned link during our research. Our IP TTL and network packet latency analysis confirms that the injection is done in-band using a DPI or similar network equipment to conduct a man-in-the-middle attack. The analysis refutes the hypothesis of an “infected” website serving advertisements instead of content. The statistics suggest that the injector is located within the TE Data network (not further than that and not as close as end-user LAN) and transparently injects content for gaining profit via affiliate advertising.
Client <--(forged packet)-- ISP's middle box <--(valid packet)-- Web server
The curl output excerpts below illustrate how TE Data and Noor ISP redirected users’ connections to porn websites through the injection of ads. It’s important though to note that the DNS query answers of the requested domains are legitimate, and there appears to be no sign of DNS tampering.
TE Data ISP redirected the user visiting
http://xnxx.com/ (34th most visited
website in Egypt according to Alexa statistics) to
HTTP headers curl output
http://xnxx.com/ in Noor ISP.
* Rebuilt URL to: http://xnxx.com/ * Hostname was NOT found in DNS cache * Trying 22.214.171.124... * Connected to xnxx.com (126.96.36.199) port 80 (#0) > HEAD / HTTP/1.1 > User-Agent: curl/7.35.0 > Host: xnxx.com > Accept: */* > < HTTP/1.1 307 Temporary Redirect < Location: http://go.ad2upapp.com/afu.php?id=723454 < Connection: close < * Closing connection 0
Noor ISP redirected the user visiting
http://xhamster.com/ (53th most visited
website in Egypt according to Alexa statistics) to
HTTP headers curl output of
* Trying 188.8.131.52... * Connected to xhamster.com (184.108.40.206) port 80 (#0) > HEAD / HTTP/1.1 > Host: xhamster.com > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 307 Temporary Redirect < Location: http://adf.ly/1cqbTY < Connection: close < * Closing connection 0
The complete and detailed technical analysis of the injected malware and advertisements in TCP connections can be found here.
OONI findings in Egypt revealed the censorship of a media website, blocking of services and malicious TCP injections of advertisements and malware content. ISPs in Egypt appear to be using DPI, TCP injections and network throttling to block resources, censor websites and serve advertisements and malware to internet users.
You can bypass such censorship through the use of Tor and the Tor Browser. Users in mobile networks can use Orbot (Tor on Android) to access the web or other mobile applications by using the VPN mode of Orbot which enables all apps on the device to run through the Tor network.
OONI would like to thank anonymous contributors that reported and shared evidence to document these incidents including, but not limited to, the cypherpunk who asked to be identified by the following hashsum:
Detailed technical analysis: