An Eventful Few Weeks in Iran: DNS Tampering, Content-Type Filtering and SSL Blocking on Google

As is the historical trend, an eventful month of political and economic instability, not the least reflected in the return of Mehdi Hashemi, the dive of the Toman, Ahmadinejad at the U.N. General Assembly, and the arrest of Ali Akbar Javanfekr, has led to an increase in the aggressiveness of Internet censorship by the state. This was most evident in the filtering of SSL access to Google and Gmail, however, what has received less attention are two development, the filtering of foreign-hosted media files and the fulltime implementation of DNS tampering. Since such moments are the time when the government tips its hand on what it can do, I offer some brief notes.

Google services were filtered starting Sep 24 2012 through the targeted blocking of HTTPS connections on IP addresses within the round-robin DNS records for encrypted.google.com, google.com, accounts.google.com, youtube.com, mail.google.com, and gmail.com. Representatives of the telecommunications sector were quoted attributing the blocking as an inability to differentiate YouTube with other Google services. This, however, was one of a multitude of reasons that were given and contrary to Iran having successfully blocked the site since at least Summer 2009. My belief in this case was that blocking was accomplished through simple port restrictions, rather than a more sophisticated approach such as deep packet inspection of traffic. It is also worth noting that Iran was not completely thorough in blocking all active Gmail addresses.

[root@nami results]# tcptraceroute 173.194.69.19 -p 80
traceroute to 173.194.69.19 (173.194.69.19), 30 hops max, 40 byte packets
 1  [hop-1]  0.721 ms  0.862 ms  1.024 ms
 2  [hop-2]  0.740 ms  0.900 ms  1.010 ms
 3   (62.220.96.114)  1.089 ms  1.319 ms  1.258 ms
 4  217.218.190.173 (217.218.190.173)  0.909 ms  1.063 ms  1.066 ms
 5  78.38.119.237 (78.38.119.237)  0.875 ms  0.992 ms  0.918 ms
 6  78.38.119.222 (78.38.119.222)  1.082 ms  1.056 ms  1.209 ms
 7  10.10.36.221 (10.10.36.221)  1.092 ms 10.10.36.253 (10.10.36.253)  1.368 ms 10.10.36.117 (10.10.36.117)  1.273 ms
 8  92.50.192.145 (92.50.192.145)  80.031 ms  79.992 ms  79.821 ms
... [international]
13  bk-in-f19.1e100.net (173.194.69.19)  440.813 ms  440.784 ms  440.574 ms
[root@nami results]# tcptraceroute 173.194.69.19 -p 443
traceroute to 173.194.69.19 (173.194.69.19), 30 hops max, 40 byte packets
 1  [hop-1]  0.944 ms  1.106 ms  1.310 ms
 2  [hop-2]  0.954 ms  1.181 ms  1.433 ms
 3   (62.220.96.114)  1.245 ms  1.312 ms  1.523 ms
 4  217.218.190.173 (217.218.190.173)  0.937 ms  1.130 ms  1.487 ms
 5  78.38.119.237 (78.38.119.237)  0.688 ms  0.955 ms  0.701 ms
 6  78.38.119.222 (78.38.119.222)  0.790 ms  1.191 ms  0.895 ms
 7  * * *
... * * *
30  * * *

Lastly, it was noted from comments on social media and testing that the implementation of this filtering was not uniform; Gmail became blocked in some locations earlier than others. As the fate of Google was announced a few hours before implementation this would seem to indicate that some ISPs jumped the gun before the TCI acted to prevent access for nearly the entire country.

DNS Tampering

While one would assume that the Telecommunication Company of Iran (TCI) had figured out DNS tampering in preparation for its August 2011 attempt to man-in-the-middle Gmail, specific instance and data have not been readily accessible. On or shortly before October 2 2012, DNS requests for ‘youtube.com’ began to return the improper address of 10.10.34.34, otherwise known as the domestic filtered site page.

22:37:08.987441 IP (tos 0x0, ttl  64, id 33216, offset 0, flags [none], proto: UDP (17), length: 57) [host].35934 > 8.8.8.8.53: [udp sum ok]  25198+ A? youtube.com. (29)
22:37:08.989841 IP (tos 0x0, ttl  57, id 0, offset 0, flags [none], proto: UDP (17), length: 73) 8.8.8.8.53 > [host].35934: [udp sum ok]  25198 q: A? youtube.com. 1/0/0 youtube.com. A 10.10.34.34 (45)
22:37:12.659425 IP (tos 0x0, ttl  64, id 33222, offset 0, flags [none], proto: UDP (17), length: 56) [host].47877 > 8.8.8.8.53: [udp sum ok]  55700+ A? google.com. (28)
22:37:12.805491 IP (tos 0x0, ttl  43, id 10830, offset 0, flags [none], proto: UDP (17), length: 152) 8.8.8.8.53 > [host].47877:  55700 q: A? google.com. 6/0/0 google.com. A 173.194.70.102, google.com.[|domain]

