Upgrade unseres HTTPS-Frontends

tl;dr

Wir haben unser HTTPS-Frontend Pound von Version 2.6 auf 2.7 aktualisiert um zeitgemäße Diffie-Hellman-Parameter von 4096 Bit Größe zu unterstützen.

Wenn du Probleme feststellst, die womöglich durch dieses Upgrade entstanden sind, wende dich einfach mit möglichst vielen Details an hallo@uberspace.de! :)

Hinweis: Das Upgrade geschieht in inkrementellen Schritten. Wenn dein Uberspace-Host mit CentOS 6 also nicht sofort als 4096 Bit DH-Parameter unterstützend beim SSL-Test der SSL Labs erkannt wird, dann folgt das Upgrade auf Pound 2.7 auf diesem Host im Laufe der nächsten 24 Stunden. (siehe Update #2)

Uberspace-Hosts mit CentOS 5 werden von uns erst im Laufe der nächsten Tage aktualisiert.

Update #1: uberspace.de haben wir ebenfalls das neue HTTPS-Frontend verpasst!

Update #2: Sämtliche Uberspace-Hosts mit CentOS 6 sind nun aktualisiert worden.

Was ist ein HTTPS-Frontend?

Im Optimalfall verhält sich unser HTTPS-Frontend Pound sehr unauffällig. Wenn ihr eure Inhalte per HTTP oder HTTPS von eurem Uberspace über die Standard-Ports 80/443 abruft, dann passieren diese zuerst Pound und werden erst dann transparent an den Apache-Webserver durchgereicht.

Der Hintergrund davon ist folgender: Apache beherrschte zu Zeiten, als Uberspace-Hosts noch auf CentOS 5 basierten kein SNI. Seit CentOS 6 hat Apache 2.2 zwar über mod_ssl ebenfalls die SNI-Funktionalität erhalten, unsere bereits bestehende TLS-Frontend-Isolierung gefiel uns aber so gut, dass wir sie bei der Umstellung auf CentOS 6 beibehalten haben. (Teaser: Für CentOS 7 behalten wir sie ebenfalls bei!)

SNI steht für Server Name Indication und bedeutet, dass über eine IPv4-Adresse abhängig von der angefragten (Sub-)Domain eine verschlüsselte TLS-Verbindung aufgebaut werden kann.

Das ist nötig, da ansonsten für jedes TLS-Zertifikat eine IPv4-Adresse benötigt wird, was angesichts der IPv4-Apokalypse schlicht nicht mehr praktikabel ist, wir hätten unseren Usern dann also keine Nutzung eigener Zertifikate anbieten können.

SNI in Kürze

Wenn der Ubernaut phantomias nun also seine neu entwickelte Webseite über https://phantomias.ducklair.uberspace.de testen möchte und sie in seinem Browser aufruft, so erkennt unser HTTPS-Frontend beim ersten HTTP-Request

  • dass der Client bei der TLS-Aushandlung die Domain übermittelt
  • dass es sich bei der Anfrage um eine Subdomain handelt
  • dass es zu der Anfrage ein Zertifikat existiert, in diesem Fall also unseres für *.ducklair.uberspace.de

so dass eine verschlüsselte Verbindung aufgebaut werden kann.

Das Upgrade

Pound ist ein essenzieller Bestandteil von Uberspace. Wir haben bisher viel Erfahrung mit Pound gesammelt und sind im großen und ganzen auch sehr zufrieden damit. Es gab bisher allerdings eine Schwäche, die uns davon abgehalten hat, als zukunftssicher geltende DH-Parameter von 4096 Bit Größe zu verwenden, die TLS verwendet, um die eigentliche Verschlüsselung auszuhandeln. Erst durch das Upgrade auf Version 2.7 ermöglicht Pound es uns, die kryptografische Stärke dieser Parameter auf ein ausreichend hohes Niveau zu heben.

Hinweis zu Logjam

Von der Logjam-Attacke waren unsere Hosts im übrigen nicht betroffen, da wir gar keine schwachen DHE_EXPORT-Parameter von weniger als 512 Bit Größe angeboten haben. Im Kontext dieser Attacke wurde allerdings die Stärke von DH-Parametern zum Thema. So heißt es, dass vermutet wird, dass Nationalstaaten dazu in der Lage sein dürften, bis zu 1024 Bit starke asymmetrische Verschlüsselung zu brechen. Das ist für uns Grund genug, alle Register zu ziehen und Pound 2.7 auszurollen.

Upgrade unseres HTTPS-Frontends
Share this