P.S.: I just see the error messages in the URL and Additional Info fields could be related to my test environment. On my life site I only have the Warning (yellow box) at the very top.

When tested on live servers I had no problem
When tested on localhost I had exactly the same problem

On 2 March 2016 at 10:51, Richard Fath notifications@github.com wrote:

P.S.: I just see the error messages in the URL and Additional Info fields
could be related to my test environment. On my life site I only have the

Warning (yellow box) at the very top.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/9281
https://issues.joomla.org/tracker/joomla-cms/9281.

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I tested on live server where also my website is located, 1and1 shared hosting. The test environment (some subdomains) I have secured with http password. My backend is "force secure", and the cert for my domain is not valid for my testing subdomains, that's maybe why I get the PHP errors there only, but for my real life site (where I get not PHP errors but still the warning about XML download) the cert is valid.

I have posted on this issue on googlegroups since monday morning:
error on xml file while trying to update to 3.4.8 - Google Groups
-> https://groups.google.com/forum/#!topic/joomla-dev-general/S4wATwbEkdc

As a moderator on a joomla forum, I saw quite a fex people having this pb.

"a few"

@wilsonge maybe we need revert the https changes on the update servers? Or can this be realted to the update.joomla.org cert problems?

I would guess it is the update.joomla.org cert problems.

Symtoms are same as previous cert problems with JED.

Doesn't seem to exist any incomplete cert chain issues on update.joomla.org domain.

See https://www.ssllabs.com/ssltest/analyze.html?d=update.joomla.org&hideResults=on&latest

Symtoms are same as previous cert problems with JED.

The symtoms when your server can't connect to a https uri are always similar (e.g. no connection), but the causes of the problems can be very diverse. Also they can be client side (your server config for instance) or server side (update.joomla.org server ssl config for instance).

And they also can be Joomla side, of course.

Hmm, am testing my stuff on shared hosting, have nothing local here, so I think I cannot go deeper with testing.

Just out of curiosity, for the server you're hitting the could not open issue on, try plugging this URL in as a custom update stream and report the results:

https://downloads.joomla.org/component/ars/updates/files?format=xml&dummy=extension.xml

