Some Versions Can't Upgrade to 4.0

[miqrogroove]

Looks like a bug! This user reported his 3.5.1 update system is unable to download the latest version due to an SSL error.

​https://wordpress.org/support/topic/cannot-update-my-wordpress-version

It is trying to fetch ​http://wordpress.org/wordpress-4.0-new-bundled.zip

The .org server responds with:

HTTP/1.1 302 Moved Temporarily
Location: https://wordpress.org/wordpress-4.0-new-bundled.zip

[SergeyBiryukov]

Moving to 4.0.1 for review, although it's probably an API issue.

[johnbillion]

​#META632

[Otto42]

It's not a WordPress or API issue. The user or his host needs to update their server to have a more recent version of curl and/or OpenSSL. Old versions of such cannot parse the more modern sha256WithRSAEncryption signature algorithm, which the WordPress.org certificate uses.

[miqrogroove]

And before 4.0 everyone was able to upgrade without SSL?

[Otto42]

The user in that thread is upgrading from 3.5, which would download over http. I believe that the upgrade process switched to downloading the zip packages only over https in 3.7.

[miqrogroove]

Right but did the non-SSL address become unavailable recently?

[Otto42]

Yes, all wordpress.org addresses (with only a couple current exceptions) now do a redirect to their SSL counterparts. That happened last week.

Nevertheless, if the user had previously done a manual update to 3.7 or higher, then it would be trying to get from the https address in the first place (without the redirect) and he would be experiencing the same problem with updating, because the underlying issue is that his server's software can't verify the wordpress.org certificate.

[miqrogroove]

Here is another report:

​https://wordpress.org/support/topic/wont-download-40

[miqrogroove]

And another:

​https://wordpress.org/support/topic/cant-upgrade-to-v-40-error14090086

[miqrogroove]

Replying to Otto42:

Yes, all wordpress.org addresses (with only a couple current exceptions) now do a redirect to their SSL counterparts. That happened last week.

We need to officially raise the minimum requirements for installing WordPress then.

[Otto42]

miqrogroove: The issue with hosts that have outdated root certificates is solved in 3.7 or later, because WordPress includes a copy of the root certificate bundle starting in 3.7.

As for minimum requirements, I don't see that there are any additional requirements to be added. We could add "a hosting service that is up to date" on there, perhaps.

[miqrogroove]

That may not be accurate in environments where OpenSSL is bundled with PHP. I'm trying to determine which version was bundled with PHP 5.2.4...

[miqrogroove]

I found one mention so far on php.net that PHP 5.2.9 was bundled with OpenSSL 0.9.8j. If this is inadequate, then it seems WordPress should not be advertised as compatible with that version.

[Otto42]

Typically, PHP isn't "bundled" with OpenSSL, as such. OpenSSL is a library on the system and PHP's openssl extension often uses that library, although it can be compiled statically too. And it's a bit more complex than that, because if the curl extension is being used, it may or may not be compiled with openssl included within it directly (not using the php openssl extension). So, it's rather hard to say with certainty.

OpenSSL 0.9.8o and 1.0.0a (1 Jun 2010) added the default-to-on support for the SHA2 library of algorithms wrt SSL.

Note that you're talking about two different issues here. The original issue, with this error message:

Download failed.: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm

is caused by an old version of curl w/openssl being used.

The two new threads you linked to today are caused by outdated root certificates, which is separate and solved in WP 3.7 and later. Servers can update their root certificates bundle easily enough, but few do, which is why 3.7 includes its own copy of the bundle.

[miqrogroove]

Okay but they aren't separate issues if they're all being caused by the removal of ​http://wordpress.org/wordpress-4.0-new-bundled.zip

[Otto42]

Well, they are separate issues, because they have separate solutions.

The first problem we can't fix, unless we're willing to go backwards in time to 3.7, where the core decided that all updates must be secure. If we're going to be doing auto-updating, then secure communication is a requirement. The fix for that one is not to also offer insecure downloads, but to help the user fix their server configuration to have the ability to talk securely.

The second issue(s) can be most easily fixed by simply doing a manual upgrade, one time. After that, the problem is solved and they will have the current root cert bundle included in WordPress. People on the support forums assist with manual updates quite a lot. It's not complicated.

[miqrogroove]

Replying to Otto42:

The first problem we can't fix

What is the reason for not allowing both SSL and non-SSL downloads?

[Otto42]

Replying to miqrogroove:

What is the reason for not allowing both SSL and non-SSL downloads?

Well, I would say *security* is probably the biggest one.

But then, this does depend on scale of the issue too. I took a look through the support forums, and found only six SSL related issues from the last week. The three you pointed out, one guy who can't seem to install themes because of an SSL related message, and two others with the same basic root cert problem.

Is this a widespread enough problem to back off on what is fundamentally a security issue? Being able to download executable software over non-secure channels strikes me as "bad-idea". All it would take is one bad-actor out there to set up a proxy to serve their own version of the ZIP file with some malicious code in it.

If this is happening on thousands and thousands of sites, then yes, it's an issue. A few bad hosts here and there should be solved by fixing those hosts or getting customers onto better hosts. Just my 2 cents.

That said, we are allowing for requests to api.* and downloads.* to be http at the moment, so perhaps routing the main core downloads through there as well would be acceptable instead. Ping @nacin.

[miqrogroove]

Replying to Otto42:

All it would take is one bad-actor out there to set up a proxy to serve their own version of the ZIP file with some malicious code in it.

Removing the non-SSL download does nothing to prevent proxy attacks. If we are going to debate security, then we need to consider the impact of blocking upgrades.

[nacin]

Everyone please stop. This is a bug and I'm looking into this.

[nacin]

This was fixed on Thursday.

Before 3.7, all WP installs communicated over HTTP with wordpress.org. After 3.7, they communicate securely if we think they are able. As of 3.7.1, they then also fall back to HTTP if the SSL request fails, because just because we think they are able doesn't mean they *are* able. (The primary example was bad OpenSSL.) Missing or broken OpenSSL is supported because allowing them to update is ultimately way more important.

Anyway, the API endpoints that pre-3.7 installs used were getting back ​http://wordpress.org/*.zip URLs which now redirect. While that redirect is followed, it would break any install without OpenSSL or with a broken OpenSSL. I've moved those downloads to come from downloads.wordpress.org, which has no redirect.