nghttp2 is an implementation of HTTP/2. It comes as a set of libraries and tiny programs using them – a client, WWW server and a proxy. I've started using the last one, nghttpx, as a reverse proxy in few project and I'm quite content with.

Recently I implemented sd_notify() support in it. Explicit main PID tracking and readiness signaling works like a charm with systemd. sd_notify() protocol let us reliably supervise service even during hot-swap. That is, after receiving SIGUSR2, nghttpx executes new binary and tells systemd “this is main process now”. Old binaries can finish serving current requests and exit.

The pull request, after a round of comments and fixes, was merged into trunk after v1.19.0, so it will be in the next release. If you're willing to test, I'd ask you to check USR2 graceful shutdown branch, also. At the moment you need to manually SIGQUIT old processes after hot-swap. This branch is supposed to automate it.

And if you're maintain nghttp2 package in a distribution, please be sure to check changes in the service unit file.

Od końca zeszłego wieku używam IPSec to zabezpieczania ruchu sieciowego. Zgodnie z dziwactwami opensource, FreeS/WAN morfował się przez Openswan do Libreswan i strongSWAN. Równolegle korzystałem też z racoon. Interesował mnie racoon2 z uwagi na integrację z Kerberosem (KINK), ale ten wygląda na porzucony. Ostatnio zainteresował mnie Wireguard, który do niektórych zastosowań jest całkiem fajny.

Może najpierw zalety. Wireguard oparty jest na współczesnych algorytmach i protokołach kryptograficznych, autor chwali się całkiem niezłą wydajnością i niskimi opóźnieniami. Konfiguracja jest bardzo prosta i działa w zasadzie od strzału. W systemie pojawiają się dodatkowe interfejsy sieciowe, w które można zajrzeć tcpdumpem albo wyroutować w nie ruch do szyfrowania.

Miłym dodatkiem jest że tak powiem moshowatość. Po jednokrotnym nawiązaniu sesji, wymiana zaszyfrowanych pakietów odbywa się nawet jeśli jednej z końcówek zmienia się adres IP (oczywiście jeśli po zmiane odezwie się on do drugiej). Trudno więc wpaść w sytuację, w której sesja jest niby zestawiona, a ruchu trafia w czarną dziurę.

Są też wady. W zestawieniu z IPSec, Wireguard całkowicie ignoruje aspekt zarządzania kluczami. Końcówki mają swoje klucze publiczny z prywatnym, ale administrator pozostawiony jest sam sobie z kwestią ich propagacji. A to często jest najbardziej skomplikowane zagadnienie przy opracowywaniu architektury rozwiązania szyfrującego.

Jak można się domyśleć z obecności dedykowanego interfejsu sieciowego, Wireguard obsługuje tylko tryb tunelowy. Szkoda, bo o wiele częściej korzystam z trybu transportowego. Sieciowo jest bardziej oczywisty. Części scenariuszy nie da się za pomocą WG zrealizować. Można za to inne, jak np. przeniesienie tylko szyfrowanego interfejsu sieciowego do przestrzeni nazw jakiegoś kontenera. Niektórzy tego potrzebują, o czym świadczy chociażby pojawienie się w Linuksie interfejsów ip_vti*.

No i największa wada, WireGuard jeszcze nie jest w jądrze Linuksa. Jason (autor WG) ma plan włączenia gdzieś w drugiej połowie roku. Od tego uzależniona jest szeroka dostępność w dystrybucjach i włączenie obsługi w systemd-networkd. Jak na razie dostępne są repozytoria i samokompilujące się moduły dla różnych dystrybucji.

WireGuard ma jakąś taką trudną do uchwycenia elegancję i czuję, że coś z tego będzie. Może nawet pojawi się wsparcie dla innych niż Linux systemów.

Red Hat zdecydował się na nietypowy krok w swojej dystrybucji Linuksa. W wersji RHEL 6.9 usuną lub ograniczą obsługę przestarzałej kryptografii. Zmiana dotknie SSLv2, MD5, RC4 itp. W aktualizacji stabilnej wersji nie powinno się zmniejszać zakresu obsługi, jednak ten krok wymusiły odkryte problemy z bezpieczeństwem.

