added package cacerts. It will download ca-bundel from curl.haxx.se a… #218
Conversation
…nd place in /etc/ssl/certs/cacert.pem. further it's recommended to add location in .profile: export SSL_CERT_FILE=/etc/ssl/certs/cacert.pem
|
|
|
Was ist mit 3e12798? Oder reicht ? |
|
Zum Setzen von SSL_CERT_FILE empfiehlt sich die Datei |
|
Nachdem ich den initialen branch mit etlichen unsinnigen commits drucheinander gebracht hatte, habe ich die Änderung am curl package in einem seperaten branch eingepflegt. Aber ich kann das noch in diesen branche mergen. |
|
Als Nachtrag ... curl nutzt natürlich auch openssl libs und liest SSL_CERT_FILE ein. Der Eintrag "with-ca-bundle=..." hat aber Vorrang. Insofern könnte man tatsächlich die curl.mk Änderung auch weglassen. |
…rts/cacert.pem' as per suggestion of er13 - update curl.mk to configure with-ca-bundle="/etc/ssl/certs/cacert.pem" - corrected cacerts.mk "$(pkg)-uninstall"
|
Ich habe |
Sofern man sich fürs Anpassen von Ich fände es jedoch besser, wenn man |
|
Ich hatte gestern noch etwas rum probiert und mir fiel auf dass
|
Hmm, aktuell gibt es keinen ready-to-use Mechanismus, der das globale Setzen einer Umgebungsvariable ermöglichen würde. Ein denkbarer Weg wäre das Erweitern von Könntest Du bitte aufzählen, für welche rc-Scripts das Deiner Ansicht nach benötigt wird? U.U. wäre das Einlesen aus diesen heraus oder aus |
|
Es ging um ein Paket wofür ich noch keinen PR erstellt habe: adaway. Ich habe mich aber jetzt dafür entschieden |
|
@PeterPawn: könntest Du mir bitte sagen, wofür Du die Option Hättest Du etwas dagegen bzw. würde es mit Deinen Use-Cases kollidieren, wenn ich diesen Pfad hart auf |
1. This way curl works the same way regardless of the environment it is started from. 2. SSL_CERT_FILE is also evaluated by AVM's version of libcrypto, setting it globally is a potential source of problems with AVM binaries. OpenSSL related changes are pending. Refs #218
|
Ja, würde kollidieren. Ich habe diese Option deshalb hinzugefügt, weil in eigenen ("custom") Images der Pfad zur Konfigurationsdatei eben noch den Mountpoint dieses alternativen Images VOR dem Beispiele für solche Images findet man im IPPF, mit dieser Option (unter Verwendung von "/var/custom" als Mountpoint) übersetzte Binaries findet man in meinem Repository mit den signierten Dateien. Aber ich kann die Option auch in meinen Fork selbst weiterführen ... nur halte ich die Verwendung eines fest kodierten Wenn man so etwas machen möchte (wie Du selbst festgestellt hast, kann man natürlich auch die Pfade jeweils selbst setzen, wobei das mit der Denn unter diesem Pfad sucht eben OpenSSL (bzw. alles, was die Libs ohne zusätzliche Angaben verwendet) nicht nur die vertrauenswürdigen Root-CA (die sich sicherlich seltener ändern), sondern auch deutlich volatilere Daten, wie CRLs. Und OpenSSL wird eben i.d.R. nicht nur von Zwar sollte jede CA, die mit CRLs anstelle von OCSP arbeitet, auch entsprechende Verteilerpunkte in den erweiterten X509-Attributen eines (CA-)Zertifikats bereitstellen, aber oft sind solche Dienste auch nicht erreichbar (vermutlich hat jeder schon mal erlebt, daß sein Browser eine Verbindung nicht aufbauen wollte, weil er keine Informationen beziehen konnte, ob das vorgelegte Zertifikat zurückgezogen wurde oder nicht) und auch die Prämisse, daß man bei Verwendung des (Mozilla-)Bundles ALLEN CAs in diesem Bundle vertrauen soll, würde vermutlich nicht jeder teilen. Ich kenne genug Leute, die auch schon vor den von Mozilla gezogenen Konsequenzen (https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/) die Symantec-Roots aus ihren Geräten verbannt hatten. Ich denke nicht, daß das SquashFS-Image (als "read-only"-Medium, außer man baut ein neues Images bei jeder Änderung) der richtige Ort für die Ablage solcher Daten ist. Ich mache mal einen (zugegebenermaßen etwas aufwändigeren, vielleicht für Freetz sogar zu aufwändigen) Vorschlag ... OpenSSL muß in dem hier diskutierten Kontext ja ohnehin im Image enthalten sein. Mit Damit hätte man also eine dynamische Quelle für die Zertifikate, denen man tatsächlich vertrauen möchte (die anderen werden halt rausgeworfen, ich brauche jedenfalls nicht mal 1/10 der im Bundle enthaltenen CAs) und auch nach Änderungen an diesen Dateien (ich meine mich zu erinnern, etwas von Update-Absichten für diese Zertifikate in den vorhergehenden PR-Versuchen gelesen zu haben) hat man die Möglichkeit, diese Liste wieder so zu signieren, daß man ihrem Inhalt einigermaßen vertrauen kann. Die Form mit der einzelnen PEM-Datei, die alle "trusted root CAs" enthält, ist - wenn ich mich richtig erinnere - ohnehin nicht die schnellste ... meines Wissens wird eine auf diesem Weg angegebene Datei beim Daher ist diese Form der Root-Zertifikate in einer einzigen Datei, wie sie |
|
Ohje, ich hoffe ja mit diesem Paket nicht mehr Aufwand als Nutzen erstellt zu haben. Eure Argumente machen durchaus Sinn. Meine Intension war es erstmal nur ein CA bundle im image bereitzustellen um https downloads mit curl oder wget "etwas" sicherer zu machen. Zumindest wollte ich nicht den server-cert check wie bisher abschalten.
|
|
Laß Dich nicht ins Bockshorn jagen, das von mir beschriebene Vorgehen klingt schlimmer, als es wirklich ist. Die für mich entscheidende (Design-)Frage wäre es halt, ob man derartige "veränderliche" Daten tatsächlich ins Basissystem integriert oder doch - so wie es Freetz bisher auch hielt, denn da lag es ja unter Ich würde halt hingehen (daß ich mich zuvor nicht geäußert habe, hatte auch damit zu tun, daß ich das erste Erfolgserlebnis nicht verkomplizieren wollte - jetzt stellt sich halt die Frage, wohin sich das Ganze entwickeln soll) und in den Start des Systems (bzw. genauer in die Auswertung von "onlinechanged" - ohne "online" braucht man i.d.R. auch keine Zertifikate (fremder Systeme) zu validieren) eine Prüfung einbauen, ob es ein lokales "Archiv" von "trusted root CAs" gibt. Ist es vorhanden, packt man es erst mal aus (das ist - wie gesagt - im besten Falle ein Das Zerlegen an den "Schnittmarken" einer PEM-Datei ist easy und auch das "Hashen" ist i.d.R. kein Problem - ich weiß allerdings gerade nicht, ob das "rehash" als OpenSSL-Operation erst in der 1.1.x in das Binary Einzug gehalten hat. Aber auch wenn das so ist, sollte mit der 1.0.x noch ein mutiges den Hash für den Dateinamen liefern. Einzig die Logik, da den richtigen Index anzuhängen, wenn es mehr als ein Zertifikat mit dem Hash gibt, ist vielleicht etwas aufwändiger ... kann man auch erst später implementieren, wenn es tatsächlich notwendig sein sollte. Jedenfalls ist das "Zerlegen" wirklich so einfach ... und diese Art der Speicherung hat natürlich eindeutige Vorteile (ggü. dem "single file with all certs"), auch wenn es um "Selektion" von CAs geht (falls man tatsächlich mal ein GUI dafür bauen wollte) oder wenn man gar das Zertifikat seiner eigenen Root-CA hinzufügen will (das natürlich in einer Das dann am Ende wieder zu einem lokalen Image zusammenzupacken, was man signieren kann, ist auch nicht wirklich "schlimm" ... man muß halt eine bestimmte Verzeichnisstruktur einhalten und eine Datei Am Ende ist das mit dem fehlenden Vertrauen in das komplette Bundle (ich brauche nur selten die "China Financial Certification Authority" als Root - wobei deren CA-Zertifikat wenigstens schon SHA-256 als Hash verwendet, viele sind immer noch mit SHA-1 signiert in dem Bundle) und der Notwendigkeit, eine eigene Root-CA hinzuzufügen, aber sicherlich schon "etwas spezieller" ... aber ich prüfe eben auch lieber "von Hand" ein Zertifikat und pinne dann dessen "public key", wenn ich von einem fremden Server per TLS Dateien lade, denen ich hinterher ein "besonderes Vertrauen" aussprechen muß: https://github.com/PeterPawn/YourFritz/blob/signimage_database/signimage/database/download_firmware_files#L89 Also laß Dich von mir nicht verunsichern ... zumal man das auch nicht alles "auf einen Schlag" auf die Beine stellen muß. Man kann das auch Stück für Stück implementieren und zusammensetzen ... sogar dann, wenn man dafür irgendwelche vorhergehenden "Provisorien" wieder abräumen muß. PS: Hier gibt's auch das Zerlegen eines solchen Files aus mehreren Zertifikaten (in "Shell") als Beispiel zum Nachlesen ... ich hatte in Erinnerung, so etwas gezeigt zu haben: https://github.com/PeterPawn/YourFritz/blob/signimage_database/tools/showcertchain - man muß halt an der Stelle mit "openssl x509" etwas anders verfahren. PPS: Um noch ein Argument für die getrennte Datenhaltung hinterherzuschieben ... integriert man es nicht in das Image, können mehrere Images eine einmal erstellte "eigene Zusammenstellung" verwenden (ggf. sogar mehrere Boxen, wobei jede ihr lokales Image selbst signieren sollte, es also etwas wie einen "Import" geben müßte, wenn man das über mehrere Boxen verwenden will) - ansonsten müßte man bei jedem neuen (Freetz-)Image auch wieder "tätig werden", wenn man "Abweichungen" zum "normalen CA-Bundle" (sei es durch Hinzufügen oder Entfernen) hat. |
|
Habe jetzt noch nicht alles gelesen, geschweige denn verstanden. Kleine Anmerkung zum Thema "einzelne Zertifikate mit hash-Symlinks" vs. "alles in einer Datei". Möchte man die aus Performance-Sicht bessere Variante "einzelne Zertifikate mit hash-Symlinks" umsetzen, so könnte man sich an dem BuildRoot-Paket orientieren. |
|
Also ich bin wirklich froh über den regen Austausch und je öfter ich die Beitrage lese, desto mehr verstehe ich alles :) Also folgendes habe ich mir mal für cacerts notiert (bitte korrigiert mich falls ich was falsch verstanden habe):
Geht das in die richtige Richtung? |
|
Das mit den Symlinks innerhalb der Freetz-Konfiguration wäre sicherlich machbar und ist auch in meinen Augen eine gute Idee (auch zum Beschränken des Vertrauens), die mit dem Platz sparsam umgeht. Die Tatsache, daß die 0.98.x-Version ein anderes Hash-Verfahren benutzte, würde ich ignorieren und einfach das ganze Package nur für OpenSSL >= 1.0.x weiterentwickeln. Die alte Version wird früher oder später noch an ganz anderen Problemen scheitern (und das betrifft ja auch nur die älteren FRITZ!Box-Modelle, die haben dann noch ganz andere Sicherheitsprobleme in der als Vorlage verwendeten AVM-Firmware) ... bis hin zu einem Inhalt neuerer Zertifikate, den sie per Definition nicht versteht, weil neuere Erweiterungen o.ä. zum Einsatz kommen. |
It will download ca-bundle from curl.haxx.se and make it available on the box under /etc/ssl/certs/cacert.pem
…nd place in /etc/ssl/certs/cacert.pem.
further it's recommended to add location in .profile:
export SSL_CERT_FILE=/etc/ssl/certs/cacert.pem