(Note: though the version reports as 3.6.0, the packages it is referencing is actually 3.4.0 because that's the latest CMS version plugged into that system right now; I just quickly changed a version number to force it to see an available update)

That'll use a different SSL certificate and possibly help ID the issue as SSL related or something else.

Works, available update shown without any issues or warnings after having changed update channel to custom URL provided in previous comment by @mbabker .

Applying this update on a test site works, too.

I've dropped a ticket to hosting cross-referencing the appscdn ticket. I'm gonna be on the road today so won't be able to follow e-mail. From the looks of it @roland-d or @marijkestuivenberg could post here if there are any relevant updates on that.

Thanks.

@richard67 just to check (verify peer should not be disabled), what happens if, with the normal update path, you put ...

$options[CURLOPT_SSL_VERIFYPEER] = false;

in this line https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/http/transport/curl.php#L174

I confirm the test by @richard67 with @mbabker custom URL. It works.

@andrepereiradasilva When I do this on a 3.5.0 Beta 3 I see as result that I am already on the current version, without any warning (was like this before, too).

When I merge that line into the file of the 3.4.8 - the file looks different but I have put this 1 line at similar place, let's say - then it still does not work.

ok thanks.

So on 3.5.0 beta 3 it works fine, only on 3.4.8 and below the problem exists, right?

Here, it doesn't work either on the joomla 3.5 beta 3 update.
(MAMP stack as localhost server)

from your descriptions it seems like update.joomla.org server problems as @mbabker refered.

No, on beta 3 I cannot say if it works or not, because the updater only can see in 1st xml not mentioned in the warning that there is no update to check for in the 2nd details xml file because already on current version, and so no 2nd xml will be fetched.

And yes I could be like @mbabker referred.

@richard67 do you need me to report anything to Rochen? It seems @mbabker has already done so.

@roland-d It seems he has done so and only mentioned you for reporting any news as long as he is on the road. I have no idea about ticken number and Rochen and their ticket system so I cannot watch that by myself.

@roland-d related: i think extensionscdn.joomla.org has problems too. Maybe should alert Rochen too.

See https://www.ssllabs.com/ssltest/analyze.html?d=extensionscdn.joomla.org&hideResults=on&latest

# openssl s_client -connect extensionscdn.joomla.org:443 -servername extensionscdn.joomla.org
CONNECTED(00000003)
depth=0 OU = GT22984067, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = extensionscdn.joomla.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = GT22984067, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = extensionscdn.joomla.org
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = GT22984067, OU = See www.rapidssl.com/resources/cps (c)15, OU = Domain Control Validated - RapidSSL(R), CN = extensionscdn.joomla.org
verify error:num=21:unable to verify the first certificate
verify return:1
---
// [removed for brevity]
    Verify return code: 21 (unable to verify the first certificate)
---

@andrepereiradasilva I have updated the SSL ticket with the findings. Thanks.

in the SSL Labs test both servers seem ok now. See

• https://www.ssllabs.com/ssltest/analyze.html?d=update.joomla.org&hideResults=on&latest
• https://www.ssllabs.com/ssltest/analyze.html?d=extensionscdn.joomla.org&hideResults=on&latest

@richard67 @ghazal do you still have the problem with update.joomla.org?

BTW, don't know what percentage of Joomla servers use old OS (like, for instance, CentOS 5).

IMHO Joomla HTTPS servers should also support some older cipher suites to fallback in case of servers with old OS.
Like:

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  
• TLS_RSA_WITH_AES_128_CBC_SHA
  
• TLS_RSA_WITH_3DES_EDE_CBC_SHA

See joomla.org (https://www.ssllabs.com/ssltest/analyze.html?d=joomla.org&hideResults=on), for instance, it supports older clients.

@andrepereiradasilva Just checked, problem still persists here.

@richard67 what's your server system information?

Weird, locally, behavior is different according to which AMP stack is used.

• MAMP (3.5) -> xml error
• bitnami stack(s) Update OK

@andrepereiradasilva Which kind you mean? The stuff shown in Joomla! backend? Or uname -a?

your OS/Version, openssl version (if linux or something like it)

@andrepereiradasilva

uname -a
Linux icpu1577 3.2.72-grsec-infong-15294 #1 SMP Wed Oct 21 14:57:23 CEST 2015 x86_64 GNU/Linux

openssl version
OpenSSL 0.9.8o 01 Jun 2010

i ask this happens because downloads.joomla.org (the one that works) https configuration supports more clients than update.joomla.org.

See:

• Downloads: https://www.ssllabs.com/ssltest/analyze.html?d=downloads.joomla.org&hideResults=on
• Update: https://www.ssllabs.com/ssltest/analyze.html?d=update.joomla.org&hideResults=on

openssl version
OpenSSL 0.9.8o 01 Jun 2010

as suspected
you're using a old OpenSSL version (0.9.8) that update.joomla.org doesn't support
see my previous comment (6 ou 7 comments ago - the one with images)

@mbabker @roland-d i think you should talk to Rochen for the joomla cdns support also old clients.

I think adding this cipher suites as fallback would be enough;

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA

I will wait here for further instruction by @mbabker or @roland-d on when to test again or if to close this issue.

I have added the request by @andrepereiradasilva to the ticket at Rochen.

Anyway i leave this link for future reference

The following link shows which client (User Agent) supports what in the https environment.
https://www.ssllabs.com/ssltest/clients.html

If it is still of interest, I can't update to 3.4.8 with joomla component on a distant host (1&1).

@ghazal Sure, same as me, 3.4.8 on 1&1, in my case shared host. We have to wait until Roland or someone else who follows the tickets at Rochen tells us sais that Rochen has solved it.

Same here. Can't update from 3.4.6 to 3.4.8 on Hostgator

Upgrading level to the highest.

IMHO also should be a 3.5.0 blocker, even it seems not to be a problem in joomla code itself.

Added release blocker status to this. No point in releasing a new version if people can't update

Hmm, they still can use extension installer ... but they will not be notified in backend with the red update notifications.

Here is the feedback from Rochen:

I'll see what our CDN provider can do here and get back to you. They may not be willing to budge on older ciphers. If that's the case we can look into alternative solutions such as simply pulling the CDN out of the equation altogether so we have more control.

Thanks for the update, Roland. I get it right that we have to wait for further news, right?

@richard67 Correct, Rochen is looking into it and we have to wait for their findings.

sure, they are not modern ciphers, but the ciphers refered are considered still secure and if used as a fallback (last in the server preferred cipher suites) don't see the problem.

You can see the joomla downloads.joomla.org server uses them and still gets and A grade in SSL Server Scan test.
https://www.ssllabs.com/ssltest/analyze.html?d=downloads.joomla.org&hideResults=on&latest

OK, I am available here today, so just ping me if I shall test so we can close this soon.

You can see the joomla downloads.joomla.org server uses them and still gets and A grade in SSL Server Scan test.

The difference between downloads.joomla.org and update.joomla.org is the former is hosted direct on the Rochen servers while the latter is on the CDN provider (which is a third party from Rochen). It'd be more fair to compare downloadscdn.joomla.org and update.joomla.org or downloads.joomla.org and update1.joomla.org (the former group are both on CDN, the latter group are the direct non-CDN resources and both are hosted on the same server).

I see, thanks for the explanation @mbabker.

My point has only to show you could have grade A (secure) using old cipher suites, and with that supporting most of the older clients.

Actually this only shows most of direct Joomla servers are well configured (hosted by Rochen).
As you say the domains in CDN servers (third party) are the ones that should receive some ssl configuration adjustments so they can support older clients too.

Same issue. Unable to upgrade from 3.4.1 to 3.4.8. Getting following error message:

Warning
Update: :Extension: Could not open https://update.joomla.org/core/sts/extension_sts.xml

I am having this same issue, which I have never seen before when upgrading to Joomla 3.4.8. This time I am upgrading from a Joomla 2.5.28 site, which I have done before (on same host) without a problem.

I was able to work around this error by copying the extension_sts.xml file onto my local host, and then editing the Joomla database using phpMyAdmin to replace the URL in the "_updates" table with my local URL. The item is the last in the "_updates" table, name "joomla", version "3.4.8". Replace "https://update.joomla.org/core/sts/extension_sts.xml" with your local URL. In my case, I did not use https. The update then proceeds normally. There is no need to re-edit the database, because after the update, the "_updates" table no longer contains a record for "joomla", "3.4.8".

Yes - it's an issue on the server we host the XML files on. For your workaround - rather than change the database you should just swap to adding your custom URL in the options of the Joomla Update component and put your XML path in the custom URL field (and select Update Stream as "Custom URL").

For your workaround - rather than change the database you should just swap to adding your custom URL in the options of the Joomla Update component and put your XML path in the custom URL field (and select Update Stream as "Custom URL").

I tried that and it doesn't work. Unless update server is set to "Short Term Support", Joomla will report that "you already have the latest version" 2.5.28.

You have to select "Custom URL" as update channel in the update component's options, and then in the field below the chanlle selector enter the url https://update.joomla.org/core/sts/extension_sts.xml George provided. Then save & close and you should be offered the update. This will work for updating any 3.x but not a 2.5, the xml is not prepared for that. But or a 3.4.8. thid works pretty well.

I understand, but I was updating from 2.5.28, so your method won't work in that case.

It would if I would have prepared for George the 2nd xml which is referred to by the 1st xml in the right way.

In fact we use this custom url for testing a pull request, so it might disappear sooner ot later and so is not an alternative for upading in general.

Is there an ETA on when this will be solved? Have several sites need updating to Joomla 3.4.8.

@WebTread This is not related to updating to Joomla 3.4.8 but to Joomla 3.5. You can always update sites by downloading the package and install it via the Extension manager.

@rolandd it is related to all updates using the joomla update component!!

On 7 March 2016 at 07:55, RolandD notifications@github.com wrote:

@WebTread https://github.com/WebTread This is not related to updating
to Joomla 3.4.8 but to Joomla 3.5. You can always update sites by
downloading the package and install it via the Extension manager.

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman but we can update to Joomla 3.4.8 at the moment or not?

Not using the Joomla update component

On 7 March 2016 at 08:32, RolandD notifications@github.com wrote:

@brianteeman https://github.com/brianteeman but we can update to Joomla
3.4.8 at the moment or not?

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Must be my luck then, just updated 3.3.6 to 3.4.8 with the Joomla update component.

Yes it depends on your host and you can see multiple people have posted that it doesnt work

My misunderstanding then, I thought it was only an issue when going to 3.5.x. The alternative for updating via the Extension Manager should still work as you do the download yourself.

*Yes BUT there is no way for a user to know that. *They just go to the update component and get the error that they are reporting - that is why I marked this is as the highest priority issue

Any workaround for users migrating from 2.5.x?

@brianteeman Understand and agree.

@jazzynico Download Joomla manually from https://www.joomla.org/download.html and use the Extension Manager to install the Joomla 3 package.

@roland-d Thanks a lot! I thought that it only worked for updating from 3.x but it also worked with 2.5.x. Great, it was a real blocker for me.

@roland-d Also keep in mind that I had to have my host increase my max upload and post PHP settings. This is a major pain for anyone that is use to just going to the update component as many will still get an error using the Extension Manager as I did. My sites are all updated but yes this would be a major priority as the Joomla community at large is going to hit this wall.

Also keep in mind that I had to have my host increase my max upload and post PHP settings.

This issue has nothing to do with upload or post settings. It's all related to SSL validation, apparently there are hosts out there through whatever combination of settings cannot validate the SSL connection to update.joomla.org.

One possible (short-term) workaround since it seems the physical servers still support this whereas the CDN solutions don't. For the following upgrade paths, set these custom URLs:

• 2.5.x to 2.5.28 or 3.x to 3.4.8: https://downloads.joomla.org/updates/cms/list.xml
• 2.5.x to 3.4.8: https://downloads.joomla.org/updates/cms/sts/list_sts.xml
• 3.x to 3.5.0-beta5: https://downloads.joomla.org/updates/cms/test/list_test.xml
• 2.5.x to 3.5.0-beta5: https://downloads.joomla.org/updates/cms/test/list_test_25to3x.xml

EDIT: Changed version references for beta 5

Its not just hosts - a mac localhost running MAMP wont work either

On 7 March 2016 at 14:15, Michael Babker notifications@github.com wrote:

Also keep in mind that I had to have my host increase my max upload and
post PHP settings.

This issue has nothing to do with upload or post settings. It's all
related to SSL validation, apparently there are hosts out there through
whatever combination of settings cannot validate the SSL connection to
update.joomla.org.

One possible (short-term) workaround since it seems the physical servers
still support this whereas the CDN solutions don't. For the following
upgrade paths, set these custom URLs:

• 2.5.x to 2.5.28 or 3.x to 3.4.8: https://downloads.joomla.org/updates/cms/list.xml
• 2.5.x to 3.4.8: https://downloads.joomla.org/updates/cms/sts/list_sts.xml
• 3.x to 3.5.0-beta4: https://downloads.joomla.org/updates/cms/test/list_test.xml
• 2.5.x to 3.5.0-beta4: https://downloads.joomla.org/updates/cms/test/list_test_25to3x.xml

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman what does your phpinfo shows as openssl version on MAMP?

0.9.8?

@mbabker Just tried custom url 3.x to 3.5.0-beta4: https://downloads.joomla.org/updates/cms/test/list_test.xml. Did not work. Got message that archive file may be truncated or currupt. Maybe the zip is not uploaded completely there? Could you check if file size is OK or smaller than expected?

OpenSSL support enabled
OpenSSL Library Version OpenSSL 0.9.8zg 14 July 2015
OpenSSL Header Version OpenSSL 0.9.8r 8 Feb 2011

On 7 March 2016 at 14:25, andrepereiradasilva notifications@github.com
wrote:

0.9.8?

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

The ZIP packages are still hanging off GitHub as usual, I just changed all the XML references to use the downloads.joomla.org server instead of the update.joomla.org CDN. That said I do see an error in the XMLs, give me one moment to fix (this affects both the CDN and alt server).

Both sources are updated (downloads should be fine now, update will need to wait for the CDN to refresh which is on about a 10 minute cycle).

I can confirm that @mbabker 's workaround with custom URLs he provided above works for me for updating 3.4.8.

So maybe add a hint to the release notes and all is ok with this workaround?

So priority of this issue can be reduced and 3.5.0-blocker label can be removed?

Or shall I even close this issue?

@brianteeman so the same problem as the others.
That version of openssl does not support the cipher suites used by the CDN
you can check the ciphers your openssl version support with the following command:

openssl ciphers -v

Still a blocker for me - users cannot be expected to read - they just want
to click update

On 7 March 2016 at 14:45, andrepereiradasilva notifications@github.com
wrote:

@brianteeman https://github.com/brianteeman so the same problem as the
others.
That version of openssl does not support the cipher suites used by the CDN
you can check the ciphers your openssl version support with the following
command:

openssl ciphers -v

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

i also agree with @brianteeman.
Update should work in 3.5.0 without workarounds.

So priority of this issue can be reduced and 3.5.0-blocker label can be removed?

Leave it open. It's a workaround. Not a long term solution (at least at our level). I've pinged hosting to see if there are any updates, we'll see what happens.

Ok, thanks, I'll stay tuned.

Still a blocker for me

Is it a blocker for the 3.5.0 release? I doubt it as it's basically not something we can fix in the CMS. It's a hosting issue.
The only thing we could do in the CMS is going back to use non-SSL links for the update XML. Which is not really a solution imho.

Is it a blocker for the 3.5.0 release? I doubt it as it's basically not something we can fix in the CMS. It's a hosting issue.

A permanent solution needs to be found before the next stable release. Even if that means the XML manifests switch back to the HTTP protocol until the hosting situation is addressed. Short term I consider it acceptable to use the workaround posted above for updates as this has helped to gauge the number of resources relying on configurations that our hosting solution has provided, and they are also looking at this issue and what their partners provide to get us a working solution.

Yes, it's annoying for users right now, but it gives us data to provide to Rochen about the types of environments different server solutions need to support. The update CDN, given its use case, has different requirements than the CDNs serving static content or the Install from Web's CDN setup.

Being an observer of patterns, I must say that it seems outside of random that critical security vulnerabilities exist in versions before 3.4.6 and suddenly the update feature of Joomla becomes broken. Many sites have become victim to the zero day exploit, and I'm sure there are thousands more out there that need upgrade to 3.4.7 (3.4.8) to close this vulnerability. I don't know if anyone has asked this question yet, but why was the updater working and then recently stopped working? Does anyone else see how rare it is that these two conditions should occur together: 1) a vulnerability that is bringing sites down (or worse) with bots continuing to attempt to exploit the vulnerability, 2) the Joomla core update feature becoming unusable?

