0

I am on an Intel x86_64 CPU architecture platform running a Debian Bullseye Linux distro. On that platform runs a custom application. This application is a 32-bit software running as a systemd service and has many dependencies, some of them being libraries from Qt5 v5.15.2 (such as libqt5network5 module) and openssl1.1. On the new versions of openssl and Qt5, SSLv3 protocol is deprecated. However, the custom application only supports SSLv3 protocol for network communication. I have added back SSLv3 support in openssl1.1 and whenever I try to use the following command:

# openssl s_client -connect <my-ip>:<my-port>

I get a warning in the custom application journal logs:

QSslSocket::startServerEncryption Attempted to use an unsupported protocol

My goal now is to add back the support for SSLv3 protocol in the libqt5network module in order to remove that warning and have a proper connection. In addition, I need to have libqt5network5 module in a 32 bit architecture to be compatible with the custom application.

The steps I have done so far are:

I have downloaded Qt5 source code I tried to revert the commit (OpenSSL: drop support for SSLv2 and SSLv3, commit hash ID: 455951f59074d6457fd2d10720ac3cbdaa966076.) After many hours of battling with compilation and makefile errors, I have successfully built Qt5 libraries. I created a .deb package of Qt5 and installed it in the platform's root file system However, I keep getting the warning as if nothing has changed. I might have not reverted correctly the commit or there may be more things to do. I tried to modify the source code further but this dives me into more compilation errors.

My question is what should I change in the Qt5 source code in order to achieve my goal? I've been racking my brain over this problem for 3 weeks now and can't find a solution.

PS: Sorry if there is any confusion or lack of information in my question. I am ready to give you all the necessary information. PS-2: I know SSLv3 is deprecated for security reasons but it is a requirement and I cannot change that.

Thank you for your time.

1 Answer 1

1

Prologue (you already know this)

The easier solution, and also, the only secure solution, seems to me to just use a modern version of TLS on the side that still relies on SSLv3; that should not be hard. The APIs of these libraries didn't really change, they just support more modern TLS than SSL3 now. SSL3 was deprecated 12 years (!) ago, and in 2014 a relatively trivial attack (POODLE) was found, and several easy-to-use tools to exploit that were found.

So, if you're using SSL3 today without POODLE mitigations, then you really can't call your communications encrypted. They're weakly obfuscated, and it takes but an internet connection to decrypt your messages.

Covering your ass

I understand this is a requirement, but as a responsible software developer you should clearly have written sign-off from your boss or client that says "yes, this is insecure, and we still want Chris to spend time and thus money on it. He pointed out the vulnerabilities", just to keep you out of the line of fire once things go wrong.

I propose that the team running that unsecure service gets the problem of setting up a TLS proxy on the same machine, so that SSL3 traffic never leaves the machine; just put the same data in modern TLS1.3 packets and thus solve both the security and the software engineering problem at once. (Of course, again, the right thing to do is fix the darn application, not to work around it, but I understand how legacy software works.)

How to do it

THAT BEING SAID, you need to actually replace the Qt5 libraries that your program is using, and that means you cannot just install some version of Qt5 and hope a) things don't break and b) the new version actually replaces what you've been using.

So, instead of building the Qt5 source from hand, you need to rely on debian mechanisms to build a compatible Qt5 package, with your patch applied (which, again, I'll never tire to say, is a bad idea).

So, following steps:

upfront, uninstall what you've manually built. It will otherwise cause problems.

  1. install debian development tools:
    sudo apt-get install build-essential fakeroot devscripts
  2. find out which debian package contains the library you want to modify.
  3. Go to https://packages.debian.org, and find it, in the version for your version of debian
  4. on the right hand side of the package information page, you'll find a link to the .dsc file of the source package (which my guess here is qtbase-opensource-src, so the link is this
  5. copy that link;
  6. on your debian develop machine, make a new directory and cd into it
  7. dget THE_LINK_YOU_JUST_COPIED
  8. Make sure you install all build dependencies:
    mk-build-deps; sudo apt-get install ./*build-deps*.deb
  9. go into the extracted source in the subfolder of that, cd debian
  10. prepare by applying all the patches that are already there: quilt push -a
  11. Start a new patch: quilt new enable_ssl_v3_verybadidea
  12. since you know which files you're going to change: quilt add file1 file2 file3 …
  13. afterwards, edit the files
  14. commit the changes to the patch quilt refresh
  15. now go back to the debian extracted top directory, and do a build:
    debuild -b -uc -us
  16. in the directory that you created in 5., there's now new qt5 debian packages with your modifications that you can directly install, which then replace the qt5 packages. sudo apt-get install ../*.deb to install these!

Why is it so complicated?

well, we'll both agree building Qt5 is complicated. Debian has figured out how to do that for you, so we should be using their scripts. Also, we need to build exactly like debian, because we need the library to be compatible with debian – otherwise, you'll damage the functionality of other debian packages which rely on qt5.

So, we have to do things the debian way. The advantage is that we get .deb packages, which we can just copy to any machine that we want to deploy our application on, and install them with a single dpkg -i package.deb or apt-get install ./package.deb command.

When changing the files to make them do what we want, we had to extract a patch that the debian build process then applies to the "fresh" sources in order to make sure the build is really reliable.

You will also have to

  • pin the installed packages, so that an update from debian that might fix other bugs doesn't overwrite your files (this is true no matter how you install things)
  • forward-port your patch (copying the patch file from debian/patches in your unpacked source, and adding it to debian/patches/series) to any update that you build manually.

All in all, the requirements you have now made you the actual maintainer of Qt5 for your systems, totally regardless of how you build your Qt5. If that is not a strong argument for management to consider finding another solution than to damage the security of the user system, then I don't know, that's something I might be taking into the next salary negotiation, because other companies will not force you to do that.

3
  • 1
    You left out, "For the rest of time you have to monitor Qt and OpenSSL for vulnerabilities, and when a critical one is discovered, do it all again with the added task of verifying the updated Qt or OpenSSL code doesn't break your patching." Aug 25, 2023 at 12:16
  • @AndrewHenle fair point, added to the answer. Aug 25, 2023 at 12:21
  • Thank you @MarcusMüller for your answer. Actually, I don't know the files to patch. That is the problem. The commit I've given in my question seems to be one of many to revert the support for SSLv3. So it seems there are more commits that change other files related to the support of SSLv3. I used the revert commit as a patch but even with this, it seems there are still things not as they should be. And thank you as well for your guidance regarding the security and how we should proceed in this matter. I will take what you said into consideration. Aug 29, 2023 at 8:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .