In the file /core/Http.php, there is a protocol issue. Line 386 contains the following:
$connectHost = 'ssl://' . $connectHost;
This is an insecure method and should be changed to:
$connectHost = 'tls://' . $connectHost;
Could this be updated in a future release? I apologize in advance if this has already been reported. I tried digging through the issues to see if it had been reported, but was unable to find a match.
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.
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
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).