bbs
bbs copied to clipboard
net4people
Cloudflare CDN looks blocked in Iran
Hello It's my first time contributing to bbs so sorry if I do anything wrong. Starting from hours ago, I think Iran blocked cloudflare's CDN. It looks like that Iran blocks all SNI's which go to cloudflare's IP address except cloudflare itself. I used scripts in this repo to check it. Have a look:
C:\Users\Hirbod>curl -v --trace-time -m 31 --resolve "www.google.com:443:104.21.2.133" https://www.google.com/
16:13:12.982105 * Added www.google.com:443:104.21.2.133 to DNS cache
16:13:12.987047 * Hostname www.google.com was found in DNS cache
16:13:12.990002 * Trying 104.21.2.133:443...
16:13:13.086126 * Connected to www.google.com (104.21.2.133) port 443 (#0)
16:13:13.090785 * schannel: disabled automatic use of client certificate
16:13:13.095734 * ALPN: offers http/1.1
16:13:28.179172 * schannel: failed to receive handshake, SSL/TLS connection failed
16:13:28.184461 * Closing connection 0
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
C:\Users\Hirbod>
However:
C:\Users\Hirbod>curl -v --trace-time -m 31 --resolve "www.cloudflare.com:443:104.21.2.133" https://www.cloudflare.com/
16:15:28.134425 * Added www.cloudflare.com:443:104.21.2.133 to DNS cache
16:15:28.139470 * Hostname www.cloudflare.com was found in DNS cache
16:15:28.143001 * Trying 104.21.2.133:443...
16:15:28.238850 * Connected to www.cloudflare.com (104.21.2.133) port 443 (#0)
16:15:28.243799 * schannel: disabled automatic use of client certificate
16:15:28.248615 * ALPN: offers http/1.1
16:15:28.448943 * ALPN: server accepted http/1.1
16:15:28.452648 > GET / HTTP/1.1
16:15:28.452648 > Host: www.cloudflare.com
16:15:28.452648 > User-Agent: curl/7.83.1
16:15:28.452648 > Accept: */*
16:15:28.452648 >
16:15:28.584464 * schannel: failed to decrypt data, need more data
16:15:28.589000 * Mark bundle as not supporting multiuse
16:15:28.591791 < HTTP/1.1 200 OK
16:15:28.594221 < Date: Mon, 10 Oct 2022 12:45:28 GMT
16:15:28.597058 < Content-Type: text/html; charset=utf-8
... Cotinues
Wireshark also shows that data nothing is received after client hello:
Thanks for this. I can partially confirm your report. I found some names other than www.cloudflare.com that are responsive, but most SNIs receive nothing after Client Hello, as you say.
However, I tried the name reestr.rublacklist.net (which is hosted on Cloudflare), and it does work from Iran. Then again, I tried investing.com, also hosted on Cloudflare, and it does not work.
OK curl -I -v https://www.cloudflare.com/
OK curl -I -v https://blog.cloudflare.com/
OK curl -I -v https://static.cloudflareinsights.com/beacon.min.js
OK curl -I -v --connect-to ::www.cloudflare.com: https://reestr.rublacklist.net/
OK curl -I -v https://reestr.rublacklist.net/
timeout curl -I -v --connect-to ::www.cloudflare.com: https://www.example.com/
timeout curl -I -v --connect-to ::www.cloudflare.com: https://www.google.com/
timeout curl -I -v --connect-to ::www.cloudflare.com: https://investing.com/
timeout curl -I -v https://investing.com/
Testing from the U.S., all the commands work. (Except the non-Cloudflare SNIs, which result in an SSL error, which is expected.)
OK curl -I -v https://www.cloudflare.com/
OK curl -I -v https://blog.cloudflare.com/
OK curl -I -v https://static.cloudflareinsights.com/beacon.min.js
OK curl -I -v --connect-to ::www.cloudflare.com: https://reestr.rublacklist.net/
OK curl -I -v https://reestr.rublacklist.net/
error curl -I -v --connect-to ::www.cloudflare.com: https://www.example.com/
error curl -I -v --connect-to ::www.cloudflare.com: https://www.google.com/
OK curl -I -v --connect-to ::www.cloudflare.com: https://investing.com/
OK curl -I -v https://investing.com/
Thanks for the report. I can also partially confirm your findings using active measurements
It may have something to do with TLS fingerprint, and be broader than Cloudflare generally. These requests to sites on the Azure and Fastly CDNs also time out for me using curl:
$ curl -I -v https://ajax.aspnetcdn.com/
* Trying 152.199.19.160:443...
* TCP_NODELAY set
* Connected to ajax.aspnetcdn.com (152.199.19.160) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
$ curl -I -v https://cdn.sstatic.net/
* Trying 151.101.1.69:443...
* TCP_NODELAY set
* Connected to cdn.sstatic.net (151.101.1.69) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
However, Snowflake rendezvous using the cdn.sstatic.net domain does work for me at the moment (using the below torrc). The difference may have to do with the difference between the curl and golang TLS fingerprints.
UseBridges 1
DataDirectory datadir
SocksPort auto
ClientTransportPlugin snowflake exec ./client -log snowflake.log
Bridge snowflake 192.0.2.3:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ front=cdn.sstatic.net ice=stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
However, Snowflake rendezvous using the cdn.sstatic.net domain does work for me at the moment
But Snowflake rendezvous using the ajax.aspnetcdn.com domain name (à la https://github.com/net4people/bbs/issues/131#issuecomment-1270782707) does not work for me now. It was working yesterday or the day before.
UseBridges 1
DataDirectory datadir
SocksPort auto
ClientTransportPlugin snowflake exec ./client -log snowflake.log
Bridge snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.azureedge.net/ front=ajax.aspnetcdn.com ice=stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478
2022/10/10 16:40:39 Negotiating via HTTP rendezvous...
2022/10/10 16:40:39 Target URL: snowflake-broker.azureedge.net
2022/10/10 16:40:39 Front URL: ajax.aspnetcdn.com
2022/10/10 16:40:49 WebRTC: closing DataChannel
2022/10/10 16:40:49 WebRTC: closing PeerConnection
2022/10/10 16:40:49 WebRTC: Closing
2022/10/10 16:40:49 WebRTC: net/http: TLS handshake timeout Retrying...
I doubt it's because of fingerprint. At least some of them could be. Because I cannot access my own server which I do have nginx on it via chrome. However, I can access it if I use a proxy.
From Cloudflare Radar: https://twitter.com/CloudflareRadar/status/1579564658444206080
well there is another scenario when you want to disguise traffic as a normal looking website but there is a profiler thing that set them a limited amount of traffic to them when its reached it will be done for that machine. it's hard to know which is happening but heavy tls fingerprinting is acitve today in iran.
Apparently, this blockage is lifted. Now It's possible to run the following command:
C:\Users\Hirbod>curl -v --trace-time -m 31 --resolve "www.google.com:443:104.21.2.133" https://www.google.com/
08:58:17.075901 * Added www.google.com:443:104.21.2.133 to DNS cache
08:58:17.081857 * Hostname www.google.com was found in DNS cache
08:58:17.085395 * Trying 104.21.2.133:443...
08:58:17.186531 * Connected to www.google.com (104.21.2.133) port 443 (#0)
08:58:17.191667 * schannel: disabled automatic use of client certificate
08:58:17.196291 * ALPN: offers http/1.1
08:58:17.297944 * schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
08:58:17.307284 * Closing connection 0
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
C:\Users\Hirbod>