Resolved sw-cp-server is compiled with old openssl where nginx is not

[mr-wolf]

sw-cp-server is actually a custom compiled version of nginx.
While we are encouraged to increase the security of our SSL-connection with the outside world it becomes hard on some systems to apply these as well on the PSA-interface.

I can't use this directive on my 1-year old Ubuntu 14.04 although my 6-year old CentOS 5.11 has no problem with that.

ssl_ecdh_curve          secp521r1:secp384r1:prime256v1;

On the Ubuntu 14 system I need to use (a modern CentOS 7.3 has the same)

ssl_ecdh_curve          prime256v1;

While nginx is reasonably modern on most systems it becomes quite unpredictable when it comes to sw-cp-serverd.

Can you consolidate these versions in your psa-distributions???
Note the OpenSSL 1.01e of 11 Feb 2013 on the most modern CentOS-version

Here are some examples:

Onyx 17.5.3 CentOS 7.3.1611
sw-cp-serverd -V 2>&1 | head -n3

nginx version: nginx/1.11.10
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled

Plesk 12.5 CentOS 5.11
sw-cp-serverd -V 2>&1 | head -n3

nginx version: nginx/1.9.2
built with OpenSSL 1.0.1p 9 Jul 2015
TLS SNI support enabled

nginx -V 2>&1 | head -n3

nginx version: nginx/1.11.1
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled

Onyx 17.5.3 Ubuntu 14.04.5 LTS
sw-cp-serverd -V 2>&1 | head -n3

nginx version: nginx/1.11.10
built with OpenSSL 1.0.1f 6 Jan 2014
TLS SNI support enabled

nginx -V 2>&1 | head -n3

nginx version: nginx/1.11.10
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled

Onyx 17.5.3 Ubuntu 16.04.3 LTS
sw-cp-serverd -V 2>&1 | head -n3

nginx version: nginx/1.11.10
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled

nginx -V 2>&1 | head -n3

nginx version: nginx/1.11.10
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled

 

[learning_curve]

Adding any un-official release, to any Plesk official release (ourselves) is something we haven't done so far (and probably never will), so we're very keen to hear an answer from Plesk on this (the outcome will assist us on another thread of ours too).

Meanwhile, for those of us using the current release of CentOS, could Plesk maybe also comment on this guide (link below) at the end of their answer to the main question as well? All the other versions of this that we have seen, appear flawed and generate lots of errors. This one may be different? OpenSSL > CentOS 7.3

 

[learning_curve]

Hopefully there will be comments soon, from those that this thread was aimed at by @mr-wolf
Ironically, there is a tangible link now with the 'fix' in this thread: Resolved - Connection Refused :8443 Plesk Onyx

 

[Varrenlad]

As a matter of fact, sw-cp-server could be recompiled easily, with the latest version of OpenSSL linked to it (only 1.0.2 branch, though).

There are two tricky parts: OpenSSL 1.1.0f and nginx > 1.11.2 are not yet supported by lua-nginx-module and some changes should be made in the nginx Makefile before running the compilation. Otherwise, it's yet another instance of 'recompile the nginx and install it via checkinstall'.

# /usr/sbin/sw-cp-serverd -V 2>&1 | head -n4
nginx version: nginx/1.11.2
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.2l  25 May 2017
TLS SNI support enabled

 

[learning_curve]

As a matter of fact, sw-cp-server could be recompiled easily, with the latest version of OpenSSL linked to it (only 1.0.2 branch, though).

There are two tricky parts: OpenSSL 1.1.0f and nginx > 1.11.2 are not yet supported by lua-nginx-module and some changes should be made in the nginx Makefile before running the compilation. Otherwise, it's yet another instance of 'recompile the nginx and install it via checkinstall'.

# /usr/sbin/sw-cp-serverd -V 2>&1 | head -n4
nginx version: nginx/1.11.2
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.2l 25 May 2017
TLS SNI support enabled

