Viele Entwicklerinnen und Systemadministratoren haben ein leicht gestörtes Verhältnis zu OpenSSL oder gleich X.509 im Allgemeinen. Unendlich lange Befehlsketten, die sich die niemand jemals merken kann, ein kaum durchblickbares System von CAs und deren Kindern, eine stattliche Liste von Sicherheitsproblemen und vieles mehr lässt sich dort im Keller finden.

Es geht [gut voran] 1, mit unserer neuen Arbeitsweise sind wir inzwischen gut vertraut und sie ist uns in Mark und Bein übergegangen. Wir wollen euch nun mal kurz unsere Bürotür öffnen und euch zeigen, woran wir gerade arbeiten und wie die nähere Zukunft aussieht.

Wir tauschen unser HTTPS-Frontend aus

Inzwischen ist es spruchreif: Wir tauschen unser HTTPS-Frontend aus. Bisher haben wir auf [Pound] 3 gesetzt, mit Uberspace 7 setzen wir auf [nginx] 4. Das bringt folgende Vorteile:

Jonas und ich waren in der letzten Woche in Prag, um die Write the Docs Europe zu besuchen. Es war für uns beide die erste Write the Docs und, um das schonmal vorwegzunehmen, sicher nicht die letzte!

Warum eine Doku-Konferenz?

Wir wollen unsere Dokumentation verbessern. Nicht, dass sie schlecht wäre, wirklich gut ist sie aber eben auch nur bedingt. Ich weiß, viele von euch mögen sie sehr und ich auch, aber unsere wachsende Popularität stellt uns da gleich vor mehrere Herausforderungen:

Wie ihr im aktuellen Blogpost der Uberspace-7-Reihe lesen könnt, ändert sich im Bereich unserer Shellscripts gerade eine ganze Menge. Aus Config-Dateien werden Ansible-Facts, aus Bash werden Playbooks oder Python-Skripte. Um all diese Teile wieder unter einen Hut zu bekommen, müssten wir einen Ausflug in die Softwareentwicklung machen.

Viele unserer Features - wie das allseits beliebte uberspace-add-domain - erfordern, dass wir euch mehr Rechte einräumen, als ihr eigentlich haben dürft. Auf diesem Weg könnt ihr beispielsweise mit uberspace-add-domain auf die Konfiguration unseres Webservers oder mit uberspace-add-port auf das iptables-Ruleset in engen Grenzen und indirekt, aber dennoch schreibend, zugreifen.

From stateful to stateless - the whole enchilada

Bei Uberspace habt ihr die Möglichkeit, eure eigenen Domains aufzuschalten, Ports in der Firewall zu öffnen und Zertifikate einzutragen. Bei all diesen Aktionen interagiert ihr mit Konfigurationsdateien, auf die ihr eigentlich keinen Zugriff habt - mit dem Webserver, unserem HTTPS-Frontend und der Firewall.

Wie ihr sicherlich schon auf Hackernews oder anders wo gelesen habt, kursiert gerade eine “neue” Lücke für diverse GCI-Applikationen im Netz: httpoxy.

Konkret geht es darum, dass der Proxy-HTTP-Header des Clients aufgrund der CGI-Spezifikation in der Umgebungsvariable $HTTP_PROXY landet. Diese wird von unzähligen Applikationen dazu benutzt, Verbindungen nach außen aufzubauen. Somit hätte ein potentieller Angreifer die volle Kontrolle über diese Aufrufe, die zum Beispiel die API eines Zahlungsanbieters als Ziel haben können.

In Uberspace 7 - Episode 2 haben wir das Thema Tests angerissen:

Nachdem Features definiert wurden sollte man anfangen, Tests zu schreiben und damit die Anforderungen an die Features genau definieren.

Aber wie sieht so ein Test eigentlich aus? Beispiel: Jeder User bekommt mit seinem Account eine Mailbox, die er mit seinem SSH-Kennwort abrufen kann. Ein Test dafür würde folgendermaßen aussehen:

1. Einen User auf dem Server anlegen
2. Ein SSH-Passwort setzen
3. Eine Mail an User schicken
4. Der User loggt sich per IMAP ein
5. User holt Mail 1 per IMAP ab (Es kann nur eine Mail da sein, der User ist ganz frisch angelegt und das Postfach war vor der Testmail leer)
6. Wir überprüfen den Inhalt der Mail auf einen bestimmten String
7. Profit!

Diesen Test haben wir mit Ansible realisiert. Und jetzt mal Butter bei die Fische, so sieht das in Code aus: Die Variablen testuser und dummypassword haben wir bereits an anderer Stelle definiert, in ansible_fqdn steht der Hostname des Servers. <{{ testuser }}@{{ ansible_fqdn }}> ist also die E-Mail-Adresse des Testusers.