News: 1649763908

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Creator of SSLPing, a free service to check SSL certs, downs tools

(2022/04/12)


A timely reminder is being issued to the effect that free web services are not the same as free software: the creator of the [1]SSLPing service says he can't look after it anymore .

SSLPing was a useful tool to have around. Sign up, add your servers and the service would check certificates, protocols, ciphers and known vulnerabilities. It checked versions of TLS from SSL v3 to TLS 1.2 and, importantly for some major vendors who should know better, would also bleat if certificates were due for renewal (with nags at 10 days, three days and then on the renewal date.)

The tool was wielded by over 500 registered users, monitoring more than 12,500 TLS servers. It was lightweight and mercifully ad-free. Which appears to have become a problem for its creator, Chris Hartwig.

[2]

"It's broken and I can't and won't fix it," said Hartwig in a message [3]posted on the project's homepage , pulling down the shutters on an operation that has run since March 2016.

[4]This JavaScript scanner hunts down malware in libraries

[5]Worried about occasional npm malware scares? It's more common than you may think

[6]JavaScript dev deliberately screws up own popular npm packages to make a point of some sort

[7]When software depends on a project thanklessly maintained by a random guy in Nebraska, is open source sustainable?

Hartwig faced a number of problems stemming from the technical debt incurred by the platform: an update to OpenSSL would have caused issues; it was stuck on an older version of node.js ("because upgrading would remove SSL v3 detection," said Hartwig); and it was using Docker Swarm, which has fallen a little out of favour in a Kubernetes-obsessed world.

Finally, the three physical servers on which the service ran were tottering. Hartwig reported that one had died, while the others were reporting more than 1,400 days of uptime. Impressive figures, but hinting at a potential impending hardware failure.

It's broken and I can't and won't fix it

"5 days ago," he said, "SSLPing started dying, and I can't figure out how to bring it back to life. Docker refuses to run after attempting an OS update which broke too many things (upstart vs. systemd being one, FS drivers, etc...)"

And, significantly, only 25 percent of the hosting costs were being covered by users signed up to Patreon, according to Hartwig.

[8]

Rates were $5 per month for a personal subscription, $25 per month for enhanced support and access to the source if Hartwig shut things down, and $100 per month for "corporate" level, with private access to the code on Gitlab and the opportunity to influence the direction of SSLPing.

The Register contacted SSLPing to find out if the code would be made available following the end of service, but we have yet to receive a response.

[9]

It's an unfortunate situation but also a reminder that somebody, somewhere needs paying even for apparently free services (and even for those that are very clear about a lack of guarantee.)

It is equally a classic tale of how quickly technical debt can build up as projects race to add new features while deprecating old ones, leaving some services, such as SSLPing, facing challenges beyond those faced by a mere side project. ®

Get our [10]Tech Resources



[1] https://sslping.com/

[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YlWiNa7PqY3OqTIAXdWMeAAAAYQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[3] http://web.archive.org/web/20220410144610/https://sslping.com/

[4] https://www.theregister.com/2022/03/01/socket_npm_dependency_scanner/

[5] https://www.theregister.com/2022/02/03/npm_malware_report/

[6] https://www.theregister.com/2022/01/10/npm_fakerjs_colorsjs/

[7] https://www.theregister.com/2021/05/10/untangling_open_sources_sustainability_problem/

[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YlWiNa7PqY3OqTIAXdWMeAAAAYQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YlWiNa7PqY3OqTIAXdWMeAAAAYQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[10] https://whitepapers.theregister.com/



The worst bit....

Plest

You can bet your sweet life that poor guy is getting a ton of abusive mail from ungrateful bastards moaning about why a free service is no longer running. You can only put yourself out there and help so many before something turns from something helpful into a fucking huge chore you simply can't do anymore.

Re: The worst bit....

sreynolds

Yeah I remember someone taking something I had working on github and raising issue on this and banging on about it not working etc. I had long since given up.

Bloody entitled millennials, why can't they do their own homework.

Pingu

djnapkin

I must be masochistic because I would be interested in the challenge of running such a tool. I've never let lack of prior experience get in the way.

On another angle ... I notice one of the major obstacles was keeping the *nix operating system up to date. If only he'd run it on Windows ... (ducking for cover :-)

Re: I've never let lack of prior experience get in the way.

Anonymous Coward

Neither has any of our current goverment.

Sign up?

heyrick

Or just pop over to

I feel for the guy, but..

BinkyTheMagicPaperclip

Isn't the whole point of Docker and other container services that you're insulated from various configuration changes?

Re: I feel for the guy, but..

John Robson

The containers... yes.

Docker itself still needs to run though.

Re: I feel for the guy, but..

NoKangaroosInAustria

weeell, one would think that because in theory yes, that's what it says on the docker tin. But in practice, it works a bit differently. Docker isolation is a double edged sword, especially if your app depends on another upstream app which doesn't upgrade or alternatively, upgrades itself in a way that breaks YOUR application, because then it's again your problem. The Isolation concept of docker primarily benefits you with regards to the multiple parts of your application being isolated from one other.

Let's assume - for example - that you have two scenarios: in scenario 1, your app depends on an upstream app which has not been upgraded against a known and publicized security vulnerability and in scenario 2, the upstream app has been upgraded but in a way which - if applied - breaks your app.

Docker Isolation enables you to have the particularly undesirable choice of either continuing running your app in a configuration which you know to be unsafe or in a configuration you know to be safe but unstable or non productive/offline

Docker Isolation would be fulfilling it's job perfectly in this scenario - you are insulated as long as you do not change anything in your current setup - security vulnerabilities and all, which is of course a less than ideal situation.

Living your life is a task so difficult, it has never been attempted before.