A Case Study in Iran

In May of 2016, ICLab in collaboration with Smallmedia UK, conducted a case-study of censorship on 7 URLs in Iran to determine if they are blocked, and if so, what methods were used to block access to these URLs.

Small Media is a London-based action lab, providing digital research, training and advocacy solutions to support the work of civil society actors that provides assistance to at-risk communities globally. This report explains the results of our study. You can find the full version of the report here.

Censorship experiments were conducted on 6 URLs that were run on four vantage points running ICLab software. These vantage points are located in 3 Autonomous Systems (AS) inside Iran: 2 in AS 48434 (Tebyan-e-Noor Cultural-Artistic Institute), and one in each of AS 16322 (Pars Online PSJ) and AS 42337 (Respina Networks & Beyond PJSC).

We collected data from the above ICLab vantage points in the field and analyzed them to identify information controls and censorship. For the case of website blocking detection, we have automated “page-view” queries run on our vantage points that try to load websites while collecting measurement data. This data is sent back to the centralized system to identify anomalies and known blocking methods (e.g. blockages, DNS injection).

The URLs

The URLs tested are:

• http://persian.euronews.com
• http://dargahpardakht.com
• http://www.kajonline.ir
• https://jensiat.io
• http://www.bbc.com/persian
• http://www.samen-alhojaj.ir
• https://www.zarinpal.com

These URLs were selected because the subject matter they cover suggest that they might be filtered, or because we have heard claims on social media, in blogs, and on news reports that the sites might be filtered. Below is a brief description of each website and a short explanation of why we thought it was worth testing.

http://persian.euronews.com/

• This is the Farsi-language version of Euronews. According to rumours on Iranian social media and blogs, this website may have drawn the ire of the authorities due its coverage of Iran’s involvement in Syria.

http://dargahpardakht.com/

• This is an online payment website whose users and owner have complained of disruptions, possibly due to a court order.

http://www.kajonline.ir/

• The is a reformist news website. Reformist media is often a popular target for Iran’s censorship authorities.

https://jensiat.io

• This is a new website (disclosure: Small Media was involved in its development) with content about sexual health and digital security, two sensitive topics in Iran.

http://www.bbc.com/persian

• This is the Farsi-language and Iran-focused version of BBC news. Iranian conservatives’ recent suspicions regarding the BCC’s role in parliamentary elections suggests that this website might be vulnerable to filtering.

http://www.samen-alhojaj.ir

• This is the website of a financial institution whose activities we rumoured to have been the subject of a recent court order, so we wanted to see if the website was still accessible.

https://www.zarinpal.com

• This payment service is similar to Paypal. Given recent reports of disruptions to other online payment services, we thought it would be worthwhile to check the accessibility of this website.

Results

We observe different results between vantage points for the URL https://jensiat.io:

• Our vantage point in AS 48434 (Tebyan-e-Noor Cultural-Artistic Institute) has unrestricted access to the website.
• The vantage point in AS 16322 (Pars Online PSJ) received the locally routable IP 10.10.34.36 (the local IP for the blockpage), as opposed to 104.31.88.225 (which was observed in the successful page load from the AS we tested (AS 48434)). The fact that 10.10.34.36 is not a globally routable address, and differs from the globally routable address normally seen for jensiat.io indicates that there is DNS tampering occuring for this URL. For the end user, this means that he or she will see the blockpage that typically greets Iranian users attempting to access blocked content.

We observe that Iran’s censorship apparatus does not support requests sent using TLS encryption (i.e. URLs that begin with HTTPS); when a user attempts to initiate the TLS session it receives a connection refused error. This means that HTTPS websites that are redirected to this address will be blocked, and will not show anything (not even a blockpage).

• For the vantage point in AS 42337 (Respina Networks & Beyond PJSC), we observe a valid DNS reply with the IP address 104.31.88.225. However, upon attempting to connect to the site, the connection fails as the client received an injected HTTP reply from the censor containing HTML for the standard block page observed in Iran (Figure 1).

It is worth noting here that because the website uses HTTPS, the redirect does not work and results in an error. Thus, access is blocked, but no blockpage is shown. The result in this case (i.e. the website is inaccessible) is the same as in the case above, but the censorship method is different. Whereas in the case above access was blocked using DNS tampering (which rerouted the user to the blockpage), in this case access is blocked using packet injection (which prompted the connection to fail and left the user with an error message rather than the blockpage). The process of this packet injection is discussed in more detail below.

Below we show the error observed when we attempt to access https://jensiat.io from our vantage point in AS 42337 (Respina Networks & Beyond PJSC). The connection ends erroneously and it is flagged that an “unexpected TLS packet was received”.

$ curl-v https://jensiat.ioa
* Rebuilt URL to: https://jensiat.io/
*   Trying 104.31.88.225...
* Connected to jensiat.io (104.31.88.225) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 692 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* gnutls_handshake() failed: An unexpected TLS packet was received.
* Closing connection 0
curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received.

However, upon looking at the packet capture taken during this same session, we can see that this “unexpected TLS packet’’ was actually Iran’s standard blockpage (with an iframe tag pointing at 10.10.34.36, the local IP address for the blockpage):