None of it is co-related. If anything, the issues affecting a number of users are a result of needed hardening in the update system.

Joomla has always delivered updates via the HTTP protocol. Every security aware person watching this can tell you why that's a bad idea. A recent change has started to serve some of the XML files via HTTPS (not the original one that Joomla will connect to, rather the second file in the collection). On servers still running older software packages, those servers can't validate against the SSL connection to the CDN service. It was suggested at #9281 (comment) that a workaround is to enable older cipher suites at the server level, and that has been proposed to hosting. As they partner with a third party for the CDN resource, that is out of our hands at the moment.

A workaround, which is short term, is to use custom URLs coming from another of the joomla.org properties as guided in #9281 (comment) (these are authentic, I personally uploaded them, and they can be compared against the source repo at https://github.com/joomla/update.joomla.org/tree/downloads.joomla.org).

I don't know what exactly you're trying to get at with your patterns, but I promise you there is absolutely no foul play involved anywhere, unless learning that you're running on servers with outdated software packages is considered foul.

The explanation is further up this thread - no conspiracy theory - there
was a switch to using ssl

On 7 March 2016 at 19:45, durian808 notifications@github.com wrote:

Being an observer of patterns, I must say that it seems outside of random
that critical security vulnerabilities exist in versions before 3.4.6 and
suddenly the update feature of Joomla becomes broken. Many sites have
become victim to the zero day exploit, and I'm sure there are thousands
more out there that need upgrade to 3.4.7 (3.4.8) to close this
vulnerability. I don't know if anyone has asked this question yet, but why
was the updater working and then recently stopped working? Does anyone else
see how rare it is that these two conditions should occur together: 1) a
vulnerability that is bringing sites down (or worse) with bots continuing
to attempt to exploit the vulnerability, 2) the Joomla core update feature
becoming unusable?

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Joomla has always delivered updates via the HTTP protocol. Every security aware person watching this can tell you why that's a bad idea.

It is a way worse idea to introduce HTTPS and break the updater. How can people update when the updater is broken? That is a really bad scenario. You can't even release a 3.4.9 to fix this, because a subset (you don't know how large) will not even be able to use the one-click updater. Given the security problems that presently exists in a large number of Joomla sites, it would seem advisable to make a critical update announcement, 3.4.9, with special instructions how to apply the update. Embarrassing? Yes, but necessary.

It is NOT an issue within the core Joomla software. It requires server-side software updates, primarily with OpenSSL and cURL.

We can turn off the SSL requirement in the update system again. The day updates get p0wned with a man-in-the-middle attack, users will be screaming about the update system not being secured sooner. That is actually a pretty high level vulnerability in the update system and the only way to stop it is to either push an SSL requirement or by not using Joomla core to fetch and apply updates for the core platform, or any third party extension which does not serve their updates from a secure location, but rather to go to the source website, download the package, and upload it manually.

This is why there is a ticket open with Joomla's hosting providers. The physical servers are able to accommodate these older software platforms (server-side, again) but the CDN service does not. So the primary action point right now is determining whether the CDN provider will enable support for older software platforms, and if they will not, exploring alternative solutions. Changing the URL isn't a solution as that change would only be valid for new Joomla versions. Downgrading back to HTTP and not trying to secure the system isn't a solution, I've explained the security hole in that. Frankly given Joomla's been running updates this way for five years, it's a miracle a major MITM attack hasn't happened yet.

@andrepereiradasilva
Unfortunately the information available to upgrade openssl when used with mamp pro is confusing (and not accurate)
MAMP state that they dont include openssl but just use the version shipped with the version of osx being used.