You're using Debian we guess? We're on CentOS, so it may not be the same for us (our previous post shows a CentOS option that might work for us*** though we haven't tried it, because of the concern about using non-officlally released changes within Plesk. i.e. the creation of consequential errors as a result (which may not be the case with this particular change, but we don't know). It's pretty relevant what OpenSSL are currently saying themselves about certain releases though (see extract below)

The table below lists the latest releases for every branch

Note: The latest stable version is the 1.1.0 series.
The 1.0.2 series is our Long Term Support (LTS) release, supported until 31st December 2019.
The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support and should not be used.

KBytes      Date       File
5239      2017-May-25 13:09:51      openssl-1.0.2l.tar.gz (SHA256) (PGP sign) (SHA1)
5154      2017-May-25 13:09:51      openssl-1.1.0f.tar.gz (SHA256) (PGP sign) (SHA1)
1457      2017-May-24 18:01:01      openssl-fips-2.0.16.tar.gz (SHA256) (PGP sign) (SHA1)
1437      2017-May-24 18:01:01      openssl-fips-ecp-2.0.16.tar.gz (SHA256) (PGP sign) (SHA1)

***EDIT We have proceeded and run the CentOS update (as per the previous posted link) No detrimental effects that we can see in any tests and all public urls / functionality etc unaffected. This however does NOT alter the Plesk Panel status obvioulsy (as can be seen clearly below) That still remains very poorly outdated as sw-cp-server isn't changed by the CentOS update...

# openssl version
OpenSSL 1.0.2l  25 May 2017

# nginx -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled

# sw-cp-serverd -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled

 

[learning_curve]

As a matter of fact, sw-cp-server could be recompiled easily, with the latest version of OpenSSL linked to it (only 1.0.2 branch, though). There are two tricky parts: OpenSSL 1.1.0f and nginx > 1.11.2 are not yet supported by lua-nginx-module and some changes should be made in the nginx Makefile before running the compilation. Otherwise, it's yet another instance of 'recompile the nginx and install it via checkinstall'.

