X.509 ist schon ein komischer Fetisch.
todo:
- Nachteile von LE (z.B. EV)
- warum ist die Implementierung mit LE statt custom-Certs so einfach?
- IDN: geht bei U5/6 immer noch nicht.
- kurz erklären, was der Paternoster tut oder ganz weglassen
- evtl. Bullshit-Bingo X509/ASN1/… reduzieren
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.
Auch wir haben so unsere ganz eigene Beziehung mit OpenSSL. Sei es nun bei der Organisation unserer internen Client-Zertifikate oder auch bei für euch sichtbaren Features wie dem uberspace-add-certificate-Script, das über Jahre entwickelt und immer wieder verbessert wurde. In der Testphase vor vielen Jahren gab es dort sogar mehrere Sicherheitslücken, wie sie bei anderen Features nicht aufgetreten sind. Das Handling solcher Zertifikate ist also eine heikle Geschichte. Jetzt - Rahmen von Uberspace 7 - ist dieses Thema intern wieder aufgeflammt.
Wie in einem anderen Blogpost beschrieben, möchten wir uns aus verschiedensten Gründen auf lange Sicht von Shellscripts verabschieden und stattdessen auf Ansible-Playbooks setzen, um Scripte wie uberspace-add-domain abzubilden. Meistens ist das - dank dem Paternoster - in der Entwicklung keine große Herausforderung und führt auch in fast allen Fällen zu einer Verringerung der Code-Komplexität unserer Tools.
Bei uberspace-add-certificate stellt uns dieser Umstieg allerdings vor ein kleines Problem. Da der Paternoster die Validierung der Usereingaben vollständig übernimmt, müssen dort, wenn wir dem Schema treu bleiben, auch die übergebenen Zertifikate und Keys für HTTPS eingelesen und validiert werden. Hierzu brauchen wir eine Python-Library, die mit X.509 bzw. ASN.1-Strukturen umgehen kann. Die gibt es auch; gleich mehr als fünf davon! Das Problem: zu keiner einzigen davon gibt es einen Security-Audit. Zusätzlich werden die Meisten schon lange nicht mehr gewartet, sodass sie gleich aus der Liste der Kandidaten fliegen. Schließt man also die offensichtlichen Blindgänger aus, bleiben nur noch zwei: pyOpenSSL und Cryptography. Beide werden im Moment vom selben Team, der Python Cryptographic Authority, gewartet, welches auch gleich von pyOpenSSL abrät. Bleibt also nur noch eine. Damit ist die Auswahl eher mager und die Implementierung eines neuen uberspace-add-certificate komplizierter als gedacht.
Das Internet und natürlich auch wir bewegen sich immer weiter und immer schneller in Richtung auf Let’s Encrypt zu.
Als optionales Feature ist das Projekt schon seit Beginn der öffentlichen Beta-Phase im Dezember 2015 bei uns verfügbar. Bisher ist es aber weiterhin möglich mit uberspace-add-certificate Zertifikate beliebiger CAs bei uns einzubinden.
Bei Uberspace 7 denken wir derzeit darüber nach Let’s Encrypt, zumindest am Anfang, zur einzigen Möglichkeit zu machen, um bei uns an ein TLS-Zertifikat zu kommen. Es wäre damit nicht mehr möglich, sich bei einer externen CA ein Zertifikat zu kaufen, um dieses bei uns einzurichten. Dafür wäre die Integration allerdings vollautomatisch, sodass jede aufgeschaltene Domain sofort und ohne weitere händische Schritte ein Zertifikat bekommt. Viele anfängliche Nachteile von Let’s Encrypt, wie z.B., dass es dort normalerweise keine Wildcard-Zertifikate gibt, fallen somit weit. Andere Bedenken, wie, dass Umlautdomains nicht dort möglich sind, hat das Projekt in der jungen Vergangenheit selbst aus dem Weg geräumt. Wir sehen also immer weniger Gründe, andere CAs weiterhin zuzulassen.
Abschließend ist unsere Frage also:
Einbinden von Zertifikaten externer Certificate Authorities.. braucht ihr das noch, oder kann das weg?