Security ist, wenn’s funktioniert.
Was mir in letzter Zeit immer wieder auf Webseiten mit irgendwelchen Installationsanleitungen für Debian oder Ubuntu auffällt:
Häufig geht es dabei um Software, die zwar als Debian-Package angeboten wird, aber nicht Teil der offiziellen Debian- oder Ubuntu-Repositories ist. Oft bieten andere Anbieter diese dann selbstcompiliert in Form eines normalen Debian-Package-Baums an, den man als zusätzliche Paketquelle in sein System einbinden kann. Dazu muss man einen PGP-Schlüssel installieren, mit dem man die siginierten Fremdverzeichnisse verifizieren kann. Und gar häufig steht da dann sowas wie
wget -O - http://packages.elasticsearch.org/GPG-KEY-elasticsearch | sudo apt-key add -
drin.
Da kann man sich dann die ganze PGP- und Verifiziergeschichte auch gleich komplett sparen. Denn wenn man die Public Keys selbst über einen komplett unsicheren Kanal und ohne jegliche Prüfung runterlädt, und gleich direkt in das eigene System durchpfeift, kann jeder, der auch nur so ein bisschen man-in-the-middle drauf hat, trivial den Schlüssel austauschen und damit dann die komplette Integritätsprüfung aushebeln.
Zeigt mal wieder das übliche Symptom: Es wird gar nicht mehr über Angreifer oder sowas nachgedacht. Security ist, wenn funktioniert, was man gerade machen will.
15 Kommentare (RSS-Feed)
Immerhin hat der Angreifer nur eine Chance beim erstmaligen Installieren der Software. Wenn da kein MITM-Angriff stattgefunden hat, dann kann bei späteren Updates (z.B. in irgendeinem öffentlichen WLAN) nichts passieren. Ist also am Ende doch wesentlich besser als völlig unsignierte Software-Downloads.
Tja, die Frage ist, ob das Einbinden von Packetquellen per betriebssystemeigenem Installations-Tool (wie z.B. YAST bei OpenSuSE) sicherer ist.
Man bekommt da ein Kästchen, Trust? oder eben Not, keine Ahnung ob dieser Kanal man-in_the_middle-sicher ist.
Das Problem ist der menschliche Faktor.
Macht man es sicher gibt es jede Menge Leute die es (aus welchen Gründen auch immer) nicht gebacken kriegen und rumheulen, was der ganze Mist denn solle. Dabei sitzt der Fehler in den allermeisten Fällen direkt vor der Tastatur.
Die Frage ist:
Wie würde denn Deiner Ansicht nach ein benutzerfreundlicher aber auch sicherer Weg aussehen?
> Wie würde denn Deiner Ansicht nach ein benutzerfreundlicher aber auch sicherer Weg aussehen?
Eine ganz einfache und trotzdem deutliche Verbesserung wäre, beim selben Befehl einfach https statt http zu verwenden. Machen auch manche. Aber viele eben nicht.
@Hadmut Experimentierst du mit elasticsearch oder hast sogar Erfahrung damit?
> @Hadmut Experimentierst du mit elasticsearch oder hast sogar Erfahrung damit?
Nein, noch nicht. Ich brauche zwar für die Neukonstruktion des Blogs noch eine Suchmaschine, aber ich habe noch nicht damit rumprobiert und würde auch erst mal die Suchfunktionen von postgresql näher austesten.
Bin zufällig drüber gestolpert, als ich eine Webseite besichtigt haben (s.o.), und es ist mir aufgefallen, weil ich das in den letzten Wochen mehrfach auf verschiedenen Webseiten gesehen habe.
@Hadmut:
“Eine ganz einfache und trotzdem deutliche Verbesserung wäre, beim selben Befehl einfach https statt http zu verwenden. Machen auch manche. Aber viele eben nicht.”
Du hast mich jetzt doch neugierig gemacht und ich habe mir gerade mal das Beispiel angesehen. Was mich interessieren würde, wo hast Du die Zeile her? Denn zumindest auf der Seite von elastic.co wird in der selben Befehlszeile HTTPS genutzt.
Seltsam ist dann nur, daß zwar auf Haupt- und Produktseite HTTPS genutzt wird, dies aber nicht durchgehend passiert. Ausgerechnet auf der Seite die den Fingerprint des Signing Keys enthält wird normales HTTP genutzt. Noch befremdlicher ist dann allerdings, daß nicht einmal die Seite “pgp.mit.edu” auf der man den Key überprüfen kann durchgehend per HTTPS angebunden ist. Man kann zwar auf die sichere Version wechseln, aber das muß man explizit machen. Auch die Repositories selbst sind nur per normalem HTTPS angebunden. Warum aber diese Inkonsistenz?
Im Prinzip muß man also sagen, daß man Sicherheit (so weit man davon sprechen kann) nur hat wenn man ganz paranoid alles selbst überprüft und bei jedem Schritt doppelt hinguckt. Nur kann man das von dem durchschnittlichen User nicht erwarten.
Wobei das Kapitel Sicherheit auch in normalen mittelständischen Unternehmen nicht wirklich angegangen wird. Bei meinem letzten Arbeitgeber hatte beispielsweise jeder Mitarbeiter auf “seinem” Rechner Adminzugriff. Für den Adminzugang der Domäne gab es zwar ein separates Passwort, aber zumindest den ersten Schritt auf den Rechner hatte man eventueller Malware so leicht wie möglich gemacht. Die Mitarbeiter nutzten dann auch den Zugriff nach Herzenslust um sich alle möglichen und unmöglichen Programme zu installieren. Als ich dann mal wagte bezüglich dieser Praxis Bedenken anzumelden wurde ich von dem Consultant der die Administration bis dahin machte (und meines Wissens heute auch wieder macht) nur abgewürgt, daß wäre so doch viel benutzerfreundlicher und eine Änderung die völlig unnötig sei würde ohnehin nur den Betriebsfrieden stören. Von daher wundert mich in dem Zusammenhang prinzipiell nichts mehr.
> Was mich interessieren würde, wo hast Du die Zeile her?
Es ging um ein Tutorial bei Digital Ocean:
Jemand hatte mich nach meiner Meinung über Digital Ocean gefragt und ich habe mir deren Webseite mal angesehen, dabei auch mal ein paar dieser Tutorials.
Mir ist gerade aufgefallen, daß mir oben ein Fehler passiert ist.
Der Satz: “Auch die Repositories selbst sind nur per normalem HTTPS angebunden. Warum aber diese Inkonsistenz?”
Müsste eigentlich lauten: “Auch die Repositories in denen die Pakete enthalten sind, sind nur per normalem HTTP angebunden. Warum aber diese Inkonsistenz?”
> “Auch die Repositories in denen die Pakete enthalten sind, sind nur per normalem HTTP angebunden. Warum aber diese Inkonsistenz?”
Das macht aber nichts, weil die Pakete und die Listen ja über Signaturen abgesichert sind. Die brauchen keine Transportsicherung.
Ich denke, daß ist den heutigen Point-and-Click-Admins geschuldet. Die köntne natürlich auch auch copy&paste-Admins genant werden, was ja dank moderner GUIs ja im wesentlichen inzwischen das gleiche wie Point and Click ist.
Diese wissen nicht mehr, was das Ganze macht, was sie da anklicken und jede Komplexitätssufe mehr die Gefahr des scheiterns birgt.
Jetzt stell dir mal vor der arme Admin müßte ers das SSl-zertifiakt des Servers prüfen. Dann den pgp key. und dann die erst könnte er loslegen. Das würde er vielelicht tage damit verbringen.
PS: Ich habe mal versucht bei (Online-)Banken versucht SSL-keys zu verifizieren. Es hat Tage gedauert, bis ich mal einen erwischt habe, der sich auskennt und mir nicht einfach den Fingerprint des keys vorgelesen hat, den er per Internetbrowser selbst von der Banking-seite abgelesen hat. 🙁
Https wird wie genau abgesichert? Wem vertraue ich da?
> Https wird wie genau abgesichert? Wem vertraue ich da?
SSL bzw. TLS. Man vertraut einer Liste von über 200 CAs fragwürdigster Herkunft und Gesinnung.
> Man vertraut einer Liste von über 200 CAs fragwürdigster Herkunft und Gesinnung.
Oder wirft den Großteil davon raus (oder gar alle) und überprüft dann die Zertifikate des gegenüber “händisch”, was aber gar nicht so einfach ist, wenn man keine kompetenten Leute gegenüber findet.
Das führt dann allerdings dazu, daß man zusätzlich eine Unmenge Zusatzaufwand aufbürdet.
Das steht ganz in der Tradition von Debian. Signierte Installationspakete haben die überhaupt erst im letzten Jahrzehnt eingeführt. Die üben noch. 😉