thtomate12 schrieb:
Ja, ich meinte das ACME-Protokoll
Ich hatte auch aus Versehen den alten Draft verlinkt, der korrekte (aktuelle) ist unter
https://tools.ietf.org/html/draft-ietf-acme-acme-01 zu finden.
daher wird es wohl auch welche in C geben.
Meines Wissens gibt es bisher die ISRG-Implementierung in Python, eine in
Ruby on Rails und einen recht kompletten
C#-Client - neben der JS-Implementierung, die eigentlich auch nichts weiter als ein "endlicher Automat" ist, der die einzelnen auszuführenden Schritte dem Benutzer anzeigt und die eigentliche Arbeit trotzdem ihm überläßt. Die JS-Implementierung und auch die C#-Version greifen obendrein noch auf OpenSSL als Kommandozeilenversion zurück, um einige kryptographische Operationen auszuführen, die Python-Version auf pyOpenSSL als Module und damit m.W. auf die OpenSSL-Libraries - bei der Ruby-Version habe ich keine Ahnung, was die noch an "Rahmenbedingungen" braucht.
Aber am Ende ist die JS-Version (die kannte ich tatsächlich auch schon seit Mitte November und der
Ankündigung der "public beta" durch "Let's Encrypt" und nicht erst seitdem ein in IT-Kreisen bekannter Blogger dahin verlinkte und dann heise.de darüber
berichtete) eben nichts anderes als das "manual"-Plugin der Python-Version, es ist nur die "Ablaufsteuerung" für den Benutzer ... die dann bei ihm wirklich kein Python verlangt, aber immer noch die Möglichkeit, statische Inhalte auf dem Webserver "auf Kommando" bereitzustellen unter einem Pfad - ".well-known/acme-challenge" - auf den ein normaler User keinen Zugriff haben sollte - damit nicht eine beliebige "Webpräsenz" auf einem "shared server" (nach dem Schema "www.server.tld/usercontent") sich ein Zertifikat für den gesamten Server beschaffen kann.
Der eigentliche Vorteil der automatisierten Abläufe ist es ja, daß der Benutzer eben nicht irgendwelche komplizierten Kommandos in ein Terminal kopieren oder aus einer Anleitung abtippen muß. Wenn man den Aufwand bei der manuellen Vorgehensweise mit ACME-Protokoll mit dem Aufwand bei anderen Methoden (z.B. StartSSL mit E-Mail-Verifikation über eine administrative E-Mail-Adresse) vergleicht, schneidet nach meiner Meinung das ACME-Protokoll sogar schlechter ab ... es kann eben seinen entscheidenden Vorteil - die Automatisierung - nicht ausspielen.
Man kann also sicherlich mit ein wenig Aufwand auch "manuell" ein "let's encrypt"-Zertifikat für eine FRITZ!Box generieren (indem man für die Dauer der Verifikation die eingehenden Ports für HTTP/HTTPS auf einen anderen Server forwarded (z.B. die "standalone"-Version des letsencrypt-Clients) oder die Inhalte tatsächlich in die FRITZ!Box bringt, was aber gar nicht so einfach ist angesichts des benötigten Pfades für einen solchen Request und ohne Shell-Zugriff ohnehin nichts wird) ... aber der Aufwand dafür steht angesichts der Gültigkeitsdauer erst einmal in keinem Verhältnis zum Nutzen. Da ist dann tatsächlich ein (lokal generierter, alles andere ist Quatsch) CSR für StartSSL fast einfacher zu erledigen mit der richtigen Anleitung, wobei der m.W. wieder keine SANs-Entities erlaubt.
Wenn das mit "Let's Encrypt" dem Beta-Stadium entwachsen ist, kann man sich sicherlich auch Gedanken darüber machen, wie man so etwas in die FRITZ!Box bekommt ... und zwar so, daß es automatisch funktioniert. Das setzt dann aber eine "konzertierte Aktion" verschiedener Komponenten voraus, z.B. muß dann eben zum Zeitpunkt der Validierung jede im Zertifikat angegebene DynDNS-Adresse auch tatsächlich aktuell sein, damit so ein Request funktionieren kann.
Einen reinen C-Client sehe ich jedenfalls im Moment noch nicht als OpenSource-Software irgendwo im Internet ... ich habe bisher nichts gefunden. Das ist ähnlich wie bei einer WebDAV-Server-Implementierung in "purem" C oder meinetwegen noch C++ ... alles was es jenseits des Apache-Moduls gibt, ist in irgendeiner (Interpreter-)Hochsprache geschrieben, die zusätzlichen Aufwand auf der Box verlangt.
Am Ende sollte so etwas für den Benutzer eben so einfach sein, daß er nur noch einen Haken setzt bei "Let's Encrypt-Zertifikat verwenden" und die FRITZ!Box dann anhand der konfigurierten DynDNS-Namen ein Zertifikat automatisch erstellen läßt.
Aber da lauert dann auch schon die nächste Falle ... wenn man so ein externes Zertifikat verwendet, kann man den internen Zugriff über HTTPS praktisch vergessen. In den self-signed-Zertifikaten der FRITZ!Boxen sind eben nicht nur die externen Namen enthalten, sondern auch noch weitere "subject alternative names":
Code:
DNS Name=<primary DynDNS name>
DNS Name=<myfritz name>
DNS Name=fritz.box
DNS Name=www.fritz.box
DNS Name=myfritz.box
DNS Name=www.myfritz.box
DNS Name=<FRITZ!Box name>
DNS Name=fritz.nas
DNS Name=www.fritz.nas
Außer den ersten beiden Einträgen wird man wohl keinen der aufgeführten Namen von einer externen CA "genehmigt" bekommen. Wenn man also intern auch HTTPS verwenden will und dabei nicht über den externen DynDNS-Namen (oder den MyFRITZ!-Namen) zugreifen will, ist so ein "richtiges Zertifikat" auch nicht das Gelbe vom Ei.
Unter diesem Aspekt ist dann wieder ein ordentliches "self-signed"-Zertifikat (ggf. von der eigenen CA und nicht von der Box selbst ausgestellt, wenn man mehrere Boxen verwaltet und anstatt der ganzen Box-Zertifikate dann nur das eigene CA-Zertifikat "pinnen" muß) sogar die bessere Wahl ... einen Tod muß man eben sterben.
Meine (sehr persönliche) Einschätzung: Unter Umständen ist "Let's Encrypt" auch in einer FRITZ!Box eine gute Idee, allerdings wäre es dann vermutlich sogar schlauer von AVM, zwei unterschiedliche Zertifikate (ein "offizielles" für extern und ein "self-signed" für intern) zu verwenden und per SNI das richtige auszuwählen. Aber auch die SNI-Unterstützung ist m.W. noch nicht vorhanden, müßte also - neben dem Automatismus für ACME - ebenfalls noch implementiert werden.
Sehe ich in nächster Zukunft eher verschwommen, aber lassen wir uns überraschen ... vielleicht kriegt es AVM im Zuge einer solchen Änderung ja auch hin, den externen DynDNS-Namen und den MyFRITZ!-Namen bei internen Abfragen auf die LAN-Adresse der FRITZ!Box aufzulösen. Das hat zwar auch Nachteile (beim NAT-Hairpinning für "forwarded ports" auf LAN-Clients), aber auch verschiedene Vorteile bei Redirections vom HTTP- auf den HTTPS-Port - dann löst eben "fritz.box" immer noch auf die interne IP-Adresse beim HTTP-Zugriff auf und dort gibt es zwar ein Redirect auf den "offiziellen" DynDNS-Namen, aber der löst ebenfalls auf die interne Adresse auf ... zumindest solange gar keine externe Verbindung besteht, das wäre nämlich dann der Punkt, wo so ein TLS-Zugriff auf den externen Namen nicht mehr funktionieren würde, weil gar kein "NAT hairpinning" stattfinden kann, solange erstens das externe Interface keine Adresse hat und zweitens diese Adresse nicht im DynDNS aktualisiert wurde, so daß DNS-Abfragen auch auf die aktuelle externe IP-Adresse auflösen.
Das "keine Verbindung"- oder "DynDNS nicht aktuell"-Problem ist ja ein weiterer Pferdefuß bei der internen Verwendung der offiziellen DynDNS-Namen zum Zugriff auf die Box selbst (und natürlich auch auf jeden Client mit "forwarded ports"). Während man das bei einem beliebigen LAN-Client aber noch verschmerzen mag, wird es bei der Konfiguration der FRITZ!Box dann schon wieder kritisch, wenn die als Antwort beim HTTP-Zugriff unabhängig von ihrem aktuellen Zustand immer auf TLS unter dem externen DynDNS-Namen verweist und dieser Zugriff aber gar nicht funktionieren kann, weil schon der externe Name mangels externem DNS-Server (mangels Internetverbindung) nicht aufgelöst werden kann. Das ist zwar sicherlich nicht der "Normalfall", aber auch den muß man eben berücksichtigen, wenn man so etwas plant - da bietet sich dann eben wieder die Verwendung eines "internen" Zertifikats für die IP-Adresse und ein Redirect auf diese Adresse an, solange keine Internet-Verbindung besteht oder man läßt dann den HTTPS-Zugriff gleich weg, was wieder Auswirkungen auf die Sicherheit haben kann (session hijacking).
Wenn dann irgendwann auf Port 80 bei FRITZ!Boxen nur noch ein Redirector auf eine TLS-Verbindung antwortet und der Server mit HSTS modernen Browsern beim ersten Kontakt automatisch die künftige Verwendung von TLS nahelegt, dann klappt es auch mit dem automatischen internen HTTPS-Zugriff und ein Kriterium für vier "Pluspunkte" für sichere Router nach dem
BSI-Entwurf (Punkt 3.4.3, S. 22) ist damit erfüllt.
Allerdings sollte dann auch noch die (parallele, aber möglichst auch abschaltbare, falls man einen anderen Server dort laufen lassen will) Verwendung des Standard-HTTPS-Ports 443
aus dem internen Netz möglich sein ... bisher nimmt AVM wohl denselben Port wie für einen externen Zugriff, damit die Konfigurationen irgendwelcher FRITZ!Apps auch dann noch gültig sind, wenn sich die Geräte im LAN befinden und nicht über das Internet zugreifen (was natürlich denselben Beschränkungen unterliegt, wenn die Box gar nicht erst ins Internet kommt - ich kenne nicht genug von den Android-Apps um sagen zu können, ob dabei dann ein automatischer Fallback auf die per UPnP im LAN lokalisierte Box erfolgen würde, meine MyFRITZ!-App für iOS schaut dann recht dumm aus der Wäsche und braucht ein "internes Konto"). Allerdings sollte es ja kein Problem sein, da noch einen zusätzlichen Listener auf Port 443 aufzusetzen - es gibt ja ohnehin schon mehrere Sockets im "listen()"-Mode, da macht ein weiterer den Kohl nicht fett.
Aber so ein TLS-Zertifikat hat eben viele "Konsequenzen", die alle bedacht sein wollen ... das war zwar bisher bei der Verwendung eines "offiziellen" eigenen Zertifikats auch so, aber da wußte der Benutzer dann in aller Regel auch einiges über Zertifikate an sich und genau das soll ja bei ACME nicht mehr erforderlich sein - mit entsprechenden Auswirkungen an anderen Stellen (wie ich vielleicht zeigen konnte).
Ob man jetzt den internen HTTPS-Zugriff für notwendig hält oder nicht (immerhin bin ich ja offenbar nicht alleine dieser Meinung, wenn der BSI-Entwurf dafür auch vier Extra-Punkte vergibt), ist vielleicht Geschmackssache ... wenn aber eine "Let's Encrypt"-Unterstützung das auf alle Zeiten verhindern würde, würde ich für das Auslassen von ACME-Unterstützung plädieren. Einfach schon deshalb, weil ein "certificate pinning" ohnehin in modernen Browsern um sich greifen wird (eigentlich macht es der Mainstream ja schon, daß man solche "Sicherheitsausnahmen" permanent speichern kann) und auch auf Serverseite gibt es mit HPKP ja inzwischen eine Lösung für das Pinnen einer CA oder sogar eines Zertifikats - da kann man (zumindest ich) mit einer einmaligen Browser-Warnung bei einer (erwarteten) Änderung des Zertifikats besser leben als mit einem dauerhaft abhörbaren Zugriff auf das GUI der Box. Allerdings verwende ich ohnehin für die FRITZ!Boxen Zertifikate meiner eigenen CA, die dann auch die notwendigen internen Namen und sogar noch die IP-Adresse der FRITZ!Box als "subject alternative names" enthalten ... das vermeidet natürlich die angesprochenen Probleme mit "intern vs. extern" ebenfalls.