Thanks for spotting this @DHammer-PT, It doesn't seem to have been reported previously.

As it appears to be trivial fix and would improve security I've flagged it for a priority review.

@tsteur are you happy for this to be scheduled as a security improvement?

Is there any chance of breaking anything? If not, then could do it. If there's a chance then we'd need to look at this and do it in Matomo 5

tls:// has been supported since PHP 4.3.0

If OpenSSL support is installed, you may prefix the hostname with either ssl:// or tls:// to use an SSL or TLS client connection over TCP/IP to connect to the remote host.

https://www.php.net/manual/en/function.fsockopen.php

For what it's worth I did a quick test by modifying Http::getTransportMethod to always use socket instead of curl and then made the ssl:// to tls:// change. Retrieving plugin information in the Marketplace uses this method, a break point check confirms that the tls:// line was used and completed without any errors.

I don't think the issue is as much of a problem with ssl:// working or not working, but rather that ssl:// is seen as obsolete and tls:// is the modern standard. TLS is the more secure method.

Do we know if ssl:// really means "connect with a socket using SSL 3.0"? I can find very little information about this.
But it might just be an alias as I doubt many PHP setups even support any version older than TLS 1.0. And at least on my PC openssl (3.0.3) doesn't even support any SSL 3.0 options any more.

Also no *.matomo.org domain has supported SSL 3.0 in quite a long time, so does that mean the socket method was broken for all Matomo users for a long time now? If so, we should maybe think about removing it (as at least for me using curl feels a lot more reliable than an improvised HTTP client over a raw socket).