Autor: matthias

FTP ist ein schlechtes und unsicheres Prototoll aus vor-WWW-Zeiten. Wer es verwendet oder anbietet legt damit Zeugnis ab über seine Inkompetenz und Ignoranz.

FTP ist unsicher

FTP unterstützt keine Verschlüsselung. Die Daten werden unverschlüsselt über das Internet übertragen. Jeder kann sie mitlesen. Aber nicht nur die übertragenen Nutzdaten, sondern auch der Benutzername und das Kennwort werden unverschlüsselt übertragen.

Wenn man einen FTP-Zugang verwendet, dann kann man die Zugangsdaten genausogut veröffentlichen. Alles was man mit FTP macht können andere dann auch.

Trotzdem meinen manche (selbst Profis) es sei eine gute Idee zur Verwaltung eines Online-Shops FTP zu benutzen. Das ist lustig und gleichzeitig traurig, denn die Verbindung vom Server zu den Benutzern ist ja ordentlich verschlüsselt und die Kunden verlassen sich darauf.

FTP ist alt

Nur weil etwas alt ist bedeutet das nicht, dass es deshalb schlecht sein muss. Viele alte Autos sind z.B. toll; oder alte Gemälde. FTP ist aber nicht alt. Es ist saualt. Als FTP im Oktober 1985 spezifiziert wurde gab es noch gar kein World Wide Web. Und das ist auch nur die Basis der aktuellen Version. Eigentlich ist das Protokoll von 1972, als es noch gar kein Internet gab.

FTP wurde für das Arpanet, den Vorläufer des Internet, entwickelt. In der Google Bildersuche kann man sehen wie Computer 1972 aussahen. Für diese Computer, und Leute, die an Schwarz-Weiß-Terminals sitzen und über ein längst vergessenes Netzwerkprotokoll Daten übertragen wollen – dafür wurde FTP entwickelt.

FTP ist ungeeignet

Wenn vor so langer Zeit ein Protokoll entwickelt wurde, dann ist es natürlich für heutige Einsatzzwecke so gut geeignet wie eine Sänfte für den Einsatz auf einer bundesdeutschen Autobahn. Insbesondere zum Verwalten von Website ist es total ungeeigent, weil es den Status auf dem Server nicht verfolgt:

Wenn man nicht einfach immer alle Dateien übertragen will, dann muss man jede Datei vergleichen. Außerdem kann es passieren, dass man Änderungen überschreibt, die jemand anderes auf dem Server vorgenommen hat. Man muss also immer die komplette Website vom Server auf den Client kopieren bevor man Änderungen vornimmt.

Hat man Änderungen auf dem Server vorgenommen, dann kann man diese nicht mehr einfach rückgängig machen. Um das tun zu können muss man jedesmal vorher manuell ein Backup erstellt haben.

Und nein: Ich bin nicht der Einzige, der das meint

Wer FTP nutzt, der tut das weil er es nicht besser weiß. Jeder, der sich Gedanken macht wird FTP nicht nutzen. Dementsprechend gubt es keine Argumentation für FTP, nur dagegen: Schon 2011 war klar, dass man FTP nicht mehr nutzen will und es gibt schöne Listen mit Argumenten.

Fazit: Do not use

Es gibt nur noch ganz wenige Einsatzzwecke für die FTP ein geeignetes Protokoll ist: nur dann wenn es sich quasi um öffentliche Daten handelt. Für das Verwalten von Websites ist es definitiv das falsche Protokoll.

Insbesondere beim Bearbeiten der Verbindungseinstellungen von E-Mail-Programmen kommt immer wieder die Frage auf ob denn SSL oder TLS besser wäre; deshalb hier ein GANZ kurzer Überblick:

tl;dr

I.d.R. ist die Auswahl „SSL“ besser.

Die Verschlüsselung

TLS ist die neue Version von SSL, der Nachfolger von SSL. Deshalb ist TLS sicherer, SSL sollte man nicht mehr verwenden. Welche Version benutzt wird, machen die Programme aber unter sich aus. Das ist für den Benutzer nicht einzustellen. Kein normaler Benutzer sollte mit dieser Entscheidung in Kontakt kommen.

Wenn gefragt wird „willst Du SSL oder TLS“, dann ist nur die Frage falsch formuliert. Korrekt müsste die Frage lauten: „Willst Du einen Verbindungsaufbau nach Art von SSL oder STARTTLS?“

Der Verbindungsaufbau

