Strictly speaking, yes, running crypto code in JavaScript inside a browser is inherently insecure to various side channel attacks, notwithstanding any attacks on the algorithm itself. However, the reason we use AES-CTR during the update process is to enforce authorization, not message confidentiality. It's not perfect but that's all we can do as long as we want to support plain HTTP sites.

We should definitely revisit this code when Joomla! drops support for plain HTTP sites. In this case the man-in-the-middle attack is solved at the transport layer (HTTPS) and we can use nonces stored in the temporary directory and transferred over HTTPS between client and server.

Also remember that the requirement to use AES-CTR stems from the fact that it's the only algorithm I could find which is secure enough for this use and can be implemented in plain PHP (without external library requirement such as OpenSSL) and plain JavaScript. This is a HARD requirement. If you violate that requirement you're screwed. Also note that restore.php is 3PD software to Joomla! and only supports AES-CTR for the reason I mentioned.

If you want to change the JS library you will have to also provide its symmetrical PHP twin and make sure that the two work together without introducing any cryptographic vulnerabilities (remember that the previous iteration of the encrypted authentication suffered a padding oracle attack we fixed several years ago and which was present for more than four years before a cryptographer noticed).

So, I wouldn't change what is working and battle-tested with something new, shiny and very very very very likely extremely insecure. The time to drop that code is when we drop plain HTTP support.

You may also want to ping @wilsonge and @mbabker since they are the other two people who know how the updater works.

Err, what he said.

@nikosdion I'm not proposing a change for the shake of changing things, that would be totally stupid. I came to this resolution once I realised that the node package wasn't the one that you was using. There are couple of things that we can do here:

• ask the author to publish the package in npmjs, and verify that the version (i guess the latest, although it's ES6) is ok for us
• just copy verbatim the code already there as our source and as you mentioned deal when J moves to https

I'm ok with either ways, as long as the code somehow moves to media/vendor folder

OK will close this and do a trick on our build.js script and build/media_src...

I really REALLY REALLY have to stress out that the JS we use MUST NOT change. If you change it at best you will break things, at worse you will introduce security vulnerabilities. Considering that it's a single purpose piece of code I would strongly recommend not trying to fetch it from an external source but keep it static and cemented to the source code we currently have.

If it ain't broke, don't unfix it ;)

yup, got it, will keep it as is in build/media_src or some other folder under build (media_src is supposed to be ES6 and this will break eslint...). I'll come up with something that satisfies all our requirements here.