17:47:35.242607 IP (tos 0x0, ttl 59, id 0, offset 0, flags [none], proto TCP (6), length 424)
    104.31.89.225.443 > [...].33300: Flags [F.], cksum 0x7ecb (correct), seq 68383665:68384037, ack 1555119495, win 27, options [eol], length 372
0x0000:  4500 01a8 0000 0000 3b06 dc5d 681f 59e1  E.......;..]h.Y.
0x0010:  05a0 da52 01bb 8214 0413 73b1 5cb1 3d87  ...R......s.\.=.
0x0020:  8011 001b 7ecb 0000 0000 0000 0000 0000  ....~...........
0x0030:  0000 0000 4854 5450 2f31 2e31 2034 3033  ....HTTP/1.1.403
0x0040:  2046 6f72 6269 6464 656e 0d0a 436f 6e6e  .Forbidden..Conn
0x0050:  6563 7469 6f6e 3a63 6c6f 7365 0d0a 0d0a  ection:close....
0x0060:  3c68 746d 6c3e 3c68 6561 643e 3c6d 6574  <html><head><met
0x0070:  6120 6874 7470 2d65 7175 6976 3d22 436f  a.http-equiv="Co
0x0080:  6e74 656e 742d 5479 7065 2220 636f 6e74  ntent-Type".cont
0x0090:  656e 743d 2274 6578 742f 6874 6d6c 3b20  ent="text/html;.
0x00a0:  6368 6172 7365 743d 7769 6e64 6f77 732d  charset=windows-
0x00b0:  3132 3536 223e 3c74 6974 6c65 3e3c 2f74  1256"><title></t
0x00c0:  6974 6c65 3e3c 2f68 6561 643e 3c62 6f64  itle></head><bod
0x00d0:  793e 3c69 6672 616d 6520 7372 633d 2268  y><iframe.src="h
0x00e0:  7474 703a 2f2f 3130 2e31 302e 3334 2e33  ttp://10.10.34.3
0x00f0:  363f 7479 7065 3d49 6e76 616c 6964 2053  6?type=Invalid.S
0x0100:  6974 6526 706f 6c69 6379 3d73 736c 2d62  ite&policy=ssl-b
0x0110:  6c6f 636b 616e 2022 2073 7479 6c65 3d22  lockan.".style="
0x0120:  7769 6474 683a 2031 3030 253b 2068 6569  width:.100%;.hei
0x0130:  6768 743a 2031 3030 2522 2073 6372 6f6c  ght:.100%".scrol
0x0140:  6c69 6e67 3d22 6e6f 2220 6d61 7267 696e  ling="no".margin
0x0150:  7769 6474 683d 2230 2220 6d61 7267 696e  width="0".margin
0x0160:  6865 6967 6874 3d22 3022 2066 7261 6d65  height="0".frame
0x0170:  626f 7264 6572 3d22 3022 2076 7370 6163  border="0".vspac
0x0180:  653d 2230 2220 6873 7061 6365 3d22 3022  e="0".hspace="0"
0x0190:  3e3c 2f69 6672 616d 653e 3c2f 626f 6479  ></iframe></body
0x01a0:  3e3c 2f68 746d 6c3e                      ></html>

Results for http://persian.euronews.com/, http://dargahpardakht.com/, http://www.bbc.com/persian, and http://www.samen-alhojaj.ir

• These sites are all blocked from all vantage points with an injected HTTP blockpage (without DNS redirection). The censor inspects unencrypted HTTP requests and upon detecting the censored URLs, injects a response containing the peyvandha.ir blockpage (Fig. 1) and then ends the connection with a TCP reset packet (results pages here, here, here, and here respectively).

Results for http://www.kajonline.ir/

• This website is available and can be accessed from AS 48434 (Tebyan-e-Noor Cultural-Artistic Institute) and AS 16322 (Pars Online PSJ).
• It is blocked when accessed from AS 42337 (Respina Networks & Beyond PJSC) with an injected HTTP response that redirects to the blockpage server and ends with a reset packet (results page here).

Results for https://www.zarinpal.com

• This page is available from all vantage points (results page here).

Summary of results

The table below indicates whether or not a given URL was accessible from each vantage point, and if not, which censorship method was used to block access.

Censorship methods

Are there any tentative conclusions we can draw about the broader implications of the censorship methods we’ve observed here? In particular, is there any noteworthy difference between packet injection, DNS tampering, and TLS connection errors vis-a-vis ease of circumvention?

DNS manipulation is one of the older forms of censorship that is easier to circumvent than the other two methods discussed below. Using encrypted DNS solutions easily obviates this attempt at information control, because if the censors can’t decrypt DNS queries, they won’t know when users are trying to access forbidden content.

HTTP blockpage injection – which looks inside each HTTP request to find blocked hostnames and injects a blockpage in response if it finds one – is more difficult to circumvent. This is because changing (or removing) the “Host” name in the request will result in an error on the server-side since most websites are hosted on shared servers and, without a proper Host header, the server won’t serve you the webpage you were looking for.