So i upgraded opensl to the latest version using brew and verified that it is installed but mamp still doesnt see it :(

It requires server-side software updates, primarily with OpenSSL and cURL.

I don't think so. I have used the updater with my server no problem, to upgrade to 3.4.8, and there was no problem fetching this file:
https://update.joomla.org/core/sts/extension_sts.xml

If my server-side software versions haven't changed (certainly not downgraded), and this file's URL hasn't changed, then why is the updater now failing?

I would suggest looking into your system's logs to find that answer. Nobody has a magic "this is why it doesn't work" statement for every possible scenario.

The url changed to https

On 7 March 2016 at 21:21, Michael Babker notifications@github.com wrote:

I would suggest looking into your system's logs to find that answer.
Nobody has a magic "this is why it doesn't work" statement for every
possible scenario.

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

At this point their is a far greater risk to a users site that they cant upgrade from a version with known vulnerabilities that are 100% exploitable and the potential for a MITM attack.

Until the cdn prover can verify that they have added the missing cipher we should immediately revert back to http until either they do or a new cdn provider is found

i agree

we could make a toggle in the updater component's options to switch between https and http ... or we could make it use https as it is now but catch the error somehow and then use http as fallback.

This is the same mentality that got #8186 closed. My opinion. Either Joomla needs to stick with it or Joomla needs to accept that its update mechanism will ALWAYS be vulnerable to MITM. It is NEVER going to work 100% of the time for 100% of users.

@brianteeman:

immediately revert back to http

Agreed.

I now understand that when "Update server" is changed from "Long Term Support" to "Short Term Support", the URL is imported from somewhere and stored in the Joomla database table "_updates" with item name "Joomla" and version "3.4.8". The URL being: https://update.joomla.org/core/sts/extension_sts.xml

I am doing some debugging in libraries/joomla/http/transport/curl.php, function getResponse, because PHP is reporting "Undefined offset" on line 159 and 163. This is the function that gets the response from the remote server.

there should be a http fallback maybe also because it always can happen that https stops to work after it worked before, e.g. if a root ca is reverted because was hacked like it once was with verisign, as far as i remember.

It is NEVER going to work 100% of the time for 100% of users.

It should

On 7 March 2016 at 22:05, Richard Fath notifications@github.com wrote:

there should be a http fallback maybe also because it always can happen
that https stops to work after it worked before, e.g. if a root ca is
reverted because was hacked like it once was with verisign, as far as i
remember.

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

We should strive for it but cannot guarantee that.

It is NEVER going to work 100% of the time for 100% of users.

It should

Then the only way to guarantee that is to leave it on HTTP or run servers with vulnerable SSL configurations.

there should be a http fallback

HTTP fallback isn't an option unless we're going to serve two sets of files from two different servers. If you notice, http://update.joomla.org/core/list.xml has hardcoded URLs in it. JUpdater cannot (and should not, holy hell if someone does this then I don't know what to say) take a HTTP(S) URL and try the other protocol arbitrarily. Either the system is 100% HTTPS or 100% HTTP.

Read http://blog.ioactive.com/2016/01/drupal-insecure-update-process.html, seriously. The update system being completely vulnerable to interception like this is a much bigger potential issue than you may be willing to accept.

@mbabker i agree with you that not having HTTPS in whole update system is a risk of MITM and should be done ASAP - high priority. But this is here for almost a week now and no developments in the CDN front.

Joomla 3.4.x as several very critical vulnerabilities already in the wild, and the update broken for older servers. It's not the best scenario.

My opinion to revert temporarily until the CDN provider resolves the ssl configuration issues is just to not leave those servers in a impossible to update state (I know joomla can be updated manually, but do all users know?)

But has you all know, i'm no joomla member, just my humble opinion, that's all.

I know joomla can be updated manually, but do all users know?

hell no!

The tendency with Joomla (I was on the leadership teams, I watched this happen) is to revert issues because they break something and instead of trying to address it it gets swept under the rug and ignored. I even said earlier that if this can't be addressed before 3.5 releases that it should be reverted. Reverting it now is just going to give Rochen and the CDN partner and the Joomla leadership excuses to sit on the issue and not do anything about it, and set a precedent for when the next time it's attempted to push to SSL and it fails for a small group of users to quickly revert.

another option is to change the xml to read the downloads.joomla.org XML in HTTPS until the CDN issues are solved.

That way you will have HTTPS and work in most (if not all servers).

When CDN is ok, you can revert this change.

What do you think?

I agree - if it's not fixed by 3.5 release day then i'll reconsider - but for now I'm happy to sit on this and put some pressure on Rochen.

Let's keep the pressure on.

The tendency with Joomla (I was on the leadership teams, I watched this happen) is to revert issues because they break something and instead of trying to address it it gets swept under the rug and ignored. I even said earlier that if this can't be addressed before 3.5 releases that it should be reverted.

As you can see from this PR, from my part, i can only say i tried to troubleshoot the issue the best i can so the change wouldn't got reverted. But no developments in almost a week...

@mbabker:

fails for a small group of users

How small is small? When does small mean insignificant?

@mbabker:

Nobody has a magic "this is why it doesn't work" statement for every possible scenario.

Meaning the problem is not even 100% understood, so the logical thing is to revert to an environment that is known to work. The updater is crucial.

Agreed. We can always revert to http just before release as we know this would work. But it's last resort and we need to go back to https with 3.5.1 then.

As for http fallback in code, if you really do that, then you can as well leave the https out. If SSL doesn't work, then there is a reason for it. It can be due to bad servers or it could be because the site isn't truly the one you were looking for. In the latter case, you certainly don't want to just fall back to http. You would throw out the whole purpose of SSL.

@durian808

Meaning the problem is not even 100% understood, so the logical thing is to revert to an environment that is known to work. The updater is crucial.

We know why it fails. That's not the issue. It's just out of our hands to fix it. Tickets are open with the correct companies and we have to wait for their response now.

I will repeat this because i think this can be a solution that temporary works and uses HTTPS.

another option is to change the xml to read the downloads.joomla.org XML in HTTPS until the CDN issues are solved.
That way you will have HTTPS and work in most (if not all servers).
When CDN is ok, you can revert this change.

Please remember we are NOT just talking about the future upgrades of 3.5 we
are talking about users on <3.4.8 who cannot update today - are we really
abandoning them until at some point in the future when 3,5 is released

On 7 March 2016 at 22:28, Thomas Hunziker notifications@github.com wrote:

@durian808 https://github.com/durian808

Meaning the problem is not even 100% understood, so the logical thing is
to revert to an environment that is known to work. The updater is crucial.

We know why it fails. That's not the issue. It's just out of our hands to
fix it. Tickets are open with the correct companies and we have to wait for
their response now.

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Well, in defense of Rochen and the CDN provider, they only started getting engaged on the cipher part of the issue on Friday. Not sure what either team did over the weekend, but given it wasn't an emergency issue (and still isn't), I wouldn't be surprised if it didn't get much attention again until today.

Meaning the problem is not even 100% understood, so the logical thing is to revert to an environment that is known to work. The updater is crucial.

Yes, it is crucial. But there are other documented ways to update (and the 1.5 style FTP updates never stopped working) and workarounds are published for the short term timeframe that this is happening. So I don't agree that it needs to be reverted this very minute. Revert it if it isn't addressed before the next stable release.

If you really want to help make sure that it's 100% understood, providing data on WHY it's failing in given environments is going to be the most beneficial. I don't have access to resources that are failing, so I can't provide that data. Apparently you do have a server with this issue, so any data (logs, error messages beyond the generic "can't connect to https://..." one Joomla gives, etc.) helps determine this. Maybe you're hitting an issue that has absolutely nothing to do with what we're dealing with now.

@durian808 what is your openssl version?

OpenSSL 1.0.1e-fips 11 Feb 2013

Regarding pressure on Rochen: In which engineering unit? Pascal? Or american pounds per quare foot?

I'm former military. I prefer "alternative" pressure making devices

Waterboarding? (scared)

Here's the results of a curl done to the URI from my server:

