Hi Ishan,
In those two measurements, it certainly seems that most probes are connecting to Mega/Telegram and obtaining the correct TLS certificates.

To verify this on your machine, use openssl and ensure the SHA1 fingerprints match those reported in the Atlas measurements:

$ echo "Q" | openssl s_client -connect mega.nz:443 -servername mega.nz | openssl x509 -noout -fingerprint -sha1

$ echo "Q" | openssl s_client -connect t.me:443 -servername t.me | openssl x509 -noout -fingerprint -sha1


If you don’t get matching fingerprints there, have a look whether the IP addresses returned by DNS are correct:

$ host mega.nz

$ host t.me


If that’s all fine, then you should also be able to load the addresses with curl:

$ curl -i https://mega.nz

$ curl -i https://t.me

For mega, the expected response is 200 OK, and for t.me, a 302 redirect to telegram.org


Let us know how far you get. There’s many ways to prevent access to a site: blocking or modifying DNS, not routing traffic to certain IPs, intercepting HTTP, etc. It’s possible that whatever method is used here would block say, web browser access but not a probe TLS connection, though that would be a little odd.

Another thing to note is that both mega and telegram publish IPv6 records for those hostnames. The measurements you ran that showed a working connection were set to IPv4-only. It may be the case that IPv4 access is not blocked, however IPv6 access is.


Cameron Steel
tugzrida@gmail.com

On 25 Sep 2021, at 02:26, Ishan Jain <ishanjain28@gmail.com> wrote:

Hi there,


There are some sites that are being blocked by ISPs here in India. The two cases I checked are,

1. mega.nz

2. t.me

In some cases, It's the Consumer ISP that's blocking access to these domains and in other cases it's the upstream providers like Tata(AS17908) that are blocking access to these sites.

To figure out how many probes were effected, I ran 2 TLS tests. The results of those tests are here,

1. https://atlas.ripe.net/measurements/32358061/

2. https://atlas.ripe.net/measurements/32358052/


As you'll see that almost every probe received correct TLS Certificate with mega.nz and excluding 4-5 probes, All the other probes received correct certificates for t.me. These measurements include 2 probes that I run in AS9829 and AS45609. Somehow, Both of my probes reported that they received the correct/valid certificate in both of these measurement when it doesn't appear to be true.

I am presented with connection closed error when accessing these sites over HTTP and a connection reset error when accessing these sites over HTTPS over both WANs used by the two probes.


Have I misunderstood TLS tests? I am not sure what is happening here and I really appreciate any insight I can get on these results. I have also included the relevant section from the logs of 1 of my probes.


atlas_run: looking for 'evsslgetcert -4 -p 443 -h mega.nz -A "32358061" 66.203.127.18'
eooqd: found cmd 'evsslgetcert' for 'evsslgetcert -4 -p 443 -h mega.nz -A "32358061" 66.203.127.18'
eooqd: atlas_run: argv[0] = 'evsslgetcert'
eooqd: atlas_run: argv[1] = '-4'
eooqd: atlas_run: argv[2] = '-p'
eooqd: atlas_run: argv[3] = '443'
eooqd: atlas_run: argv[4] = '-h'
eooqd: atlas_run: argv[5] = 'mega.nz'
eooqd: atlas_run: argv[6] = '-A'
eooqd: atlas_run: argv[7] = '32358061'
eooqd: atlas_run: argv[8] = '66.203.127.18'
eooqd: atlas_run: argv[9] = '-O'
eooqd: atlas_run: argv[10] = '/var/atlas-probe/data/new/ooq.2'
eooqd: init returned 0x738200 for 'evsslgetcert -4 -p 443 -h mega.nz -A "32358061" 66.203.127.18'
eooqd: check_resolv_conf2: no change (time 1632496526)
msgbuf_read: buf_read failed
ooqd: command is done for cmdstate 0x738200
sslgetcert_delete: state 0x738200, index 0, busy 0
total size in dir: 5982
httppost: before getaddrinfo
httppost: before connect
httppost: sending request
posting file '/var/atlas-probe/data/out/ooq/2'
httppost: getting result
httppost: getting reply headers
httppost: got line 'Server: nginx'
httppost: got line 'Date: Fri, 24 Sep 2021 15:56:32 GMT'
httppost: got line 'Content-Type: text/plain'
httppost: got line 'Transfer-Encoding: chunked'
httppost: got line 'Connection: close'
httppost: writing output
httppost: chunked 1, content_length -1
httppost: got chunk line '3'
httppost: chunk data 'OK



Regards
Ishan Jain