Many CMS plugins are disabling TLS certificate validation... and that's very bad

Hundreds of thousands of CMS plugins and PHP libraries are disabling cURL certificate validation and putting millions of users at risk.
Written by Catalin Cimpanu, Contributor
Dennis Nicolai Andersen, ZDNet [additional edits]

An absurd number of CMS plugins and PHP libraries are disabling SSL/TLS certificate validation on purpose, and by doing so, they're putting millions of internet users at great risk.

To make matters worse, many of these plugins and libraries are used to establish connections to payment provider servers, connections through which they later transmit sensitive user data or handle financial transactions.

This important, yet lesser known security issue, was discovered and brought to ZDNet's attention by Scott Arciszewski, Chief Development Officer at Paragon Initiative Enterprise.

The issue resides in how authors of CMS plugins and PHP libraries are configuring their code, and specifically some cURL options.

cURL is a command-line utility found on all web hosting servers, which is used for transferring data to and from remote servers. cURL's use is ubiquitous in the web development community, and many CMS plugins and PHP libraries use it to download, send, and upload data to remote servers via the server's underlying console, instead of opening actual browser sessions for each connection.

cURL supports a bunch of protocols, such as opening connections via HTTP, FTP, SMTP, POP3, LDAP, and more.

For example, when a WordPress plugin that handles financial transactions to "Payment Process #46," it uses cURL connections in the background to actually upload your sensitive credit card data to the payment provider's servers. This usually happens via cURL connections set up via HTTPS, for which cURL also handles SSL/TLS certificate validation, a crucial step in making sure you're talking to a legitimate HTTPS server.

But Arciszewski has recently discovered that developers of many CMS plugins and PHP libraries are disabling cURL security features for when cURL is used to download or send data via HTTPS connections, like the ones above.

This is a huge issue, especially for the cases where cURL is used to handle financial transactions and sensitive user data.

Having those connections negotiated via weakened HTTPS connections is a disaster waiting to happen, as it can allow attackers to easily trick websites into downloading or sending legitimate data to malicious servers. Because the two features are off, the originating site doesn't trigger any alerts to either users or the sites' owners.

Most devs are disabling two important cURL security settings

According to Arciszewski, this happens because of two cURL settings that developers of CMS plugins and PHP libraries disable on purpose.

The first is "CURLOPT_SSL_VERIFYHOST", which many plugins and libraries set to "false" instead of "true".

What this setting means is that cURL won't verify the host URL to which it's connecting to download or upload data. As long as the remote server has a valid certificate, signed by any random Certificate Authority, such as Let's Encrypt or Comodo, the server's URL can be legitimate-site.com or malicious-site.com, and the website from which the cURL request originates won't care.

The second cURL setting that many developers are disabling is "CURLOPT_SSL_VERIFYPEER", which many devs are setting to "0" instead of the more secure "2" value.

This setting means that websites will accept connections to any random HTTPS server, even to those who use self-signed certificates.

"This exposes you to extremely trivial man-in-the-middle attacks," Arciszewski said in a report published last week.

This is no small issue that can be ignored. The problem is extremely widespread in the PHP community, especially.

A cursory GitHub search for the first and second settings reveals hundreds of thousands of projects where developers are disabling cURL certificate validation, including in hundreds of WordPress plugins.

A simple fix is now available

But Arciszewski is not your typical security expert who just points out issues to fearmonger his way into a reputation. He also offers a simple solution.

As Arciszewski has pointed out in a recent report, and as the PHP community has confirmed in Reddit discussions this week, the main reason why so many projects are disabling these two cURL features is because when enabled they tend to generate scary security-related errors on customers' servers. In order to avoid alarming their customers, most developers opt to turn those two features off, while unwittingly knowing what they're really doing.

The reason for those errors, as Arciszewski explains, is that cURL needs to verify the certificates of remote HTTPS servers against a list of known and valid SSL/TLS certificates.

This list of authentic Certificate Authorities --organizations allowed to issue SSL/TLS certs-- is available for download in many places.

Unfortunately, some web hosting services don't store this list at all, while many store it in different server locations, making it impossible to configure cURL settings for CMS plugins and PHP libraries in a universal manner that works seamlessly on all servers.

To address this issue, Arciszewski has created a custom PHP library named Certainty that will download this file (cacert.pem) from the cURL homepage at regular intervals and host it locally, ensuring websites always have an up-to-date list of valid Certificate Authorities.

CMS plugin, and PHP library owners can include this library in their projects and then enable the two cURL settings in their projects without having to worry about triggering scare security alerts afterward.

Sure, an insecure setting inside a library inside another library might sound like an insignificant matter, but when that insecure setting is used in hundreds of thousands of projects, that insignificant matter becomes an internet-wide problem and fixing it might require something as simple as releasing better tools.

Arciszewski and his company, Paragonie, have been known for releasing such "better tools" in the past years, all open-sourced and available on the company's GitHub account.


Editorial standards