Zmiana nie dotknie osób ponadprzeciętnie dbających o bezpieczeństwo, bo Ci admini już dawno wprowadzili zalecenia z Applied Crypto Hardening PDF. I przeprowadzili analizę, do jakiego stanu można podśrubować security, żeby za bardzo nie utrudnić innym. Ja przykładowo na serwerze WWW chciałem ograniczyć TLS tylko do v1.2/1.3. Ale sprawdziłem, i oznaczałoby zablokowanie dostępu osobom z Androidem <5.0. Na takie poświęcenie nie jestem gotów ;-). Nie każdy działający tablet z 4.x można zaktualizować, a jeśli ktoś wchodzi na bloga mobilnie, to zazwyczaj jest w trudnej sytuacji bez dostępu do czegoś lepszego. Zablokowanie mu dostępu w takiej chwili byłoby bezsensowne. A może i okrutne, bo pewnie popsuł sobie dostęp do internetu i szuka sposóbu na naprawę.

Przy okazji, wspomniany dokument w wielu przypadkach specyfikuje wprowadzenie ciągu określającego dozwolone algorytmy w postaci EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+…. Jest to dosyć nieelastyczne, w Fedorze można to zrobić lepiej: wystarczy podać PROFILE=SYSTEM. Wtedy poziom zabezpieczeń dla wszystkich usług na raz ustawimy poprzez manipulacje w /etc/crypto-policies/ i wywołanie polecenia update-crypto-policies.

Tor ma taką fajną umiejętność tworzenia ukrytych adresów z wykorzystaniem domeny .onion – jak http://sejnfjrq6szgca7v.onion, http://uj3wazyk5u4hnvtk.onion/ czy https://facebookcorewwwi.onion. Ma też drugą fajną umiejętność, dzięki czemu można udostępnić łączność do takich adresów wszystkim urządzeniom w sieci lokalnej, nawet nie znającym Tora.

Sztuczka działa dzięki temu, że Tor potrafi działać jako serwer DNS i syntetyzować rekordy dla domeny .onion. W konfiguracji podajemy z jakiej podsieci mają być zwracane. Trzeba tylko przekierować routing ww. podsieci na klienta tor i voila. Tor odbierając pakiety skierowane na adres X wie, że ten adres zwrócił po zapytaniu o xyz.onion i odpowiednio kieruje połączenia.

Konfiguracja jest prosta. Najpierw wybieramy sobie ta specjalne podsieci:

VirtualAddrNetworkIPv4 10.192.0.0/10
VirtualAddrNetworkIPv6 [fceb:001a::]/32

Dwa, każemy Torowi obsługiwać DNS na naszym wewnętrznym interfejsie. Dobrze się chwile zastanowić, czy nie mamy tu już przypadkiem jakiegoś unbound, deadwood, systemd-resolved czy innego serwera DNS nasłuchującego na tym porcie. Jeśli tak, trzeba go wyłączyć. There can be only one!

DNSPort 203.0.113.2:53
DNSPort [2001:db8:85a3::8a2e:370:7334]:53
AutomapHostsOnResolve 1

Na koniec konfiguracji Tora zostaje kazać mu nasłuchiwać jako transparetne proxy, tak jak umie to Squid:

TransPort 0.0.0.0:9040
TransPort [::]:9040

Zostały jeszcze 2 drobiazgi – przekierowanie ruchu do magicznych podsieci na naszego cichociemnego tora:

iptables -A PREROUTING -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040
ip6tables -A PREROUTING -p tcp -d fceb:001a::/32 -j REDIRECT --to-ports 9040

Oraz poinformowanie naszego głównego DNS, że domenę .onion obsługuje ktoś inny:

  Zone name: onion.
  Zone active: TRUE
  Zone forwarders: 2001:db8:85a3::8a2e:370:7334, 203.0.113.2
  Forward policy: first