% curl -v -O https://update.joomla.org/core/sts/extension_sts.xml
* About to connect() to update.joomla.org port 443 (#0)
*   Trying 94.46.159.2... connected
* Connected to update.joomla.org (94.46.159.2) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Error in TLS handshake, trying SSLv3...
> GET /core/sts/extension_sts.xml HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: update.joomla.org
> Accept: */*
> 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connection died, retrying a fresh connect
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Closing connection #0
* Issue another request to this URL: 'https://update.joomla.org/core/sts/extension_sts.xml'
* About to connect() to update.joomla.org port 443 (#0)
*   Trying 94.46.159.2... connected
* Connected to update.joomla.org (94.46.159.2) port 443 (#0)
* TLS disabled due to previous handshake failure
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error

curl: (35) SSL connect error

"NSS error -12286" means "The local and remote systems share no cipher suites in common."

My server can do TLS 1.2, but looks like is having trouble with the cipher suite required by the remote system, which is: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

It appears the remote needs to allow other secure TLS 1.2. cipher suites.

From what I've read the curl client also matters, one person noted that curl 7.34.0 is the minimum needed for the current configuration (but I can test that wrong).

This comes from my SiteGround account:

babdev@serv01 [~]# curl --version
curl 7.30.0 (x86_64-unknown-linux-gnu) libcurl/7.30.0 OpenSSL/1.0.2e zlib/1.2.3 libidn/0.6.5
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp 
Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP 
babdev@serv01 [~]# curl -v -O https://update.joomla.org/core/sts/extension_sts.xml
* About to connect() to update.joomla.org port 443 (#0)
*   Trying 94.46.159.2...
* Adding handle: conn: 0x2109bd0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x2109bd0) send_pipe: 1, recv_pipe: 0
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to update.joomla.org (94.46.159.2) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv3, TLS Unknown, Unknown (22):
} [data not shown]
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, Server key exchange (12):
{ [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, Server finished (14):
{ [data not shown]
* SSLv2, Unknown (22):
} [data not shown]
* SSLv3, TLS handshake, Client key exchange (16):
} [data not shown]
* SSLv2, Unknown (20):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv2, Unknown (22):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSLv2, Unknown (20):
{ [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv2, Unknown (22):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSL connection using ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*    subject: OU=GT61470025; OU=See www.rapidssl.com/resources/cps (c)15; OU=Domain Control Validated - RapidSSL(R); CN=update.joomla.org
*    start date: 2015-10-18 16:27:56 GMT
*    expire date: 2016-10-19 13:43:52 GMT
*    subjectAltName: update.joomla.org matched
*    issuer: C=US; O=GeoTrust Inc.; CN=RapidSSL SHA256 CA - G3
*    SSL certificate verify ok.
* SSLv2, Unknown (23):
} [data not shown]
> GET /core/sts/extension_sts.xml HTTP/1.1
> User-Agent: curl/7.30.0
> Host: update.joomla.org
> Accept: */*
> 
* SSLv2, Unknown (23):
{ [data not shown]
< HTTP/1.1 200 OK
< Date: Mon, 07 Mar 2016 22:57:54 GMT
< Last-Modified: Mon, 07 Mar 2016 15:20:22 GMT
< Cache-Control: max-age=600
* Server NetDNA-cache/2.2 is not blacklisted
< Server: NetDNA-cache/2.2
< Content-Type: application/xml
< X-Cache: HIT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Accept-Ranges: bytes
< 
{ [data not shown]
* SSLv2, Unknown (23):
{ [data not shown]
100  7671    0  7671    0     0   345k      0 --:--:-- --:--:-- --:--:--  356k
* Connection #0 to host update.joomla.org left intact

And in all absolute fairness, this comes from the server hosting developer.joomla.org:

devj@developer.joomla.org [~]# curl --version
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 
devj@developer.joomla.org [~]# curl -v -O https://update.joomla.org/core/sts/extension_sts.xml
* About to connect() to update.joomla.org port 443
*   Trying 94.46.159.2... connected
* Connected to update.joomla.org (94.46.159.2) port 443
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
* Closing connection #0

curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

I just successfully connected to another https:// site, from my server, using my curl version (example above), using TLS, with cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA. I think this cipher suite was not chosen through "negotiation" handshake. The local and remote systems appear to already know which cipher suites they have in common.

There may be something going on with some servers being configured not to negotiate with the remote server for determining the cipher suite to use, and it may be that update.joomla.org is requiring such negotiation. It may be that update.joomla.org has too small a set of accepted ciphers. An answer might be to widen the set and not require negotiation (of course, without sacrificing security).

It appears the remote needs to allow other secure TLS 1.2. cipher suites.

Yes. That's the problem. CDN only allows 4 cipher suites for RSA keys and all only with elliptic curve (EC) diffie hellman (DH) ephemeral (E), in other words, ECDHE for key exchange.
See https://www.ssllabs.com/ssltest/analyze.html?d=update.joomla.org&hideResults=on&latest

The downloads.joomla.org, on the other hand, allows a lot of fallback cipher suites, with ECDHE, DHE or RSA for key exchange. Also it allows other ciphers for bulk encryption (AES, Camellia, 3DES) and with different strengths (128 and 256). So it provides much more combinations possible to support older clients or clients that disable some cipher suites.
See https://www.ssllabs.com/ssltest/analyze.html?d=downloads.joomla.org&hideResults=on&latest

I just successfully connected to another https:// site, from my server, using my curl version (example above), using TLS, with cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA. I think this cipher suite was not chosen through "negotiation" handshake. The local and remote systems appear to already know which cipher suites they have in common.

I think the problem your server probably don't support elliptic curve (EC) DHE for key exchange and the update.joomla.org CDN server regretfully only provides cipher suites that use ECDHE for key exchange.

Try this command(probably it will return an error)

openssl s_client -connect update.joomla.org:443 -servername update.joomla.org

And try this command (probably you will connect)

openssl s_client -connect downloads.joomla.org:443 -servername downloads.joomla.org

Also you can check your server openssl enabled cipher suites with

openssl ciphers -v

And to see only cipher suites with TLS an RSA for authentication (both the update.joomla.org and downloads.joomla.org servers certificates are RSA and only allow TLS protocol)

openssl ciphers -v | grep TLS | grep RSA

openssl s_client -connect update.joomla.org:443 -servername update.joomla.org

Appears to have initiated an "SSL-Session", w/ TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384.

openssl s_client -connect downloads.joomla.org:443 -servername downloads.joomla.org

Also appears to have initiated an "SSL-Session", w/ TLSv1.2, ECDHE-RSA-AES128-GCM-SHA256.

Using "openssl ciphers -v" on my server, I see the following for TLSv1.2:

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

ok, so your server has ECDHE cipher suites and can make a TLS handshake with update.joomla.org because it can use the same protocol and cioher suits.

So your problem must be with curl somehow.

maybe this is the problem? http://serverfault.com/questions/703436/ssl-handshake-with-centos-curl-and-ecdhe

It seems that your server, although openssl allows it, cannot connect by default with curl with ECDHE cipher suites and that's seems to be the problem. Since update.joomla.org only allows that kind pf cipher suites you cannot connect it seems.

So your problem must be with curl somehow.

I'm tending to agree at this point. It looks like my curl version, 7.19.7, is not able to connect via TLS1.x. The problem is, curl 7.19.7 is the current version for CentOS 6, so a huge number of people are affected by this.

@andrepereiradasilva:

Yes. That's the problem. CDN only allows 4 cipher suites for RSA keys and all only with ... ECDHE for key exchange.

Those 4 cipher suites are:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

The first 2 of these are indeed supported by my server.

Made tests in Centos 5.x, CentOS 6.x and CentOS 7.x, this are the results.

CentOS 5.x

# openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

# curl --version
curl 7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

# openssl ciphers -v | grep RSA
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=SHA1
DES-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=MD5
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-DES-CBC-SHA         SSLv3 Kx=RSA(512) Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-RC2-CBC-MD5         SSLv3 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC2-CBC-MD5         SSLv2 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export

There is not possible to do the TLS handshake with the update.joomla.org server because this version of openssl doesn't support any of the ciphers the update.joomla.org server requires.

As you can see there is no ECDHE cipher available for Key Exchange (Kx=)

So curl also will never work because will not be able to perform the TLS handshake. There can be other problems.

CentOS 6.x

# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

# curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

# openssl ciphers -v | grep RSA
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

So it's possible to do the TLS handshake with the update.joomla.org server because this version of openssl supports at least one of the ciphers the update.joomla.org server requires.

This is confirmed by this command:

# openssl s_client -connect update.joomla.org:443 -servername update.joomla.org
[...]
    Verify return code: 0 (ok)
[...]

But curl will not connect, because this version has, by default, the ECDHE cipher suites disabled.

# curl -v https://update.joomla.org/
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

But if you force a ECDHE cipher suite that the update.joomla.org server allows it will work:
Note that in this case, we are forcing the TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA cipher suite that is one of the 4 that the CDN server supports.

# curl -v --ciphers ecdhe_rsa_aes_256_sha https://update.joomla.org/
[...]
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[...]

CentOS 7.x

# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

# curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz

# openssl ciphers -v | grep RSA
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5

So it's possible to do the TLS handshake with the update.joomla.org server because this version of openssl supports at least one of the ciphers the update.joomla.org server requires.

This is confirmed by this command:

# openssl s_client -connect update.joomla.org:443 -servername update.joomla.org
[...]
    Verify return code: 0 (ok)
[...]

And curl will connect, because this version of curl has, by default, the ECDHE cipher suites enabled.

# curl -v https://update.joomla.org/
[...]
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[...]

Conclusion

As suspected, CentOS 5.x and CentOS 6.x should not be able to connect with default settings to current update.joomla.org CDN server in HTTPS.

CentOS 7.x will connect fine.

I also confirm this is an issue. I would like to know who installed an SNI based SSL for a critical Joomla! function. Whilst I appreciate some peoples views state that we shouldn't support outdated systems etc. This is something that should be resolved so it works as it did previously regardless. Joomla! needs to provide an errorless way. A lot of Joomla! users cannot be blamed for their hosts choices. Having an SNI based SSL is always going to fail on anything remotely old. updates.joomla.org should have a fully validated SSL cert, I believe this should then resolve the issue and all will be well again no?

https://www.ssllabs.com/ssltest/analyze.html?viaform=on&d=update.joomla.org

Still regarding support for Elliptic Curve Cryptography (ECC), which allow ECDH(E) for key exchange and ECDSA for authentication (with ECDSA certificates) in the TLS handshake, GlobalSign made a page that demonstrates the support for this tecnology in OS, browsers, servers and libraries: https://support.globalsign.com/customer/portal/articles/1995283-ecc-compatibility

Thanks for sharing

I would like to know who installed an SNI based SSL for a critical Joomla! function.

I'm gonna take a wild guess and say it was a standardized configuration with the CDN provider versus a deliberate decision, in part because of a lack of awareness by Rochen and the CDN partner as to the type of data and connections this resource serves compared to other CDNs in the joomla.org network. As this is the only server or CDN whose primary purpose is NOT serving web traffic to browsers, without a big warning label somewhere in a resource management system it's easy to not give it the custom configuration it requires. Those requirements are now crystal clear and the right solution is being sought out.

curl -v --ciphers ecdhe_rsa_aes_256_sha https://update.joomla.org

I have confirmed this works on CentOS 6.6, curl version 7.19.7.

On CentOS 5.8, curl version 7.15.5, I get "failed setting cipher list". Without specifying "--ciphers" I get "handshake failure".

From Rochen:

Hello,

This is hopefully now resolved, at least for clients on servers with older versions of OpenSSL such as 0.9.8. The grade reported by SSL Labs was reduced, but I don't see anything concerning.

@mbabker I can confirm that for me updating via Testing channel works. Shall I close this issue now?

Leave it for now, let's get more tests.

@mbabker Who will lose it then if enough tests? Me? Or you? Let me know in case if I shall close it later.

We've got enough people with access rights to close stuff, that's the least of our worries. I'm just more interested now in hearing from different folks who had run into an environment with issues to see if we're back in a workable state.

The MAMP localhost that would not update now will ;)

On 8 March 2016 at 20:47, Michael Babker notifications@github.com wrote:

We've got enough people with access rights to close stuff, that's the
least of our worries. I'm just more interested now in hearing from
different folks who had run into an environment with issues to see if we're
back in a workable state.

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Works for me.

CentOS 6.6
curl 7.19.7
OpenSSL 1.0.1e-fips 11 Feb 2013

Here is the result of curl:

% curl -v -O https://update.joomla.org/core/sts/extension_sts.xml
* About to connect() to update.joomla.org port 443 (#0)
*   Trying 94.31.29.160... connected
* Connected to update.joomla.org (94.31.29.160) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_DHE_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
*       subject: CN=update.joomla.org,OU=Domain Control Validated - RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)15,OU=GT61470025
*       start date: Oct 18 16:27:56 2015 GMT
*       expire date: Oct 19 13:43:52 2016 GMT
*       common name: update.joomla.org
*       issuer: CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US
> GET /core/sts/extension_sts.xml HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: update.joomla.org
> Accept: */*
> 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0< HTTP/1.1 200 OK
< Date: Tue, 08 Mar 2016 20:55:50 GMT
< Content-Type: application/xml
< Content-Length: 7671
< Connection: keep-alive
< Last-Modified: Mon, 07 Mar 2016 15:20:22 GMT
< Cache-Control: max-age=600
< Server: NetDNA-cache/2.2
< X-Cache: HIT
< Accept-Ranges: bytes
< 
{ [data not shown]
100  7671  100  7671    0     0  26439      0 --:--:-- --:--:-- --:--:--  138k* Connection #0 to host update.joomla.org left intact

* Closing connection #0

i will test tomorrow also on centos 5.x and 6.x, but since Rochen now added a lot of cipher suites now should work.

@ghazal @paulcu @ekoome @WebTread @xtech86
Could you confirm your server can connect to joomla update server now?

Did you see our note that the updates weren't working through Hostgator as well? They indicated that OpenSSL was up to date but I can't speak to the rest.

Just got this...

An error has occurred.
0 SSL: no alternative certificate subject name matches target host name 'update.joomla.org'

Saying a specific host isn't/wasn't working helps very little unfortunately. We'd need specific versions (OpenSSL and curl client for starters), see some of the data posted above by folks. And as noted Rochen and the CDN provider have made changes which we need testing on to see if there are still any lingering configurations not working.

0 SSL: no alternative certificate subject name matches target host name 'update.joomla.org'

i think @WebTread problem is the SNI problem @xtech86 referred before.

IMHO update.joomla.org also needs to work without SNI, or, at least have a fallback without SNI (e.g. downloads.joomla.org) for those hosts that don't support SNI

SNI support Reference: https://en.wikipedia.org/wiki/Server_Name_Indication#Support

Any of these fallback mechanisms HAVE to be at a hosting level. Joomla's not in the business of deciphering every possible SSL configuration and figuring out what host to connect to on what protocol or anything like that.

Server Name Indicator (SNI) is a TLS extension that openssl only supports from 0.9.8f (i think)

@mbabker I think joomla developer.joomla.org for instance uses OpenSSL/0.9.8b (from your comments above) you can also test there if you can connect to joomla update server now.

I can also confirm it is now resolved in all my environments. However, I agree with @andrepereiradasilva we should have a fallback for it to work without SNI.

devj@developer.joomla.org [~]# curl -v -O https://update.joomla.org/core/sts/extension_sts.xml
* About to connect() to update.joomla.org port 443
*   Trying 94.31.29.160... connected
* Connected to update.joomla.org (94.31.29.160) port 443
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server key exchange (12):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: /OU=Domain Control Validated/CN=*.netdna-ssl.com
*    start date: 2014-04-11 02:36:03 GMT
*    expire date: 2016-05-31 01:26:08 GMT
* SSL: certificate subject name '*.netdna-ssl.com' does not match target host name 'update.joomla.org'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

curl: (51) SSL: certificate subject name '*.netdna-ssl.com' does not match target host name 'update.joomla.org'

As for the fallback, if it can be done at a server level, we can pass the information forward. Actually the only choice is for it to be done at a server level as 1.6.0 (January 2011) was the first stable release using this update system, so a fix cannot be provided at the CMS level.

@andrepereiradasilva If I read the OpenSSL changelog right, 0.9.8f is the first version adding support for TLS extensions and that included the SNI support.

@andrepereiradasilva If I read the OpenSSL changelog right, 0.9.8f is the first version adding support for TLS extensions and that included the SNI support.

yes, it seems so

Add initial support for TLS extensions, specifically for the server_name extension so far.

Source: https://www.openssl.org/news/changelog.html#x39

And BTW the dev server runs:

devj@developer.joomla.org [~]# openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

i could be wrong, but i think at server level to have support for non SNI you have to have a dedicated IPv4 for a host, since SNI is what allows virtual hosts in HTTPS environment.

That why i said before to have a fallback.

But maybe others know other solutions.

Here is result on my Hostgator VPS...

CentOS 5.8
curl 7.15.5
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

%curl -v -O https://update.joomla.org/core/sts/extension_sts.xml
* About to connect() to update.joomla.org port 443
*   Trying 94.31.29.160... connected
* Connected to update.joomla.org (94.31.29.160) port 443
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server key exchange (12):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*        subject: /OU=Domain Control Validated/CN=*.netdna-ssl.com
*        start date: 2014-04-11 02:36:03 GMT
*        expire date: 2016-05-31 01:26:08 GMT
* SSL: certificate subject name '*.netdna-ssl.com' does not match target host name 'update.joomla.org'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name '*.netdna-ssl.com' does not match target host name 'update.joomla.org'

yes, it seems CentOS 5.x is one of those that will not work with somekind of SNI fallback.

• SSL: certificate subject name '*.netdna-ssl.com' does not match target host name 'update.joomla.org'

This means openssl it's trying to compare the CDN server default certificate *.netdna-ssl.com with the host requested by the client update.joomla.org and they don't match, so error.

I've left a note in the ticket with Rochen, let's see what they come up with.

Good idea @mbabker at least we are finally getting somewhere with this without the need to remove SSL.

Is this a related issue or something different that needs its own tracker.
Installing "Install from Web" on3.5beta6 gives
Update: :Extension: Could not open
https://appscdn.joomla.org/webapps/jedapps/webinstaller.xml
Error connecting to the server: error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

On 8 March 2016 at 22:30, Tony Partridge notifications@github.com wrote:

Good idea @mbabker https://github.com/mbabker at least we are finally
getting somewhere with this without the need to remove SSL.

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman i think appscdn.joomla.org (and others with the old ssl configuration of update.joomla.org) needs to be configured as update.joomla.org is now to work.

And they also will have the SNI problem.

@brianteeman @andrepereiradasilva No need for another tracker, same problem. Different url. We need to also make Rochen aware of this URL.

Probably the same issue (WTF didn't they just use the same update server for their XML updates!?)

update. and appscdn. should be the only CDN endpoints needing these revised configurations. The other CDNs I know of (cdn., downloadscdn., and extensionscdn.) are or will be only serving web browser traffic. Are there browsers still out there with dominant use that would require these same "downgrades"?

OK I will leave it to you to update the ticket with @Rochen

On 8 March 2016 at 22:37, Michael Babker notifications@github.com wrote:

Probably the same issue (WTF didn't they just use the same update server
for their XML updates!?)

update. and appscdn. should be the only CDN endpoints needing these
revised configurations. The other CDNs I know of (cdn., downloadscdn.,
and extensionscdn.) are or will be only serving web browser traffic. Are
there browsers still out there with dominant use that would require these
same "downgrades"?

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@mbabker See https://www.ssllabs.com/ssltest/clients.html

Joomla itself doesn't support IE6, so that's a no there. IE8 accounts for anywhere from .02% to .48% of traffic on joomla.org subdomains, I'd say that isn't quantifiable enough to request a change for those endpoints. And I don't know of a method off hand to grab numbers for Java 6u45, but I'm gonna guess that's fairly insignificant too.

only IE8 on Windows XP doesn't support SNI.
IE8 on Windows 7 supports it.

I didn't get into OS breakdowns with it, but if the total IE8 numbers are that low I'd imagine I can probably count some of these sites' IE8/XP traffic on one hand

As asked, tested on MAMP 3.5, from 3.4.3 to 3.4.8, then to 3.5beta5, without a glitch.
Not even a Fix.
Nice !

Also, besides the SNI support, don't forget the ECC requirements for those CDN servers, since they only support ciphers with ECDHE for key exchange. As they are configured OS/Browser combination must also support ECC to connect to those CDN.
https://support.globalsign.com/customer/portal/articles/1995283-ecc-compatibility

Unless I'm missing something (just on those 3 web content only CDN nodes) the only combinations that might not be supported are anything running Windows XP or OS X 10.5 and earlier. So I think unless you haven't updated your personal computer since 2007 we should be OK. Once the appscdn node matches the updated configuration on the main update node, things should be cleared up for 99% of folks.

sounds about right

On 8 March 2016 at 23:05, Michael Babker notifications@github.com wrote:

Unless I'm missing something (just on those 3 web content only CDN nodes)
the only combinations that might not be supported are anything running
Windows XP or OS X 10.5 and earlier. So I think unless you haven't updated
your personal computer since 2007 we should be OK. Once the appscdn node
matches the updated configuration on the main update node, things should be
cleared up for 99% of folks.

—
Reply to this email directly or view it on GitHub
#9281 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@mbabker What is the ETA on that?
I can appreciate all the views shared here. Just think it is vital that we get a solution that is secure but also works as seamlessly as before and nothing short of that seems like a valid answer. Also agree with the... if you are running a really old computer bit...

Don't have one. From the sounds of it though everything is pretty much as seamless as before for the CMS update channel except for anyone running OpenSSL 0.9.8e or earlier (which appears to be just CentOS 5.x systems based on the responses here, but that's also an assumption). So it could be tomorrow or next week, but given how responsive everyone's been working on things and given that this isn't an emergency issue I wouldn't expect things either to stop or be ignored or take very long if folks pick back up on it tomorrow.

@mbabker thanks for all you do!

We can hope they take this as urgent. As people mentioned above not having your Joomla site up to date leaves plenty of people vulnerable to attack. I've manually updated my sites but as I mentioned before that required having the host increase the max upload and post sizes for that to happen. Loads of people will be stuck not knowing what is wrong.

At first I thought my sites were all hacked because the updater wasn't working and I wasted hours over this issue before finding this thread. I suspect tons of people are in a similar boat. Why this wasn't considered an emergency issue is kind of baffling with all the known threats out there as others have mentioned.

But thank you for staying with this and to all those that are also working to fix this issue.

An emergency issue in the hosting world would revolve around services being totally unavailable (joomla.org sites down completely, CDN nodes crashed, etc.). It is being treated as an urgent matter with a high priority, but given there isn't that element of catastrophic failure in play unless everyone's sitting on a budget surplus the overtime pay for engineers to stay on the clock to close this out in full isn't going to get approved. This comes from someone who's spent far too many days having to deal with politics around call-ins and what my user base considered emergency issues versus the contract's definition, I know the pain too well.

The upload/post size configuration truthfully doesn't sound anything like the SSL related issues happening here (and in fact that should only be an issue if your host had those configured down to some insanely small size; the largest 3.5 beta package is the full ZIP at 11.3 MB and other compression methods or upgrade packages are smaller).

As promised here are the updated results for the tests on CentOS 5.x, CentOS 6.x and CentOS 7.x.

CentOS 5.x

# cat /etc/*release*
CentOS release 5.11 (Final)

# openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

# curl --version
curl 7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

# curl -v https://update.joomla.org/
[...]
SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*        subject: /OU=Domain Control Validated/CN=*.netdna-ssl.com
*        start date: 2014-04-11 02:36:03 GMT
*        expire date: 2016-05-31 01:26:08 GMT
* SSL: certificate subject name '*.netdna-ssl.com' does not match target host name 'update.joomla.org'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name '*.netdna-ssl.com' does not match target host name 'update.joomla.org'

Result: No connection because of lack of Server Name Indicator (SNI) TLS extension support in the OpenSSL and Curl version on this CentOS version (as discussed previously).

CentOS 6.x

# cat /etc/*release*
CentOS release 6.7 (Final)

# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

# curl --version
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

# curl -v https://update.joomla.org/
[...]
* SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
*       subject: CN=update.joomla.org,OU=Domain Control Validated - RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)15,OU=GT61470025
*       start date: Oct 18 16:27:56 2015 GMT
*       expire date: Oct 19 13:43:52 2016 GMT
*       common name: update.joomla.org
*       issuer: CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: update.joomla.org
> Accept: */*
>
< HTTP/1.1 200 OK
[...]

Result: Connection successfully established.

CentOS 7.x

# cat /etc/*release*
CentOS Linux release 7.2.1511 (Core)

# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

# curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz

# curl -v https://update.joomla.org/
[...]
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*       subject: CN=update.joomla.org,OU=Domain Control Validated - RapidSSL(R),OU=See www.rapidssl.com/resources/cps (c)15,OU=GT61470025
*       start date: Out 18 16:27:56 2015 GMT
*       expire date: Out 19 13:43:52 2016 GMT
*       common name: update.joomla.org
*       issuer: CN=RapidSSL SHA256 CA - G3,O=GeoTrust Inc.,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: update.joomla.org
> Accept: */*
>
< HTTP/1.1 200 OK
[...]

Result: Connection successfully established.

I believe the SNI issue is a simpler fix, we can just swap over to a dedicated IP with the CDN. I'm just awaiting confirmation regarding the adjustment applied previously to ensure it'll persist if we change. Once we have this completely resolved we can just have the same applied to appscdn. I'll provide an update once I hear back.

Still getting...
An error has occurred.
0 SSL: no alternative certificate subject name matches target host name 'update.joomla.org'

Expected. Haven't had an update since that last comment.

Ok no worries... Thanks for staying on top of this.

We've had the CDN provider migrate update.joomla.org to a dedicated IP, which should resolve the SNI issues as well. Note that when I was testing this I did encounter some DNS caching issues, so I wouldn't be surprised if over the next day or so some users continue to get errors

So, give it a check, if you're still seeing errors try flushing local DNS caches and see what happens. They did a test from our dev site's server and everything went well, so as that's a CentOS 5 platform I'd say it should be good to go pending cache resets.

Once this is all validated, the same changes will be applied to the appscdn node.

Fantastic... I No Longer get the 0 SSL Error... and was able to successfully update Joomla with no issues.

All fine now on CentOS 5.x too.

@durian808 ok for you too?

Yes, "SSL connection using DHE-RSA-AES256-SHA". (CentOS 5.8)

(I don't have any Joomla sites on that server. My sites are on CentOS 6.6.)

I'm unsubscribing now. Thanks everyone who worked on this.

@mbabker so it seems all people that identified problems in this issue can connect now.

Oh and one more thing, shouldn't all http://update.joomla.orgin Joomla core be replaced by https://update.joomla.org after this issue is closed?

Updated fine from 3.4.1 to 3.4.8
and then using "testing" from 3.4.8 to 3.5.0 RC

I still can't connect to install "Install web installer" from localhost and MAMP

Warning
Update: :Extension: Could not open https://appscdn.joomla.org/webapps/jedapps/webinstaller.xml
Error connecting to the server: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

yes that domain has not been changed yet @infograf768
@mbabker is waiting for the validation of update.joomla.org is working fine to ask Rochen to change appscdn.joomla.org too.

Oh and one more thing, shouldn't all http://update.joomla.orgin Joomla core be replaced by https://update.joomla.org after this issue is closed?

Yes it should. See #8186 and #8196 for the discussion about this.
It may need another attemp now that all the issues related to SSL are fixed (not that they would have had affected that PR).

Closing this issue as it is resolved now.

Reopening until the issue with appscdn.joomla.org is resolved as well. Not worth creating a new tracker for that as all the relevant discussion/comments are here

Ah, missed that one. Agreed then.

FYI, there is a new critical security update for OpenSSL "DROWN" CVE-2016-0800. Note that "openssl version" does not provide complete version information. Use one of:

rpm -qa | grep openssl
yum list installed openssl

So there's good news and bad news.

Good news: appscdn is updated with same configuration changes

Bad news: The CDN provider is planning to drop TLS 1.0 support on their network relatively soon

I've shared the full response from Rochen with @roland-d and @wilsonge so the ball's in the PLT's court I guess on anything longer term. I'm also in a sidebar chat with a couple others about Joomla's hosting architecture and how that decision affects us, will share pertinent details as needed.

The latest OpenSSL security issue is mitigated so long as you only support TLS, which is recommended all clients can connect to my server unless they are running windows XP.

Please do @mbabker . Whilst it's great people are phasing 1.0 out... It's not good for Joomla! Or any service as we all know there are bad hosts out there and it's not the clients fault that their Joomla! Updates etc stop. We obviously need to make sure it's as backwards compatible as possible. Glad there's a lot of users on this :-).

I can confirm that the server I couldnt install the "install from web" plugin now works correctly.

As we now have both the cdn servers working I am closing this.

Thanks everyone for your hard work on this.

wow, a major CDN provider phasing out TLS 1.0 support so soon?

https://en.wikipedia.org/wiki/Template:TLS/SSL_support_history_of_web_browsers

Well, until a few months ago the PCI guidance was to be migrated away from TLS 1.0 by June 30, 2016. That changed to June 30, 2018. So I don't think it's a matter of browser support but phasing out support for older (less secure) protocol versions.

i know and agree. But there are still a lot of clients which doesn't support, or at least not by default.
But is good to start the pressure to remove TLS 1.0 and 1.1.

For instance RC4 cipher is prohibit by the IETF (https://tools.ietf.org/html/rfc7465) but google (and others) still support it as fallback or else some clients wouldn't even see google page. The same for SSLv3 protocol (https://tools.ietf.org/html/rfc7568).

https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.25.113&hideResults=on&ignoreMismatch=on

Hi.

I have the same problem but now with the 3.8 Version.

Versión de Joomla instalada 3.7.4
Última versión de Joomla. 3.8.0
URL del paquete de actualización https://downloads.joomla.org/cms/joomla3/3-8-0/Joomla_3.8.0-Stable-Update_Package.zip
Información adicional Joomla!

Error:
Se ha producido un error.
0 SSL: no alternative certificate subject name matches target host name 'downloads.joomla.org'

So how to fix it?

@devmaster-terian please open a new issue as Comments on closed Issues didn't get much Notice.

OK, thanks!