[atlas] Disparity between reported results from probes and actual situation?

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 at gmail.com

> On 25 Sep 2021, at 02:26, Ishan Jain <ishanjain28 at 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20210925/683cd192/attachment.html>