This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Disparity between reported results from probes and actual situation?
- Previous message (by thread): [atlas] Disparity between reported results from probes and actual situation?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Cameron Steel
tugzrida at gmail.com
Sat Sep 25 03:23:00 CEST 2021
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: </ripe/mail/archives/ripe-atlas/attachments/20210925/683cd192/attachment.html>
- Previous message (by thread): [atlas] Disparity between reported results from probes and actual situation?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]