I tried to recompile the openssl 1.1.0g but now I do not know how to be sure that the version of openssl installed is the one compiled by me, should I recompile certbot?
Do you know a way to downgrade from Ubuntu 18.04 to Ubuntu 16.04 without losing data? If I downgrade the version of openssl that is downloaded from certbot is not always the one with the 3DES disabled?
OpenSSL 1.0.2 isn't "very old" and very much supported...
certbot isn't using OpenSSL directly, neither does it have anything to do with cipher suits. It's your webserver which uses OpenSSL for TLS cipher suit support.
As I said, is not as easy as "just" recompiling openssl, you would need to recompile all the programs that use those openssl libraries like your Apache web server.
This is something I wouldn't recommend because you could mess your entire server.
Not entirely. If you recompile the same version and overwrite the .so library files, so the file name and version is maintained, only restarting the webserver would suffice.
The blog you're mentioning compiles Apache statically, but that's not always the case. For example, on my Gentoo server, Apache is dynamically linking to OpenSSL:
server ~ # ldd /usr/lib64/apache2/modules/mod_ssl.so
linux-vdso.so.1 (0x00007ffdefbf8000)
libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007fc396f6f000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007fc396b35000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fc39692e000)
librt.so.1 => /lib64/librt.so.1 (0x00007fc396726000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fc3964ee000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc3962ce000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc3960ca000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc395d08000)
libz.so.1 => /lib64/libz.so.1 (0x00007fc395af1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc397418000)
server ~ # equery b /usr/lib64/libssl.so.1.0.0 /usr/lib64/libcrypto.so.1.0.0
* Searching for /usr/lib64/libssl.so.1.0.0,/usr/lib64/libcrypto.so.1.0.0 ...
dev-libs/openssl-1.0.2o-r3 (/usr/lib64/libcrypto.so.1.0.0)
dev-libs/openssl-1.0.2o-r3 (/usr/lib64/libssl.so.1.0.0)
server ~ #
Therefore, a restart of the webserver would suffice.
Also, Apache isn't that big to be a problem to recompile 
although statically linking (and thus the need to compile everything) would slow things down a bit.
I don't know how Apache is compiled in Ubuntu but if ssl libraries are compiled statically you would need to recompile Apache to use the new one but yes as you say, if it is dynamically compiled it could work
server apacheubuntu $ ldd ./usr/lib/apache2/modules/mod_ssl.so
ldd: warning: you do not have execution permission for `./usr/lib/apache2/modules/mod_ssl.so'
linux-vdso.so.1 (0x00007ffc897ba000)
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
libc.so.6 => /lib64/libc.so.6 (0x00007fa57bcdc000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa57c2c7000)
server apacheubuntu $
Dynamically linked
1 Like
I recompiled the same version enabling weak-ciphers now what should I replace?
I don't know how great the idea is of mixing binary packages and recompiling software with the intention of overwriting those binary packages on a distribution like Ubuntu. Also, I have no experience with it and I wouldn't recommend it. It would make things very difficult for your package manager (apt I guess).
If you would take down this path (which I can understand seeing your predicament), I think you should read the following guide: CompilingSoftware - Community Help Wiki
It should help you compile the package properly and install it in a proper way in your system.
Also, you should check the build log for the official package: https://launchpadlibrarian.net/375273210/buildlog_ubuntu-bionic-amd64.openssl_1.1.0g-2ubuntu4.1_BUILDING.txt.gz
Especially, the configuration options are of important: ./Configure no-shared --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/x86_64-linux-gnu no-idea no-mdc2 no-rc5 no-zlib no-ssl3 enable-unit-test no-ssl3-method enable-rfc3779 enable-cms enable-ec_nistp_64_gcc_128 debian-amd64
Obviously, you should add enable-weak-ssl-ciphers to that list
By using the same --prefix and --openssldir, you'll make sure the existing OpenSSL files are overwritten, so you'll know for sure Apache will use your freshly compiled libraries, not the original ones.
Another thing: you're compiling OpenSSL. Apache depends on libssl, which uses the openssl package as source. I really have NO idea how that all relates to each other and why Apache doesn't simply depend on OpenSSL.. Some Debian/Ubuntu-thing I guess, which I have no experience with. I assume compiling and installing the openssl source package would suffice, but I'm not sure.
2 Likes
Iāve tested it on Ubuntu 18.04 compiling from the source the same openssl version 1.1.0g and Apache can use 3DES 
sudo su -
cd /usr/local/src/
apt install build-essential make zlib1g-dev libxml2-dev
wget https://www.openssl.org/source/openssl-1.1.0g.tar.gz
tar zxvf openssl-1.1.0g.tar.gz
cd openssl-1.1.0g
./config shared --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/x86_64-linux-gnu no-idea no-mdc2 no-rc5 no-zlib no-ssl3 enable-unit-test no-ssl3-method enable-rfc3779 enable-cms enable-ec_nistp_64_gcc_128 enable-weak-ssl-ciphers
make
make install
systemctl restart apache2
Well, before restart Apache, you should change SSLCipherSuite from:
SSLCipherSuite HIGH:!aNULL
To something like this:
SSLCipherSuite MEDIUM:!aNULL
or better something like this:
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
If I check now the ciphers used by Apache I can see DES-CBC3-SHA listed so IE 8 from Windows XP could connect using TLS 1.0.
$ cipherscan localhost
...
Target: localhost:443
prio ciphersuite protocols pfs curves
1 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-521,521bits prime256v1,secp384r1,secp521r1
2 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-521,521bits prime256v1,secp384r1,secp521r1
3 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-521,521bits prime256v1,secp384r1,secp521r1
4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,2048bits None
5 DHE-RSA-AES256-SHA256 TLSv1.2 DH,2048bits None
6 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
7 AES256-GCM-SHA384 TLSv1.2 None None
8 AES256-SHA256 TLSv1.2 None None
9 AES256-SHA TLSv1,TLSv1.1,TLSv1.2 None None
10 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-521,521bits prime256v1,secp384r1,secp521r1
11 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-521,521bits prime256v1,secp384r1,secp521r1
12 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-521,521bits prime256v1,secp384r1,secp521r1
13 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,2048bits None
14 DHE-RSA-AES128-SHA256 TLSv1.2 DH,2048bits None
15 DHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
16 AES128-GCM-SHA256 TLSv1.2 None None
17 AES128-SHA256 TLSv1.2 None None
18 AES128-SHA TLSv1,TLSv1.1,TLSv1.2 None None
19 ECDHE-RSA-DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-521,521bits prime256v1,secp384r1,secp521r1
20 EDH-RSA-DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
21 DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 None None
And all is working fineā¦ seems so
@CrazyminerMC, if you want to try above method, keep in mind that if openssl libssl1.1 packages are updated you will need to run make install again from openssl source dir to override the libraries and binaries updated by the Ubuntu packages. Also, keep in mind that doing something like this you could mess completely your system so do it at your own risk.
In case you want to reinstall openssl Ubuntu packages, use this command:
apt install --reinstall openssl libssl1.1
Good luck,
sahsanu
2 Likes
This always works moving forward, but will only work moving backward if the new version of the library you're using hasn't added any symbols that the application uses since the old version you're moving back to. (Or if the application hasn't been rebuilt against the new version yet, but with Apache having security updates all the time you can be sure it has in a binary distro like Ubuntu.)
In the case of OpenSSL 1.1, a lot has changed since 1.0 and most applications, including Apache, got some changes to match. So it would be necessary to recompile Apache to move backward in this particular instance.
EDIT: The earlier conversation revolved around rolling back to openssl 1.0, but by this point you all had moved on to discussing recompiling openssl 1.1, so this isn't really relevant. My apologies.
1 Like
With binary distributions, its often useful to split the end result of compiling one source package, like openssl, into multiple binary packages. For instance, one might want the openssl libraries, but not the command-line tools.
Debian takes this to an extreme, and produces one package for each library with the SONAME embedded. This way you can create a new openssl1.0 source package when openssl 2.0 comes out, and it can build a libssl1 package that sits along the new libssl2 package that the old consumers can use. (It's basically a poor man's replacement for Gentoo's slots.)
This level of splitting isn't necessary in some distributions. For instance in Fedora/RHEL land, the SONAME is automatically injected into every package that ships C/C++ libraries as additional packaging metadata. When you build a package that depends on a library, a requirement on that additional SONAME metadata is also injected. So you can call the old and new openssl packages anything you want because RPM will figure it out based on the injected SONAME requirements not the package names, and it isn't necessary to split binary packages as much. You just have openssl with the tools and openssl-libs with the libraries.
1 Like
I would strongly suggest pinning openssl and related packages in APT so your server doesn't break randomly on upgrade. You would need to track openssl security updates manually in this case.
1 Like
Thank you very much, it seems to work
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.