Früher (zu Zeiten von (dem alten) SSL) brauchte man für verschlüsselte Übertragung und für unverschlüsselte Übertragung zwei verschiedene Ports. Wenn man also heute „SSL“ auswählt, dann verbindet sich das Mailprogramm auf einen Port, der nur für verschlüsselte Verbindungen da ist.

Heute (zu Zeiten von TLS) gibt es eine weitere Möglichkeit: STARTTLS. Damit verbindet sich das Mailprogramm auf den unverschlüsselten Port und schaltet dann auf Verschlüsselung um. Über dieses Umschalten müssen sich Client und Server einig werden und wenn man nicht genau aufpasst (und das Mailprogramm so konfiguriert, dass es die Verschlüsselung zwingend voraussetzt), dann kann es passieren, dass dann ohne Verschlüsselung übertragen wird.

(START)TLS ist also eher als eine Krücke zu sehen, die benutzt wird, wenn kein eigener Port für die verschlüsselten Verbindungen zur Verfügung steht.

Fazit

Zwar ist TLS „besser“ als SSL, aber wenn Du (als normaler Anwender) gefragt wirst: nimm SSL statt (START)TLS. Wenn Du die Auswahl hast. I.d.R. hast Du die Auswahl bei POP und IMAP, bei SMTP ist ein eigener Port eher unüblich, da muss man i.d.R. (START)TLS nehmen.

Weiterlesen

Auf englisch hier:

• https://www.fastmail.com/help/technical/ssltlsstarttls.html

…oder bei der Wikipedia:

• Der Verbindungsaufbau: STARTTLS
• die Verschlüsselung: SSL und TLS

Rant

Es ist eigentlich gar nicht so schwer – wenn nur die Software-Herstellen mal dazu übergehen würden, die Dinge richtig zu bezeichnen. Regelfall ist aber, dass nicht die fachlich korrekten Bezeichnungen verwendet werden, sondern jedes Programm an die Optionen irgendwas hinschreibt, so dass man selbst als sehr erfahrener Anwender raten muss. Wenn es also nicht wie erwartet geht: das liegt nicht an euch, sondern an der Ahnungslosigkeit und Ignoranz der Softwarehersteller und insbesondere der Software-Oberflächen-Übersetzer. Vielleicht hilft es schon, das Programm auf englisch zu installieren.

Wenn man E-Mail-Dienste bereitstellt, dann sollte man es den Nutzern einfach machen die E-Mail-Programme korrekt zu konfigurieren.

„502 Bad Gateway“ ist ein http-Fehler. „502“ ist die Fehlernummer und „Bad Gateway“ die Erklärung.

Bedeutung

Der Browser (Firefox, Chrome, IE, Safari o.ä) hat bei einem Webserver (www.example.com o.ä.) nach einer Website gefragt. Der Webserver kann die Anfrage aber nicht alleine beantworten. Er muss dazu eine weitere Software befragen (z.B. Online-Shop, Forum, anderer Webserver, etc.)

Bei dieser Anfrage kam es zu einem Fehler, welche die Schnittstelle („Gateway“) zu dieser Software dem Webserver zurückgemeldet hat. Der Webserver kann die Anfrage von Deinem Browser also nicht beantworten und versucht sich mit der bösen Schnittstelle rauszureden.

Wie kann ich das beheben/umgehen?

Beheben kann das nur der Webmaster der Website. Umgehen kann man das höchstens mittels eines Caches wie Googles Cache, Wayback-Machine o.ä.

Das Puppet will schauen, welche Dienste auf dem Trusty im LXC laufen. Das Upstart vom Trusty funktioniert aber komischerweise nicht so wie es soll:

root@u4:/# status foo
status: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart-session/1000/5747: Connection refused
root@u4:/# echo $UPSTART_SESSION
unix:abstract=/com/ubuntu/upstart-session/1000/5747
root@u4:/# unset UPSTART_SESSION
root@u4:/# status foo
status: Unknown job: foo
root@u4:/# echo $UPSTART_SESSION

root@u4:/#

Warum?

Ich habe eigentlich gedacht ich könne mittels „Augen zu und durch“ einfach warten bis systemd in Ubuntu einzug gehalten hat. Grmpf.

Die Variable wurde vom lxc-attach gesetzt, weil sie im Wirtssystem gesetzt war. Über SSH passiert das nicht. Warum das aber im Wirtssystem gesetzt ist und ob das korrekt ist weiß ich nicht.