Now being in a different postion that at the start of this thread (i.e OpenSSL updated to 1.0.2 in our CentOS setup ^^ and your post above, could you post a link or a maybe set of clear individual comands on here for: "....recompile the nginx and install it via checkinstall" ? We can see several online, all of which appear contradictory so far

 

[Varrenlad]

Now being in a different postion that at the start of this thread (i.e OpenSSL updated to 1.0.2 in our CentOS setup ^^ and your post above, could you post a link or a maybe set of clear individual comands on here for: "....recompile the nginx and install it via checkinstall" ? We can see several online, all of which appear contradictory so far

Sure thing, I will post a step-by-step guide shortly after testing it on CentOS 7, since you consider this to be a possible solution.

It should be noted though, that there might be some patches vanilla nginx does not have included.
Judging from my experience — a small dedicated server with a bunch of side-projects, no WHMCS integration, no Multi-Server setups — everything is ok.

 

[UFHH01]

Hi Varrenlad,

I will post a step-by-step guide shortly

We would love new forum articles at => https://talk.plesk.com/articles/

 

[learning_curve]

Hi Varrenlad,
We would love new forum articles at => https://talk.plesk.com/articles/

Is this not a genuine Plesk issue if we are being honest? Usually, you @UFHH01 and/or @IgorG have comments, guidence, or instructions on items like this and are helpful and super accurate (or certainly have been in the past) when solving things like this. There was no participation on THIS thead either, which is the one that actually brought these Plesk inconsistencies to light, which again, is unusual, but there is a big queue of other active threads though we do recognise that, to be fair

Thanks again to @Varrenlad in advance, for his very kind assistence meantime!

 

[IgorG]

Well. We built sw-cp-server with a custom openssl version for Centos5/Debian6 to support SPDY. For other operating systems, the OS vendor openssl version is used.
If you want to use ssl_ecdh_curve - you can migrate/distupgrade to the latest supported Ubuntu version.
Also, you can submit the feature request to PleskUservoice for update openssl for sw-cp-server. We will consider this feature request if it will become popular enough.

BTW, could you please clarify why are you so worried about openssl for a sw-cp-server, while other services, like sshd, Apache, etc. work the same way with vendor's openssl version and you do not care?

 

[mr-wolf]

BTW, could you please clarify why are you so worried about openssl for a sw-cp-server, while other services, like sshd, Apache, etc. work the same way with vendor's openssl version and you do not care?

Apache is not connected to the outside world on a system that has Nginx running.
The Plesk interface is communicated to our clients and port 8443 is by now a "well-known port" and it always involves a login.
SSH is not used by clients

I would rather do a virgin installation than a distupgrade. That's the reason I still have my CentOS 5.11 version.
The OpenSSL-version on sw-cp-server doesn't depend on the client's OS, but on the OS on which you compiled it. You are the only supplier of a compiled sw-cp-serverd.

How is it possible that I have a more modern sw-cp-serverd on end-of-life CentOS 5.11 than the people running the latest CentOS 7? You already answered that, really. It still would not stop you from supplying a more modern one for CentOS 6 & 7 and Ubuntu 12, 14

BTW.... Alll this is not of such importance to me as it may seem. It started with helping out @learning_curve and his need to apply the same tweaks on his panel as he had on his normal nginx. I had no problem applying those changes while he did. Only after many back-and-forths this openssl-version of sw-cp-serverd turned out to be the culprit. I wasn't expecting that.

 

[learning_curve]

Well. We built sw-cp-server with a custom openssl version for Centos5/Debian6 to support SPDY. For other operating systems, the OS vendor openssl version is used. If you want to use ssl_ecdh_curve - you can migrate/distupgrade to the latest supported Ubuntu version. Also, you can submit the feature request to PleskUservoice for update openssl for sw-cp-server. We will consider this feature request if it will become popular enough. BTW, could you please clarify why are you so worried about openssl for a sw-cp-server, while other services, like sshd, Apache, etc. work the same way with vendor's openssl version and you do not care?

Our response: @mr-wolf is a long term user of Plesk and has several different servers / setups we think plus considerable historical experience. He will no doubt post his own answer to your BTW question, this being his thread etc. [EDIT] Indeed he just has ^^^ as we were typing this reply

We on the other hand, only started using Plesk in April this year, joining this helpful forum just after in May. We have just one server and obviously, our Plesk experience is minimal We use either nginx as proxy for apache and/or nginx only on our server (see signature for our O/S etc) The CentOS 7 vendor openssl version (as seen above) is out of date and not supported by openssl anymore (see above) yet CentOS currently haven't changed it for whatever reason. We "think" we have solved this "part" ourselves now (see above posted CODE data and THIS link etc ).

We now have nginx running openssl 1.0.2k 26 Jan 2017 . This is despite us having openssl 1.0.2l fully available on our server. Presumably, this is simply because our nginx was compiled in April (when we started with a new server / Plesk) i.e. before openssl 1.0.2l that was released 25 May 2017. As nginx is either proxy or unique for all our valid urls, this means we're pretty comfortable in this area now...so far. What we haven't done yet, because we don't fully know how to... yet is make openssl 1.0.2l available right across our server (e.g. Apache / Plesk / Everywhere Else etc) That's our specific interest in this case (and was stumbled across if we're being honest, when we were trying to solve a different challenge in THIS other thread, which once this thread is resolved, will also be resolved

 

[IgorG]

Our policy is the following - we try not to compile our own openssl and use the OS vendor's version if possible, except for exceptional cases, like with nginx (for http2).
If you want more recent openssl, then you need a more recent OS version, the benefit of distupgrade allows you to do this. Thus, we rely on the support of security issues on the part of the OS vendors. For example, openssl in CentOS7 is stable version and RedHat backports into their version security fixes from upstream. And if you want to use not stable but latest versions of components - you shouldn't use CentOS

 

[mr-wolf]

And if you want to use not stable but latest versions of components - you shouldn't use CentOS

The only CentOS I have was forced upon me at the time. I didn't resist too much as I also appreciate some diversity.
My preferred distro is Debian.

 

[learning_curve]

Our policy is the following - we try not to compile our own openssl and use the OS vendor's version if possible, except for exceptional cases, like with nginx (for http2)

Yes we needed to run http2 so this was an important choice factor initially for us (and still is)

If you want more recent openssl, then you need a more recent OS version

We did chose the latest, stable version of CentOS, so this isn't an exact science or rational to follow it seems

Thus, we rely on the support of security issues on the part of the OS vendors. For example, openssl in CentOS7 is stable version and RedHat backports into their version security fixes from upstream

This underlines our comment above really as CentOS / RedHat & Co have NOT actually adressed ALL the OpenSSL security issues, just the ones with the biggest current headline...

And if you want to use not stable but latest versions of components - you shouldn't use CentOS

That's a good point well made, but obviously, one that doesn't help us at this moment!

Note: The latest stable version is the 1.1.0 series. The 1.0.2 series is our Long Term Support (LTS) release, supported until 31st December 2019. The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support and should not be used.

The quote above is the current, official OpenSSL statement in an imaginary CentOS / RedHat & Co versus OpenSSL debate over what is a security risk and what is not.... The clear statement made on openssl 1.0.1 is hard to ignore however...especially when this is included within sw-cp-server AND CentOS 7

It's not our battle, nor do we want to watch it or get involved. We simply want to "fix" what's left to address after our previous upgrades and sw-cp-server is one of the items that's currently NOT fixed. We don't want (and shouldn't need) to change CentOS for another O/S just to achieve these fixes, in our opinion.

 

[Varrenlad]

Is this not a genuine Plesk issue if we are being honest? Usually, you @UFHH01 and/or @IgorG have comments, guidence, or instructions on items like this and are helpful and super accurate (or certainly have been in the past) when solving things like this. There was no participation on THIS thead either, which is the one that actually brought these Plesk inconsistencies to light, which again, is unusual, but there is a big queue of other active threads though we do recognise that, to be fair

Thanks again to @Varrenlad in advance, for his very kind assistence meantime!

That's actually an issue caused by a buildsystem's packages, since it uses OpenSSL libraries provided by system (there is no explicit '--with-openssl=' in the output of sw-cp-serverd -V).

Expand/Collapse Block: Let's begin an upgrade, shall we?

Part 0: Prepare Dependencies
Install build tools and headers.
Since we will build PCRE, zlib and OpenSSL from source codes, no EPEL's will be required:

yum install -y libtool gcc gcc-c++ autoconf automake make git rpm-build lua lua-devel

Create a folder for all the build process:

mkdir __temp && cd __temp
export __MOD_DIR=`pwd`

Install checkinstall from ROSA repository (unfortunately, only ROSA and Mageia build this package for rpm-based distros):

wget http://mirror.rosalab.ru/rosa/rosa2016.1/repository/x86_64/contrib/release//checkinstall-1.6.2.16-13-rosa2016.1.x86_64.rpm
yum localinstall ./checkinstall-1.6.2.16-13-rosa2016.1.x86_64.rpm

That leaves us with complete dependencies for the next part.

Part 1: Prepare nginx
Firstly, let's gather and unpack all the sources we need:

wget https://nginx.org/download/nginx-1.12.1.tar.gz && tar -zxf ./nginx-1.12.1.tar.gz
wget https://ftp.pcre.org/pub/pcre/pcre-8.41.tar.gz && tar -xzf ./pcre-8.41.tar.gz
wget https://www.zlib.net/zlib-1.2.11.tar.gz && tar -xzf ./zlib-1.2.11.tar.gz
wget https://www.openssl.org/source/openssl-1.0.2l.tar.gz && tar -xzf ./openssl-1.0.2l.tar.gz
wget https://github.com/simpl/ngx_devel_kit/archive/v0.3.0.tar.gz && tar -xzf ./v0.3.0.tar.gz
git clone https://github.com/openresty/lua-nginx-module

Then, configure nginx. We will use some additional CFLAGS to improve sw-cp-server's speed and security (so-called 'hardening': compiler adds ASLR, runtime checks for buffer-overflow):

cd ./nginx-1.12.1
./configure --prefix=/usr/share \
            --sbin-path=/usr/sbin/sw-cp-serverd \
            --conf-path=/etc/sw-cp-server/config \
            --error-log-path=/var/log/sw-cp-server/error_log \
            --http-log-path=/var/log/sw-cp-server/access.log \
            --lock-path=/var/lock/sw-cp-server.lock \
            --pid-path=/run/sw-cp-server.pid \
            --http-client-body-temp-path=/var/lib/sw-cp-server/body \
            --http-fastcgi-temp-path=/var/lib/sw-cp-server/fastcgi \
            --http-proxy-temp-path=/var/lib/sw-cp-server/proxy \
            --http-scgi-temp-path=/var/lib/sw-cp-server/scgi \
            --http-uwsgi-temp-path=/var/lib/sw-cp-server/uwsgi \
            --user=sw-cp-server --group=sw-cp-server \
            --with-openssl=$__MOD_DIR/openssl-1.0.2l \
            --with-openssl-opt=enable-ec_nistp_64_gcc_128 \
            --with-openssl-opt=no-nextprotoneg \
            --with-openssl-opt=no-weak-ssl-ciphers \
            --with-openssl-opt=no-ssl3 \
            --with-pcre=$__MOD_DIR/pcre-8.41 \
            --with-pcre-jit \
            --with-zlib=$__MOD_DIR/zlib-1.2.11 \
            --with-threads --with-file-aio \
            --with-http_ssl_module \
            --with-http_v2_module --with-ipv6 \
            --add-module=$__MOD_DIR/lua-nginx-module \
            --add-module=$__MOD_DIR/ngx_devel_kit-0.3.0 \
            --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -D_FORTIFY_SOURCE=2' \
            --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now'

After that few tweaks should applied to the Makefile, so ld would be able to link libraries into the executable:

sed -i 's/\&\& CC="\$(CC)" CFLAGS="-O2 -fomit-frame-pointer -pipe "/\&\& CC="\$(CC)" CFLAGS="-O2 -fomit-frame-pointer -pipe -fPIC "/' objs/Makefile
sed -i 's/\&\& CFLAGS="-O2 -fomit-frame-pointer -pipe " CC="\$(CC)"/\&\& CFLAGS="-O2 -fomit-frame-pointer -pipe " CC="\$(CC) -fPIC "/' objs/Makefile
sed -i 's/\&\& .\/config --prefix=\//\&\& CFLAGS=-fPIC .\/config --prefix=\//' ./objs/Makefile
sed -i 's/\.openssl no-shared no-ssl3/\.openssl shared no-ssl3/' objs/Makefile

Since everything is nice and ready, run build command and relax, since it will take quite a while:

make

Part 2: Install sw-cp-server
systemd tracks all its units, so we actually need to stop sw-cp-server, or it will be masked:

service sw-cp-server stop

Then the installation part begins:

mkdir -p /root/rpmbuild/SOURCES
mkdir ~/tmp
checkinstall

Create package with following values:

1 - Summary: [ HTTP server for Plesk control panel ]
2 - Name: [ sw-cp-server ]
3 - Version: [ 2.6 ]
4 - Release: [ 1 ]
5 - License: [ GPL ]
6 - Group: [ checkinstall ]
7 - Architecture: [ x86_64 ]
8 - Source location: [ nginx-1.12.1 ]
9 - Alternate source location: [ ]
10 - Requires: [ ]
11 - Provides: [ sw-cp-server ]

Checkinstall will prepare a package, so the only thing that's left is to install it and start the server:

rpm -i --force ~/rpmbuild/RPMS/x86_64/sw-cp-server-2.6-1.x86_64.rpm
service sw-cp-server start

As you can see, its files are tracked within package manager, the package itself can be easily reverted back and there is no need of marking this package to forbid upgrading, since it has higher version:

# yum whatprovides sw-cp-server
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.nsc.ru
 * extras: ftp.nsc.ru
 * updates: ftp.nsc.ru
sw-cp-server-2.4.0-centos7.17022818.x86_64 : Plesk control panel server
Repo        : @PLESK_17_5_3-dist

sw-cp-server-2.6.0-1.x86_64 : HTTP server for Plesk control panel
Repo        : installed

 

[learning_curve]

Wow! Fantastic effort gone into that post @Varrenlad We have already 'done' this bit:

wget https://www.openssl.org/source/openssl-1.0.2l.tar.gz

(see previous posts) but are guessing, that we'll just ignore the current settings / installation and do this again, along with everyting else, once we've taken a millions backups etc first of all... We'll report back soon

Very interested in @IgorG and @UFHH01 thoughts on this great approach / future Plesk interface etc

 

[UFHH01]

Hi learning_curve,

Very interested in @IgorG and @UFHH01 thoughts on this great approach / future Plesk interface etc

I do not recommend to fiddle around with "sw-cp-server", even that it might give you the overall feeling, that you increased security settings and I don't recommend to upgrade OpenSSL manually, as it cannot be guaranteed, that all dependent packages on your server are compatible.


The Plesk Control Panel and it's used "sw-cp-server" ( nginx ) is not insecure and meets high ( worldwide ) security standarts. While I can understand to use the possible latest stable "sw-nginx" ( nginx ) for your customers ( because of modern scripting / content / ... ), I don't see the same need for the "sw-cp-server" and I always try to wait for Plesk updates/upgrades/patches.
I don't jump into the overall discussion to meet "higher security standarts" with "ecdh curve" ciphers, because I am completely satisfied with the current "old" intermediate ciphers lists, provided my Mozilla and I am still with A+ rankings with all my configurations on all my servers, which leads to the fact, that there is no need ( yet ), to change that.

I trust Plesk and their developers to publish stable, secure packages for all supported operating systems and I am sure, that they will update/upgrade/patch their components in the future, to step up with the latest security innovations, as they always did that in the past - sometimes a bit faster, sometimes not so fast... but mostly faster than all the others.

 

[learning_curve]

Thank you @UFHH01 Great to read your much valued opinion, which has helped us a lot previously.

Still, it's a democracy that we live in, so having noted your recommendations and backed up absolutely everything just in case, we ran the line by line instructions contained in that clear & very helpful post by @Varrenlad anyway.....

The result (after testing ) was no issues and no resultant problems at all We had already updated OpenSSL as per our previous posts in this thread (our views on OpenSSL are different, but that's okay) so here's a summary:

Pre-Changes posted by @Varrenlad

# openssl version
OpenSSL 1.0.2l  25 May 2017

# nginx -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled

# sw-cp-serverd -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled

Post-Changes posted by @Varrenlad

# openssl version
OpenSSL 1.0.2l  25 May 2017

# nginx -V
nginx version: nginx/1.11.10
built with OpenSSL 1.0.2k  26 Jan 2017
TLS SNI support enabled

# sw-cp-serverd -V
nginx version: nginx/1.12.1
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.0.2l  25 May 2017
TLS SNI support enabled

We feel that this now fully resolves our other thread (and have updated that accordingly).
Thanks again to @Varrenlad and @mr-wolf for helping us.

This thread, belongs to @mr-wolf so its resolution status is his decision now

 

[learning_curve]

Only one small, residual question for @Varrenlad
We are assuming that the directory created as part of this build: __temp and all of its contents / sub-directories etc can now be safely removed?