8

I'm in a rather sticky situation. Currently my server supports TLS 1.2 but not TLS 1.3 (security protocols).

It has the following installed:

  • Linux version 2.6.32-431.29.2.el6.x86_64 #1 SMP
  • OpenSSL 1.0.1e-fips
  • Apache/2.4.37

It also has a lot of valuable content with a special setup that I don't want people to mess around with.

I read online that if I upgrade OpenSSL to version 1.2? and Apache to 2.4.38? then I can get TLS 1.3.

So I tried a similar setup on my local machine then I tried updating OpenSSL from source and it claims I need new GLIBC libraries which makes me think that I need to replace the entire operating system for OpenSSL.

Is there a way I can upgrade OpenSSL without reinstalling the OS? Or is there any other way I can enable TLS 1.3 with Apache without reinstalling the OS?

Giacomo1968
  • 58,727
mike_s
  • 87

5 Answers5

35

The 'simple' answer is 'you don't' - You run a modern supported OS and a reverse proxy to serve TLS in front of this server. This lets you keep your server setup as is, and since clients are talking to the reverse proxy, somewhat sidesteps some of the vulnerabilities from running a deeply outdated platform. That said there's a few wrinkles beyond just doing this.

Considering the age of the OS, one might assume it's either on older, deeply EOL hardware or running as a VM.

If it's the former - I'd suggest considering that your hardware dying would result in both your unique and special setup being lost. If it's the latter, you've a lot of options, like cloning the VM, and testing the software on a supported distro. It also means you can run a second VM for the proxy

However virtualising an outdated platform should be a stopgap - and you probably should be looking at upgrading to something supported. Once you've virtualised it, you probably can look at upgrading - since upgrading a clone is almost zero risk. Alma Linux has instructions for going from CentOS 6 to 7, from which you can go to a modern Red Hat-based distro of your choice.

Run5k
  • 16,463
  • 24
  • 53
  • 67
Journeyman Geek
  • 133,878
29

You don't. That server is a security nightmare.

Judging from the kernel, you're running RHEL 6, which was released in 2011, 13 years ago.

  • Full Support ended in 2016.
  • Maintenance Support ended in 2020.
  • Extended Life Cycle support ($800/year, doesn't cover everything) ended this year.

Your exact kernel version, 2.6.32-431.29.2, was shipped with RHEL 6.5, released in 2013. This suggests you're missing about 10 years of security updates.

On top of all this, RHEL 6 did not ship with Apache 2.4.37 (which was released in 2018), so this is a custom install. Depending on how that was done, it's possible your Apache has never received security updates.

Then there's the sites running on your server. If those are dynamic sites, perhaps using frameworks and databases, then those are also ancient, out of support, and at risk of attacks.

Your server is running ancient software that is 100% unsupported. It has not had security updates for about a decade, will never receive any new security updates. It is done. Upgrade to a more recent OS.

Let me be very clear:

It is irresponsible to keep this server connected to a network. You need to rebuild it on a modern, supported OS.

It also has a lot of valuable content with a special setup that I don't want people to mess around with.

... but upgrading means doing backups of gigs of data and basically wiping out the whole OS, something that may be time consuming and costly while potentially putting on downtime for the website guests. There has to be a way to update openssl without redoing the OS.

I feel for you, but this is the reality of (hosting) software. It needs maintenance. You cannot just leave it alone for 10+ years and expect it to be fine.

Your current situation is unsupported and insecure. This is not just about OpenSSL. The server will also break more and be increasingly harder to fix. Your comment about having to make backups also worries me. If this is important, those backups should exist already.

Rebuilding is just vital maintenance at this point. It should have been budgeted for. If not, it must be budgeted for now.

marcelm
  • 752
9

So I tried a similar setup on my local machine then I tried updating OpenSSL from source and it claims I need new GLIBC libraries which makes me think that I need to replace the entire operating system for OpenSSL.

It might be possible in theory to also compile a new Glibc and install it into a side directory, then compile OpenSSL to use that, and then compile Apache2 to use that.

But there is no guarantee that it'll work, especially as newer Glibc will also have raised its kernel requirements as well.

but upgrading means doing backups of gigs of data and basically wiping out the whole OS, something that may be time consuming and costly while potentially putting on downtime for the website guests.

It absolutely does not mean that. It means starting up a new server alongside the existing one, copying data and configuration from the server over to the new one, then switching your DNS domain name to the new IP address. (Or swapping the IP addresses, or changing the 'port forwarding' rules, etc.)

You can set up the new server over a week or however much it takes, then switch over with only a few minutes of downtime.

grawity
  • 501,077
2

You're stuck in a vicious cycle of dependencies, because your system is outdated. You can build a current glibc from source to address the immediate error. Install glibc outside the path, so that the old one is still available for your old apps. But your next error is going to be that your kernel is too old for that glibc. If you build a new kernel from source, it won't be compatible with your old libc

A workaround for this with some apps is to find an AppImage binary (works OK for new Firefox versions on outdated Linux). But I wouldn't trust an AppImage for something as important as OpenSSL

You're past the time for workarounds. Follow the other advice here - upgrade

Finally, there are several alternatives to OpenSSL - GnuTLS is the next most popular. But it's likely you'll get stuck in the same libc -> kernel trap

Lucas Copple
  • 29
-2

What are you serving from the Apache server? - I ask because there are lighterweight alternatives that can be statically linked all the way down. - Alternatively you can build your own newer OpenSSL, or use a different SSL library like others have recommended. E.g., https://wiki.archlinux.org/title/Apache_HTTP_Server/mod_gnutls

If you really can't upgrade things the vendor recommended way, then maintain a separate tree of all dependencies [e.g., by hand or using Arch Linux's pacman or NiXOS' nixpkgs], and change your init script for apache to use this apache server. Then the only major thing left to worry about is the kernel. Guide: https://wiki.archlinux.org/title/Pacman or https://nix.dev/manual/nix#chap-installation

Finally, it's not difficult to manually upgrade the kernel; if you can't use your proper system package manager (e.g., because everything on your system is EOL); for example, by following this guide: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/kernel_administration_guide/ch-manually_upgrading_the_kernel#s1-kernel-packages

This solution isn't perfect, for a start: you'll also have to consider upgrading your glibc, networking stack, software firewall, and logging subsystems. Upgrading to a supported version of a well-known Linux distribution is recommended.

Samuel Marks
  • 219