Websites that use HTTPS (HTTP over TLS) are among the most difficult for the authorities to block, since there’s no way to inject anything into an encrypted and authenticated connection without breaking the connection. Moreover, since TLS sites are also hosted on shared servers, blocking at the IP level will have collateral damage (all other websites hosted on the same IP will be blocked).

Iran previously implemented IP-level blocking for censored TLS websites, but it seems like they are now looking at SNIs as well. SNI (Server Name Indication) is a non-encrypted (cleartext) part of the TLS handshake protocol that tells the TLS server which Hostname should be contacted. Since SNI is not encrypted, the censor can see and act upon it (e.g. block communication). In the case of jensiat,io, the censors appear to be injecting a non-encrypted HTTP response, that causes the TLS connection to end in error.

Who is responsible for censorship?

Recent comments from ICT minister Mahmoud Vaezi suggested that Iran was looking into modifying its censorship methods, which were previously applied at the international gateway. In a previous report, we speculated that Iran was seeking to roll its censorship system back to the model of the early 2000s, where each ISP is responsible for blocking specific services and content.

However, the results of the present study suggest some centralised control of the administration of internet censorship in Iran. Evidence for this interpretation can be found in the TTL (time to live) values of injected packets.

TTL is an upper limit on the number of hops a data packet can take in a computer network. It is initially set by the sender of a packet, and reduced by one at each hop the packet takes en route to its destination. So if a packet has an initial TTL value of 64, and it is sent to a destination 8 hops away, the TTL value will be 56 once the packet reaches its destination. In other words, the more hops a packet takes in a network, the lower the TTL value becomes, meaning that the lower the TTL value, the greater the distance between sender and recipient of a packet in a network.

Different machines set different initial TTL values (it’s usually a power of 2: 32, 64,128 etc.). So if we receive a packet with a TTL value of 50, we can guess that the initial TTL value set by the sender of the packet was the closest (larger) power of two (64). We then subtract the TTL value of the packet we received (50) from the estimated initial value (64) to guess the number of hops the packet has taken to reach us (64 – 50 = 14 hops). This value, known as the TTL difference, allows us to conclude that the server is approximately 14 hops away from the client (us).

We then compare this distance (14 hops) to the number of hops taken by the injected packets (which injected the blockpage). So if the injected packets have TTL values of 123, we subtract this from the closest power of two (128), which gives us an estimates of the number of hops these packets took (128 – 123 = 5 hops).

Now, we compare the TTL difference (i.e. the number of hops taken) by the first packet (14) to the TTL difference of the injected packets (5). The difference (14 – 5 = 9 hops) is pretty significant, indicating that the distance between us and the source of the injected packets (i.e. 5 hops) is shorter than the distance between us and the server (14 hops). In other words, the censoring middlebox injecting the packets that lead to the blockpage sits between the client and the server.

So we can now roughly map the distances between the client, the packet injecting middlebox, and the server.

Client + five hops = middlebox; middlebox + 9 hops = server

The location of the middlebox vis-a-vis the client and server tells us two interesting things. First, the distance between the middlebox and the server (9 hops) helps us confirm that it is a censor. If the middlebox were close to the server, say just one hop away, then it’s possible that that middlebox could simply be a load balancer, which is legitimate. The fact that is it much further away in this case raises a red flag, which helps corroborate other pieces of evidence of censorship (e.g. the injected packets leading to the blockpage).

We can now be reasonably confident that censorship is taking place. The second piece of information that can be gleaned from the location of the middlebox is the level at which the censor operates. This is suggested by the distance between the client and the middlebox (5 hops, in the example above). If the distance were 1 or 2 hops, we could surmise that the censor was close to the client, perhaps operating at the ISP level. Since in the example above it is a bit further than that, we can assume that the censor is operating at a higher level than ISP.

To return to the present study, the TTL differences we observed for the packets injected by the censor were lower than the TTL differences for other packets (indicating the intervention of a censoring middlebox that is pretty far away from the server). However, the TTL differences were not so low as to imply that the censor was operating at the ISP level (note the TTL anomalies in the results pages here, here, here, and here). Taken together, this evidence suggests that it is more likely that the blocking is done by a centralized country-wide censorship apparatus than it being the responsibility of individual ISPs. However, further research would be needed to confirm this tentative conclusion.

Conclusion

This study has sought to investigate the accessibility of six websites from several vantages points in Iran. In the cases of http://www.bbc.com/persian and http://persian.euronews.com/, access was blocked from all the vantage points we tested. Yet in others, results were more mixed. For example, Jensiat.io was accessible from one AS, and blocked from the other two (using two different censorship methods). The most common blocking methods we have seen in this report are DNS manipulation, packet injection, and TLS connection errors.

This study has been narrow in scope, only examining 6 URLs. However, we have discovered a number of difference censorship methods, and some variation in accessibility among the different vantage points. Future research could examine the extent to which Iranian authorities prefer each censorship method, as well as the question of who is ultimately responsible the implementation of internet filtering.