Filip Chabik

DevOps Engineer, Husband & Dad.

TLS version and ciphers from NGINX in ELK →

Claudio Kuenzler:

In the past 20 years we have moved from SSL to TLS (yet we’re still talking about SSL certificates, funny isn’t it). According to Wikipedia’s Transport Layer Security page, this is the release history:

SSL 1.0 -> Never officially released due to security flaws
SSL 2.0 -> 1995, deprecated in 2011
SSL 3.0 -> 1996, deprecated in 2015
TLS 1.0 -> 1999, deprecated in 2020
TLS 1.1 -> 2006
TLS 1.2 -> 2008
TLS 1.3 -> 2018

It’s crazy to think that the modern TLS 1.2 is already 12 years old. Not long ago I dropped everything older than 1.2 and introduced support for 1.3 + I’m using only modern ciphers. But this is easily done on a blog with almost no traffic.

Building kernel w/ ZFS & perf on Ubuntu

27th February 2020

One of my New Year’s resolution was to get back a bit closer to the lower level parts of Linux. And what’s there lower than the kernel itself? I always preferred vanilla kernel, even when I was fooling around with Gentoo, and this hasn’t changed. In December I started with preparing first builds. Nothing too fancy as it’s only for my personal usage, but I still find it worth going through. I hit four issues I needed to fix in order to be able to use these kernels on my machines:

  1. ZFS has to be supported (as I use it on my servers).
  2. Wireguard has to be built-in (cause vanilla releases occur way more often than the distro provided ones and re-running dkms each time makes no sense to me).1
  3. perf has to be part of the build.2
  4. Entire process has to be streamlined and possibly handled by some kind of CI.
  1. Worth mentioning that starting with kernel 5.6 Wireguard is going to be in the main tree. 

  2. Part of the linux-tools

NGINX Extended Security Update (2) →

NGINX before 1.17.7, with certain error_page configurations, allows HTTP request smuggling, as demonstrated by the ability of an attacker to read unauthorized web pages in environments where NGINX is being fronted by a load balancer.

That’s the essence of the CVE-2019-20372. Yet again, as I mentioned in my NGINX Extended post I was not going to work on 1.14.x branch any more with the exception of security updates – this is the case for such exception. Both 1.14.x for Xenial (16.04 LTS) and 1.16.x for Bionic (18.04 LTS) were patched against this vulnerability and are available from my PPA. On Docker Hub I bumped up only the 1.16.x branch as usage for 1.14.x is pretty much non-existent.

Backporting BCC & bpftrace

4th January 2020

I’m following Brendan Gregg’s performance-related content for years now. I started when he was still in Joyent, later on I bought his Systems Performance book and I get back to it whenever I’m doing any profiling. Now I follow closely all of the latest work he’s doing on BPF front. There’s a small problem though. On the dependency tree of production-grade systems, I’ve got the following:

  • stable OS (Debian 10 “Buster” or Ubuntu 18.04 “Bionic Beaver”)
  • latest kernel (5.0+)
  • latest tracing tools (BCC & bpftrace)

Two first are easy – both Debian and Ubuntu are now providing ways for having relatively new kernel up and running – former with buster-backports1 and latter with HWE.2 The third one becomes a small hassle, at least in Ubuntu world.

bpftrace is currently not available for bionic at all. There’s no technical limitation here – it’s just the package was never built for it.3 I decided to backport it then.

  1. Version 5.3.9-2~bpo10+1. 

  2. Version 5.3.0.24.93. 

  3. In contrast, buster has 0.8+git60-gccac69c2239b-2.