Idea: better support for delivering update packages via https AND fallback for http

[seyfro]

Hi Yahnis,

I use your wp-update-server on mapsmarker.com and also implemented the plugin-update-checker within my plugin. A while ago I switched to https and also changed the endpoint within plugin-update-checker to https. This worked fine for customers on servers with current configurations but unfortunately it failed on lots of others which were using outdated libraries or configs for example.

As a consequence, I had to add the option 'sslverify' => false to the wp_remote_get-request for the plugin-update-checker which is bad as security got lowered - anyway this was the only way to be able offer checks for plugin updates via https.

On the server side I also tried to change the location of the update package to https - unfortunately I had to change this back to http, as there are so many servers out there which have troubles connecting to a server with a current configuration (especially SNI support only).

As I am dissatisfied with the security of my current implementation, I am looking for a way to improve this. I thought about enhancing the plugin-update-checker with a "pre-check" which tries to retrieve a file via https from my server and if that fails, switches the plugin update checker back to http. Furthermore in that case, an additional argument would be sent to the plugin update server which results in the plugin package also being delivered via http instead of https.

The advantage of this solution would be improved security for the majority of users and a fallback to lower security for users on outdated servers (which might have greater security risks due to that).

Disadvantage of that approach would be an additional request to the update server - anyway this is the only approach I can currently think of at the moment (test ssl capability -> check for updates -> download new package https or http depending on test results).

What do you think about that approach? I could imagine that other users would also be interested in a general solution for this issue, as more and more sites are switching to https and would run into the same issues when trying to use https for their plugin updates... best,

Robert

[YahnisElsts]

Some thoughts:

• There's no need for an explicit "pre-check". You already have a perfectly valid "test file" - the metadata URL. Let the plugin optimistically use HTTPS the first time it checks for updates. If the request fails, the update checker can set an "SSL doesn't work" flag in the database and use HTTP for future checks.

  The only drawback is that users whose server doesn't support SSL won't see any updates for the first $checkPeriod hours. I think that's acceptable.

• Automatically downgrading from HTTPS to HTTP is too dangerous to make it the default behaviour. This feature must be opt-in only. I'm thinking something like this:

  $updateChecker->enableHttpFallback($enabled, $retryHttpsAfter = 30 * 24 * 3600);

• The update server already dynamically changes the package URL based on the current protocol (clients using HTTPS get https://... URLs). Unless you pass your own URL to the Wpup_UpdateServer constructor, that is.

[seyfro]

Hi Yahnis, thanks a lot for your feedback - havent thought about using the metadata URL as "pre-check" if https is supported. Will give it a try and let you know the results! best, Robert

[seyfro]

Not an issue anymore, can be closed.