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