Shared publicly  - 
I have pretty definitive proof that Iran is doing ip-and-port based filtering of SSL.

Filtering is being done by eg This hop is after my source's ISP. The filtering IPs are owned by ITC, Iran's central telco. It's (h/t to Tor team for that).

Filtering targets all IPs, some but not all IPs, probably more. Haven't attempted a broad scan. It's a simple connection drop; filtered connections just time out.

It is not based on SSL handshake signature; testing SSL on nonstandard ports worked successfully, and testing non-SSL on :443 of target IPs was blocked.

I'm not sharing screencaps in order to protect my source, but tests included TCP traceroutes on different IP/port combinations and some simple use of curl.

ETA 2/10: Further testing done. Conclusions:

1. IP-and-port filtering for some IPs
2. SSL protocol filtering on standard ports for targeted IPs / sites
3. No request header filtering
4. Some IPs / sites NOT SSL protocol or port filtered!
5. All Tor filtered, even unpublished proxies

I'm not going to openly publish what went through to prevent it getting blacklisted and useless for testing, but it was a full normal https://something:443 connection, green lock w/ verified serial # and all.

ETA2 2/11: SSL to previously working site now down. SSL to internal Iranian site up. Don't yet know why on either.

obfsproxy is working successfully from inside Iran and enabling full Tor access.


List of bridge relays being distributed privately. Not public to prevent relay IPs getting blacklisted, but contact me or anyone on the tor dev team to get a copy.

Help censored users:

ETA3 2/11: SSL w/out tor is currently erratic. and sometimes get through, as do some other sites; eg does not. Traffic is still going through the same filter server. Still don't know cause; SSL certs of connections that go through do confirm as legit.

Still to test, will update post:
* ssh on standard & nonstandard ports
* nonstandard ssl ports

More info: (based in part on my info)
Kamyar Mohajerani's profile photoJavier B's profile photoSai (saizai)'s profile photoShava Nerad's profile photo
By filtering you mean they are dropping the connections? I thought it was known that they were blocking Google and such.
+Sai So they're forcing people into the non-encrypted sites, which they presumably monitor. (Someday I'll share a funny story about Iran's monitoring of paper mail from the U.S.).
+Kee Hinckley Monitor, keyword block, etc. This is not the only filtering that's going on of course.
I live in Iran. Since yesterday, at least on the three ISPs I get Internet access from, they're blocking ALL TLS/SSL traffic. This includes STARTSLL on other protocols such as IMAP and SMTP. The blocking is not IP based, because I do receive the SYN/ACKs from servers I try to connect to, and not port based, as it blocks SSL/TLS on ANY tcp port range. This is absolutely unprecedented, and is probably the beginning of the so called "National Internet(!!!!)" project from the Islamic regime.
+Kamyar Mohajerani The testing I did yesterday showed that SSL connections on nonstandard ports on filtered IPs, and on standard ports on unfiltered IPs, were both permitted. I expect that they are doing other filtering as well; previously eg they tried to disable Tor by SSL signature detection, and search tampering implies DPI.

What have you tried that indicated more severe filtering?
Well I certainly couldn't have tested all IPs/ports on the net but actually did try a list of https websites I could think of plus whatever I could find via google (all on port 443), and also SSL on IMAP/POP/SMTP with gmail (non 443 ports) . I also see the exact same behavior on TOR trying to connect to nodes on ports other than 443. They seem to do DPI and block everything right after the client's "hello". Currently the TOR network is unreachable from here. As I mentioned. I receive SYN/ACKs from server IP but can't be really sure they come from the "actual" destination server.
+Kamyar Mohajerani Try this: TCP traceroute (eg on Windows, use tracetcp + winpcap) to,,, and

Similarly you can try curl -vvvvv,, etc. combinations of http/https, :80/:443, and IP.

If your results are the same as my source's, then you'll find that only :443 connections one one of those IPs of those gets blocked at the filter, regardless of protocol. We didn't test ports other than 80 and 443; could well be more ports are blocked.

My source reports being unable to connect to tor since this morning. :(
Port 80 connections have long been redirected to Potato Wall intermediary servers so AFAIK it has been (and still is) impossible to have a TLS on :80. Of course I see port open on tcptraceroute but that would not be the actual server responding. I tried the IPs you mentioned but I really don't get how your curl tests are going work as there's no https server on :80 on the other side. (it's stuck right after the client hello anyways).
I finally got access to a box outside the wall and checked tcpdumps on boths sides. It seems like my guess was right. They also block all ssh (tried only v2).
+Kamyar Mohajerani The :80 https results will fail correctly during the SSL handshake if it's not being filtered; they'll timeout before even starting the handshake if it is. It's a simple test.

Likewise, tcp traceroute shows :443 requests on filtered IPs getting cut off at the filter, whereas :80 requests go through. Of course they still go through the filter, so it might be tampering, but that's at least a different problem.

SSH: protocol blocked or just :22? I can get a test IP set up on nonstandard port if needed.
Seems like protocol blocking. Tried other ports as well. We see the client hello on the server but nothing's received on the client side afterwards. Would appreciate if you could help with running some more test. Please PM me with your setup.
Hi. The blockade is filtering the protocol only with IPs outside Iran? or local https websites are inaccessible too?
OP updated: obfsproxy successful! Yay for the Tor team.
The Tor Project is mobilized to help. and specifically for the geek-inclined.

[side musing, to be turned into a more elaborate essay when I'm not on my phone waiting for a prescription at the pharmacist, heh]

I continue to be amazed. People talk about this as "cyberwar," but that's often bloviating. We may as well talk about Monsanto or Wall Street as a potential instrument of agriwar or econwar.

What we have here, as we have with all those situations, is a dimension of economic/media expression (agriculture, banking, communication) being used as a football of politics and power-over by oppressive government. It's another tool for another interested party.

The more cogent difference to the everyday is that visceral understanding we have - even non-tech minds in this abstract frontier - that code really is law.

Even though Monsanto exerts that genetic code is law in its GMO manipulations, in the realm of biology, we don't see +Larry Lessig's natural law explicitly reflected in their case against the organic farmers, but it lurks as subtext. Science is law. Code is law.

Memetically to the outsider, it is rubbing shoulders in the popular nightmare with Mary Shelley - "code is law" becomes "I have created life" and "I have rewritten God's, nature's, or man's law."

This is why they fear and hate us, and consider us a "they." Well, one reason.

Wall Street asserts that their market's Code's invisible hand trumps (you should excuse the pun) the trivial concerns of land based laws and ethics in very fundamental ways. They present outcomes as inevitable and unprosecutable faits accomplis to governments in ways that hold the world economy over an abyss if dogma is questioned, and probably seem as mystical and opaque and far more powerful than any net neutrality advocate.

Part of my life work is hoping to find a way to unravel or slice or fully analyze this Gordian knot.
Add a comment...