Watching data in transit, specifically the TTL of packets,  it would appear that the false answer is being returned seven hops away from our host, therefore we can determine the probable location of the device on a traceroute.

 1  [hop-1] 0.851 ms  1.444 ms  1.391 ms
 2  [hop-2]  1.323 ms  1.267 ms  1.205 ms
 3   (62.220.97.124)  1.144 ms  1.090 ms  1.031 ms
 4  p2p.huawei-rtr.aryasat.dist-sw.aryasat.ir (78.154.32.177)  3.787 ms  2.546 ms  4.669 ms
 5  78.38.255.100 (78.38.255.100)  1.425 ms  1.304 ms  1.435 ms
 6  10.10.53.197 (10.10.53.197)  1.812 ms  1.947 ms  1.989 ms
 7  10.10.53.34 (10.10.53.34)  1.557 ms  2.015 ms nyk-b7-link.telia.net (213.248.99.177)  209.877 ms
 8  ldn-b4-link.telia.net (213.155.129.33)  146.864 ms ldn-bb1-link.telia.net (80.91.248.90)  172.420 ms  172.289 ms
... [international]
15  google-public-dns-a.google.com (8.8.8.8)  1294.457 ms  454.992 ms *

It would appear then that the false answers are originating out of the private network that acts as Iran’s international gateway, around 10.10.53.34 and mostly likely operated by the Data Communication Affairs within the TCI. Additionally, setting the +TCP flag on dig returned the legitimate result eleven records in the 173.194.43.0/24 IP space. While it appears all international DNS requests are subject to inspection, only UDP traffic triggers false answers.

It is unclear if other domains are subject to tampering, however, false answers are still be returned at the time of writing. This new technique should be disconcerting regardless of the availability of anti-filtering tools and VPN services; unless the tool properly tunnels DNS traffic and authenticates itself as the valid destination to the user, an intermediary may be able to control the user’s online activities and even completely hijack their connection for surveillance. Further investigation on the extent of this monitoring will be presented in a forthcoming research project developed for the Iran Media Program at the University of Pennsylvania.

Filtering Based Content-Type Header

In perhaps the most literal possible parallel to the government’s jamming of international satellite broadcasts, as a response to riots over the rapid devaluing of currency, Iran appears to have blocked foreign-hosted media files for several days beginning around October 6 2012. Reportedly, this blocking targeted audio (.MP3), video (.MP4, .AVI) and Adobe Flash/Shockwave content. Attempts to access these files would result in a hanging request returning no data, which differs from normal blocking that generates a 403 ‘Forbidden’ HTTP response code, a HTML page and a TCP RST packet. Renaming an mp3 file to an alternative extension such as ‘.rawr’ resulted in successful transfer. Upon the trigger of this rule, the transmission of data between the client and server is blocked for the session (most likely determined based on either source ports or packet numbers).

After investigation, it appears that the trigger is based on HTTP headers, rather than the file extension. A simple PHP page returning only the ‘Content-Type: audio/mpeg’ would trigger the described behavior. It was previously known that the TCI’s filtering is done based on inspection of the GET and HOST headers; this filtering is unique in that context because it is based on returned data, rather than sent requests. The nature of the failure made research into the location of these mechanisms difficult, and the interference had ended by the time of writing.

Private Address Space Use

Lastly, in a paper published to the open access research site arXiv recently, I detail the particularly unique routing of ‘private’ IP addresses within Iran’s domestic network.

Abstract

While funding agencies have provided substantial support for the developers and vendors of services that facilitate the unfettered flow of information through the Internet, little consolidated knowledge exists on the basic communications network infrastructure of the Islamic Republic of Iran. In the absence open access and public data, rumors and fear have reigned supreme. During provisional research on the country’s censorship regime, we found initial indicators that telecommunications entities in Iran allowed private addresses to route domestically, whether intentionally or unintentionally, creating a hidden network only reachable within the country. Moreover, records such as DNS entries lend evidence of a ‘dual stack’ approach, wherein servers are assigned a domestic IP addresses, in addition to a global one. Despite the clear political implications of the claim we put forward, particularly in light of rampant speculation regarding the mandate of Article 46 of the ‘Fifth Five Year Development Plan’ to establish a “national information network,” we refrain from hypothesizing the purpose of this structure. In order to solicit critical feedback for future research, we outline our initial findings and attempt to demonstrate that the matter under contention is a nation-wide phenomenom that warrants broader attention.