Ich habe es mir angeschaut (auch damals), aber nicht ausprobiert (keine Zeit). Das Script scheint einen individuellen Webserver mit einem individuellen Zertifikat zu starten. Nachteil ist vielleicht, dass man über einen sicheren Weg den Befehl zum Download auf das zweite System bringen muss.reox hat geschrieben:Hat sich das mal wer angeschaut?^^ Nach so viele Tipps ist es ziemlich ruhig geworden
Ich kann aber immer noch nicht so recht glauben, dass es genau sowas nicht schon vorher gegeben hätte...
Für dich @reox scheint es einen Anwendungsfall zu lösen. Sinnvoll vor allen bei Systemen mit genau einer Person (s.u.) und wenn der Service nur selten benötigt wird.
Warum wird es von anderen nicht verwendet oder benötigt:
- Anwender verfügt sowieso über einen SSL-Webserver
- Anwender nutzt SSH anstatt HTTPS
- Anwender nutzt eine lokale Verschlüsselung (z. B. 7-Zip) und einen beliebig unsicheren Transportweg.
Nachteile deiner Lösung:
- Verwendung von Kommandozeile (Client und Server), ist aber auch ein Vorteil
- Server muss gestartet werden und auf Client warten
- Befehl für den Zugriff muss sicher ausgetauscht werden (vergleichbar mit Passwort einer 7-Zip-Datei)
- es ist "nur" eine TLS-Transportverschlüsselung und keine Ende-zu-Ende-Verschlüsselung
Vorteile:
- SSL-Zertifikat für jede Verwendung
- Server nur verfügbar wenn benötigt
- sehr minimal, kein großer Webserver usw. wird benötigt
- geringe Fehlerwahrscheinlichkeit aufgrund weniger Codezeilen
Die Lösung ist von der Idee an sich genial. Da du aber sowieso auf einen sicheren Weg den Befehl austauschen musst, könntest du anstatt nur einer TLS-Transportverschlüsselung z. B. durch Befehle wie aespipe oder p7zip eine Ende-zu-Ende-Verschlüsselung erreichen. Dieses hätte den Vorteil, dass unabhängig vom Transportweg die Daten sicher verschlüsselt sind. Vor allen auf Mehrbenutzersystemen wäre das sinnvoll und ein Sicherheitsgewinn, da der Administrator keinen Zugriff auf die Daten hätte.