----------------------------
Number of entries returned 1
----------------------------

W tym momencie na każdej stacji powinno działać:

$ host facebookcorewwwi.onion
facebookcorewwwi.onion has address 10.207.220.42
facebookcorewwwi.onion has IPv6 address fceb:1a:39ba:123f:1d30:72d1:a46e:1f93

$ wget sejnfjrq6szgca7v.onion
--2016-11-03 13:14:09--  http://sejnfjrq6szgca7v.onion/
Resolving sejnfjrq6szgca7v.onion (sejnfjrq6szgca7v.onion)... 10.221.133.34, fceb:1a:437e:551f:ef67:b2c2:bb64:ece5
Connecting to sejnfjrq6szgca7v.onion (sejnfjrq6szgca7v.onion)|10.221.133.34|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 14760 (14K) [text/html]
Saving to: 'index.html'

index.html  100%[======================================================================================>]  14.41K  34.0KB/s    in 0.4s

2016-11-03 13:14:10 (34.0 KB/s) - 'index.html' saved [14760/14760]

Konfigurację dla innych systemów znajdziemy oczywiście na stronie projektu.

As for today, latest version of systemd is v231, released in July 2016. This is the version that will be in Fedora 25 (to be GA in three weeks). That's quite a long time between releases for systemd – we used to have a new version every two weeks.

During the hackfest at systemd.conf 2016, I've tried to tackle three issues biting me with Fedora 24 (v229, released in February this year) and F25. The outcome was… unexpected.

First one was a minor in issue in networking part of systemd suite. Data received via LLDP protocol had last letter cut off. I started searching through networkd code, looking for this off-by-one error. But it looked different, the output I was seeing didn't match the code. Guess what? LLDP presentation was reworked shortly after v229. The rework fixed the issue, but Fedora 24 newer received the backport. Which is fair, as the issue was cosmetic and not really important.

So I gone through another cosmetic issue which was annoying me. In list-timers display, multi-byte characters in day names were causing columns to be misaligned. I've discussed the issue as it appeared in Fedora 25 (v231) with Zbyszek during the conference, and I was ready to fix it. Again, I wasn't able to find the code, because it was reworked after v231 and the problem was corrected. I just wasted some time digging through codebase.

Last issue, which I didn't have time to chase, was more serious. Sometimes output from services stopped appearing in journal. It turned out to be genuine bug (#4408). Zbyszek fixed it last week, it will be in v232. This is serious flaw, the fix should be backported to v231 in Fedora 25 and other stable versions.

In summary, long development periods increase the need to do backports, escalating the workload on maintainers. Delays cause contributors using stable versions to lose time looking through evolved code, which may no longer be buggy. Prolonged delays between stable releases make the distributions ship old code. Even Fedora, which tries to be first.

I started August with a trip to Kraków. On Monday I worked with people at my company's remote office. Remaining of the week was for FLOCK, an annual gathering of Fedora users and developers. It was fantastic!

I've met few old friends, made new ones, but most importantly I got to put faces to various nicks and names from Fedora mailling lists, IRC channels, bugzilla and so on. The schedule was packed, with 5 tracks going in parallel and ongoing discussusions in the hallways. I'm waiting for the videos to be uploaded to see everything I've missed.

Additionally – as it happens – agenda was partly in flux during the conference. Big kudos to organisers for providing up-to-date analogue board with all the sessions. It was in central location and was tremendously helpful:

Of course on-line schedule was being constantly updated, too.

There were many great talks, sessions and workshops (most of which I haven't seen yet ;-), but I was really impressed by “Secure Automated Decryption” by Nathaniel McCallum. Go watch it now. If you are short on time, jump to 16:55 for the really cool stuff. (It's automated LUKS with flexible policies, using Tang and Shamir's Secret Sharing; there's also a short demo video, too):

I also strongly recommend “Progress on Enterprise Fedora Desktop”. Awesomely integrated SSO between GNOME, FreeIPA and various web apps.

Content, organisation, events… everything was top-notch. I was very happy to be a part of FLOCK!