I have an Atlas software probe, and notice that when its upstream ISP is a particular VPN provider (Fastest VPN) the registration fails.
Analysis has shown that whilst the 3-way TCP handshake works to any and all of the registration hosts (x4), because the SSH banner is not returned (The registration happens on ssh://[host]:443, it looks like the VPN ISP is doing MITM or transparent proxying.
Very annoying.
And the reason I wanted a software probe was to get highlighted of when the (quite unreliable) VPN provider goes down
Any workarounds?
This can get annoying indeed, and in practice it prevents the probe from connecting. On the bright side: it works as intended, as no one really wants a MITM 
I’m afraid there’d no workaround as long as you need this probe on that particular ISP, and they do MITM.
I think it’s probably transparent proxying rather than MITM as TLS works. Would just be nice if RIPE could do the registration on more than one port - not just 443.
Well if it’s really transparent, without modifying the packets, then it will work just fine. Interference is what can cause problems. I think you’re right saying we could perhaps support more ports than 443 alone; I don’t know how that would meaningfully change success rates though.
In decades past, using 443 “to get through firewalls” might’ve been a reasonable idea. But that’s not been the case for close to 20 years now. TCP/443 is HTTPS (SSL/TLS), when you use it for something non-standard (like, oh, say, SSH), anything that’s inspecting that traffic is most likely going to block it as “unknown”. These days, there’s no reason to not just stick with the well documented standard port (TCP/22).
(My former employer has used Bluecoat for over a decade. We found it an unending annoyance. Everything we do is not “windows” and much of what we do on windows does not use the system certificate store, so does not have the company “null” CA cert. And as stated above, anything that isn’t recognizable TLS on TCP/443 is blocked, and logged. Our setup specifically does detect SSH on port 443 (any port), blocks it and sends an admin alert that something is trying to tunnel out of the company – ssl/tls on non-standard ports get this treatment as well. In that network, my probe was entirely outside the company network.)
1 Like
“your network, your rules” of course
(I’m unsure how preventing 443/SSH is actually meaningful if 22/SSH is otherwise allowed - if it isn’t allowed then using it as a fallback would not work either.)
Our impression is that using 443 has a higher chance of success than 22. Of course, even though it’s not 100%. But as it is now, we’re not prepared to try various ports.
Maybe a solution could be for RIPE Atlas team to code for a variety of TCP ports and use the first one that works?
1 Like
Yes, that sounds like something we can evaluate. Thanks!
Thanks Robert. Ping (no pun intended) me if you need some testing. I’ve got a variety of probe configs (HW, Software, Docker, OpenWRT SW). Dual stack with permanent IPs.
443 had a lower “default deny” many many years ago… because there were no technical means to inspect it, and blocking “https” was a management nightmare. Blocking 22 was a “simple security measure” - it was obviously easy to defeat using a different port (as Atlas does), but then identifying ssh on non-standard ports was also trivial, thus “everyone” does it. In my case, 22/SSH was not open by default, but exceptions could be made; SSL/TLS that cannot be inspected (non-standard port, not using the wildcard CA…) will NOT get an exception. (that’s why we hated it so much.)
An ISP messing with customer traffic in this way is a very good way to not have customers. Odd that they have no fallback for things they don’t understand. (I’m not sure what they’re even trying to do, as without certificate shenanigans there’s no way to see plaintext.)