- ripe-atlas - mailman.ripe.net

Access to probes and documents
by Mccherry, Paul (Postgraduate Researcher) 30 Jan '23

30 Jan '23

Althiough I am logged in when trying to access various probes I do not seem to have the rights, probes such as 91,353,365,3094.... Additionally I noticed I cannot access any documents on RIPE labs such as 'RIPE IPmap: geolocating routes across the internet' or 'Five proposals for a better RIPE Atlas.' Can anyone resolve these access rights please ? Regards Paul McCherry Phd Researcher Lancaster University

2 2

TLS Certificate probes fail ("handshake failure") against Vercel servers
by Daniel Kahn Gillmor 25 Jan '23

25 Jan '23

Hi RIPE Atlas folks-- I noticed today that using the "SSL" probe (gathering X.509 certificates from a TLS endpoint) appears to fail against servers operated by Vercel. the failure is a uniform "handshake failure" according to the web interface. I think this might be a bug in the probe's implementation of the client side of TLS. Where could i find the specific implementation of that probe type so that i can debug it further? Or, if this is a known issue, where can i read up on it in more detail? I've demonstrated this by probing Vercel's own servers, since they appear to be eating their own dogfood. You can see this with measurement 49131334: https://atlas.ripe.net/measurements/49131334/#probes here is the definition of the query i made: { "definitions": [ { "target": "vercel.com", "af": 4, "port": 443, "hostname": "vercel.com", "description": "SSL measurement to vercel.com", "resolve_on_probe": true, "skip_dns_check": false, "type": "sslcert" } ], "probes": [ { "type": "area", "value": "WW", "requested": 10 } ], "is_oneoff": true, } This is pretty odd, since normal TLS clients appear to be able to connect to them fine. Here's me running a manual handshake debugger against vercel.com's servers: $ gnutls-cli-debug vercel.com GnuTLS debug client 3.7.8 Checking vercel.com:443 whether the server accepts default record size (512 bytes)... yes whether %ALLOW_SMALL_RECORDS is required... no whether we need to disable TLS 1.2... no whether we need to disable TLS 1.1... no whether we need to disable TLS 1.0... no whether %NO_EXTENSIONS is required... no for TLS 1.0 (RFC2246) support... no for TLS 1.0 (RFC2246) support with TLS 1.0 record version... no for TLS 1.1 (RFC4346) support... no fallback from TLS 1.1 to... failed for TLS 1.2 (RFC5246) support... yes for TLS 1.3 (RFC8446) support... yes for known TLS or SSL protocols support... yes TLS1.2 neg fallback from TLS 1.6 to... failed (server requires fallback dance) for HTTPS server name... Vercel for certificate chain order... sorted for safe renegotiation (RFC5746) support... yes for encrypt-then-MAC (RFC7366) support... no for ext master secret (RFC7627) support... no for heartbeat (RFC6520) support... no for version rollback bug in RSA PMS... yes whether the server ignores the RSA PMS version... yes whether small records (512 bytes) are tolerated on handshake... yes whether cipher suites not in SSL 3.0 spec are accepted... yes whether a bogus TLS record version in the client hello is accepted... yes whether the server understands TLS closure alerts... yes whether the server supports session resumption... yes for anonymous authentication support... no for RSA key exchange support... no |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice for ephemeral Diffie-Hellman support... yes |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice for RFC7919 Diffie-Hellman support... no for ephemeral EC Diffie-Hellman support... yes for VKO GOST-2012 (draft-smyshlyaev-tls12-gost-suites) support... no for curve SECP256r1 (RFC4492)... yes for curve SECP384r1 (RFC4492)... yes for curve SECP521r1 (RFC4492)... yes for curve X25519 (RFC8422)... yes for AES-GCM cipher (RFC5288) support... yes for AES-CCM cipher (RFC6655) support... no for AES-CCM-8 cipher (RFC6655) support... no for AES-CBC cipher (RFC3268) support... no for CAMELLIA-GCM cipher (RFC6367) support... no for CAMELLIA-CBC cipher (RFC5932) support... no for 3DES-CBC cipher (RFC2246) support... no for ARCFOUR 128 cipher (RFC2246) support... no for CHACHA20-POLY1305 cipher (RFC7905) support... yes for GOST28147-CNT cipher (draft-smyshlyaev-tls12-gost-suites) support... no for MD5 MAC support... no for SHA1 MAC support... no for SHA256 MAC support... no for GOST28147-IMIT MAC (draft-smyshlyaev-tls12-gost-suites) support... no for max record size (RFC6066) support... no for OCSP status response (RFC6066) support... yes $ Thanks for any pointers, --dkg

2 2

Duplicate packet detection in traceroute results
by Ana Custura 20 Jan '23

20 Jan '23

Hi everyone, Just a question on how Atlas detects duplicate ('dup') packets in a traceroute. Is the 'dup' field added to a result when two received packets are exactly the same, regardless of whether they were received for a different initial TTL? Or are any packets that were unexpectedly received for a specific TTL marked as duplicates (e.g. if you receive 6 replies from 2 different IP addresses to the 3 initial packets sent with TTL 1, will 3 of these replies be marked as duplicates)? Thanks for your help! Regards, Ana

2 2

Re: [atlas] ripe-atlas Digest, Vol 137, Issue 8
by Geert Jan de Groot 19 Jan '23

19 Jan '23

On 09/01/2023 11:32, ripe-atlas-request(a)ripe.net wrote: > The hardware probes are fully managed by RIPE NCC, and their only purpose is to execute measurements. I agree here, whether to update is up to RIPE NCC. > On software probes, RIPE NCC is not in control of the unit. The software probe may run other services and updating is up to its local sysadmin. Consider operating system updates, which are updated by RIPE NCC on the hardware probes, but cannot be updated on software probes. > > To automatically update, the solution here is a simple CRON job which executes yum -q update atlasswprobe periodically (say once per day or so), which was the solution that was part of the RPM up to 5080. Would it help if we add this to the instructions? One question perhaps is if a probe running very obsoleted probe code, is useful or perhaps at some time probes older than version 1234 should not be used for pool measurements? For instance, release 2345 enables measurements on 240/12 while older releases, including release 2344, 240/12 is broken. Then, having probes with software 2344 or lower will give bias on measurements for 240/12. And for that reason I wonder if it makes sense to have a policy to "phase out" probes that are running obsoleted code, however well intended? Geert Jan

2 1

probes on mobile opérateurs
by Cristel Pelsser 13 Jan '23

13 Jan '23

Hello, We are looking for RIPE atlas probes that are connected to mobile operators. Could you drop me an email with the id of the probe if you have such a probe? We found some but would like to enlarge our study. Best regards, Cristel

4 3

Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
by Robert Kisteleki 11 Jan '23

11 Jan '23

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

15 24

V3 Probe: USB Flash Drive Filesystem Corrupted
by ripe.net＠toppas.net 11 Jan '23

11 Jan '23

Hello, i have two v3 probes and i'm experiencing issues: "USB Flash Drive Filesystem Corrupted" I have tried multiple USB Sticks, including brand new ones and also sticks from "good" brands like Lexar and Sandisk. The issue is not permanent, the error appears and disappears from time to time: 2022-12-22 @ 12:14:04 UTC Probe auto-tagged Your probe #xxxxx was automatically tagged as "system: Flash drive filesystem corrupted" 2022-12-22 @ 18:14:42 UTC Probe auto-untagged Your probe #xxxxx was automatically untagged as "system: Flash drive filesystem corrupted" This leads me to the thought, that the flash storage is not the real problem. It's unlikely, since i tried multiple dongles. Could it be possible, that not the flash storage is broken, but the speed of the USB dongles is too low? All dongles I tried were USB 2.0, not 3.0, since the TP-Link TL-MR3020 is not USB 3.0 capable anyway. But maybe USB 3.0 is a better choice? What do you think? BR, Simon

2 6

Proposal: Add support for STARTTLS measurements [STARTTLS]
by Robert Kisteleki 09 Jan '23

09 Jan '23

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

4 3

Re: [atlas] Ability to traceroute to 240/4 - software vs. hardware probes
by Seth David Schoen 09 Jan '23

09 Jan '23

Hi! I noticed that Phillip Homburg merged a RIPE Atlas client patch in November of last year, based on our request, that removes the Atlas probe's inability to test addresses in 0/8 and 240/4. https://github.com/RIPE-NCC/ripe-atlas-probe-measurements/commit/59475f848b… So, I just tried a couple of measurements to 240.1.2.3 to see how Atlas would handle them: https://atlas.ripe.net/measurements/48100582/ https://atlas.ripe.net/measurements/48100585/ (I don't expect these to succeed, as no part of 240/4 is publicly announced in BGP; the interesting information to be garnered from this isn't whether the probes succeed, but how they fail.) For the first measurement, with ping, 6 hardware probes and 4 software probes all gave the same result: "Unreachable" (which is what you would get if you ran this on any ordinary Internet host with command-line ping). For the second measurement, with traceroute, 6 hardware probes all actually attempted the traceroute (getting failures after some small number of network hops), while 3 software probes all reported back "!address not allowed". What could account for the difference in how hardware and software probes handle this task? I would have thought that the change from last November would make software probes willing to attempt these.

2 2

Magellan report on built-in measurement 1
by Ernst J. Oud 09 Jan '23

09 Jan '23

Asked this question before but that post did not make it to the mailing list: Why can’t Magellan report on built-in measurement 1 (first hop)? It always shows “No packets found”. Met vriendelijke groet/Regards, Ernst J. Oud

2 1