• „FTP“ steht für „File Transfer Protocol“ und ist das unverschlüsselte Ding, das wir nicht mögen.
• „Secure FTP“ ist auch als „FTP over SSH“ bekannt und bezeichnet ein frickeliges Protokoll, bei dem der Steuerkanal durch eine SSH-Verbindung getunnelt wird, während der Datenkanal weiterhin unverschlüsselt ist.
• „SFTP“ steht für „SSH File Transfer Protocol“ (und nicht etwa für „Secure FTP“!). Es dient zwar auch der Dateiübertragung, hat implementierungstechnisch aber absolut nichts mit FTP zu tun.
• „FTPS“, das auch als „FTP Secure“ oder als „FTP-SSL“ bezeichnet wird, ist eine SSL-/TLS-Erweiterung für FTP, die wahlweise auf einem separaten Port läuft und dort direkt SSL „spricht“ (imliziter Modus; vergleichbar mit SSL-Ports wie 465 für SMTP oder 993 für IMAP; gilt als veraltet), oder aber auf dem normalen FTP-Port läuft und dem Client ermöglicht, den Steuer- und ggf. auch den Datenkanal zu verschlüsseln oder aber eben bei der unverschlüsselten Verbindung zu bleiben (expliziter Modus, gelegentlich auch als „FTPES“ bezeichnet).

Lücken im IPsec Stack von OpenBSD haben nichts mit OpenSSH zu tun, OpenSSH benutzt kein IPsec und die Verschlüsselung die bei IPsec zum Einsatz kommt ist von den reinen Algorithmen mal abgesehen sehr stark verschieden von der bei SSH genutzten. IPsec ist dafür berüchtigt, daß es komplex und schwer zu implementieren ist — anders als SSH. Man könnte auch auf den kaputten Pseudozufallsgenerator in OpenSSL bei Debian vor ein paar Jahren verweisen, aber OpenSSH nutzt auch kein OpenSSL. Vor solchen Sicherheitslücken ist man aber letztlich nie absolut sicher, selbstverständlich auch bei OpenSSH nicht. Hieraus zu schließen, Transportverschlüsselung wäre generell unnötig, bedeutet jedoch das sprichwörtliche Kind mit dem Bade auszuschütten.

Daß FTP einfach zu implementieren sei, ist für mich kein Argument. Telnet wäre noch einfacher zu implementieren, aber das macht es nicht besser. Von Telnet mal abgesehen wäre eine weitere Alternative zu FTP WebDAV über HTTPS, was ebenfalls recht leicht zu implementieren sein dürfte.

Die Erfahrung, daß FTP von überall auf der Welt aus funktioniert teile ich nicht. FTP ist bekannt für sein schlechtes Zusammenspiel mit Firewalls und Tunneln. Versuch mal aktives FTP hinter einer herkömmlichen Firewall und einem Router mit NAT zu benutzen. Oder wenn Du Herausforderungen schätzt: Versuch mal in Asien hinter mehreren, geketteten NATs irgendeine Form von FTP zu benutzen.

Verzichtet man wie bei FTPS auf die Verschlüsselung der Datenübertragung und vermeidet dann das übertragen von Passwörtern in Dateien, bleibt das Problem, daß man oftmals zum Zeitpunkt der Datenübertragung nicht weiß, ob man gerade sensible Daten überträgt oder nicht, oftmals stehen Klartextpasswörter in Configs ohne daß man das ahnt (wer hat schon den Quellcode einer typischen Webanwendung komplett gelesen?). Bei reinem FTP bleibt wie mein Kollege anmerkte das Problem, daß auch Name und Passwort mit denen sich dann jeder der das mitsnifft auf dem erschnüffelten Account einloggen kann. Ein Sniffer muß sich noch nichtmal die Mühe machen die geschnüffelten Pakete noch zu decodieren oder zu dekomprimieren, denn FTP läuft über reines ASCII im Klartext, das Passwort steht dann schon deutlich lesbar im tcpdump.

Die Argumente, die du dafür bringst, dass FTP super sei … die treffen doch genauso auch auf SFTP zu: Einfach zu programmieren, einfach anzuwenden.

Das Argument mit dem Daten vorher/nachher verschlüsseln erschließt sich mir nicht. Wenn ich (vorher) verschlüsselte Daten über eine unverschlüsselte FTP-Verbindung übertrage, gehen ja immer noch meine Zugangsdaten unverschlüsselt durchs Netz, womit ich potentiell unberechtigten Dritten Zugriff auf meinen Account verschaffe.

Die Nachricht über die potentielle Backdoor in der IPsec-Implementierung stärkt ohne Frage das Misstrauen in Verschlüsselung allgemein. Zu hoffen wäre, dass dies ein Signal für umfangreichere Audits darstellt. Mir ist aber die Folgerung nicht klar, wieso es dann besser sein sollte, die Daten vorher zu ver- und nachher zu entschlüsseln – eine Backdoor in einer Crypto-Implementierung kann ja schließlich genauso auch in den Tools stecken, die du lokal für die Verschlüsselung vor der Übertragung verwendest. Aufgrund der beschriebenen Problematik dann aber auch gleich das gesamte „Prinzip Verschlüsselung“ in Frage zu stellen, finde ich dann schon etwas übertrieben – Sicherheit ist schließlich kein „ganz oder gar nicht“. Vielleicht ist mein Anspruch ja auch nur, meine Daten z.B. vor den Augen eines Mitbewerbers zu schützen, und der bliebe ja immer noch erfüllt, selbst wenn das FBI eine Möglichkeit zur Entschlüsselung hätte (was unerfreulich genug wäre).

ftp schlecht? ich find ftp super!

ich kann von jedem client und aus jedem dorf in afrika zur not etwas herunterladen und bin arbeitsfähig. und es ist einfach zu programmieren/einzubinden. nach der übertragung werden dann die daten abgeholt/verschoben/woanders was gemacht.

die daten kann man sicherer/besser vorher/nacher verschlüsseln/entschlüsseln. zumal momentan nachrichten wie diese http://www.heise.de/security/meldung/FBI-Backdoor-in-IPSec-Implementierung-von-OpenBSD-1153180.html nicht das vertrauen in die vergügbaren verschlüsselungen stärken.

Die besten Alternativen heißen SCP und SFTP. Beides geht mit gängigen SSH-Programmen wie OpenSSH oder putty, es gibt auch spezialisierte Programme wie WinSCP. Unter Linux und MacOS X ist auch sshfs eine Option, das benutzt im Hintergrund SFTP, stellt das ganze aber so dar als hätte man es mit einem lokal angeschlossenen Laufwerk zu tun (WebDAV macht etwas ganz ähnliches, nur läuft es halt über HTTP und nicht über SSH). Ich muß allerdings gestehen, daß ich sshfs unter MacOS X schon ewig nicht mehr zu tun hatte. Dort gibt es aber auch noch Cyberduck und ein paar andere Programme. Ein Freund der viel Webentwicklung macht hat mir glaubhaft versichert, daß die ernst zu nehmenden Programme in diesem Bereich (insbesondere das teure von der Firma die sich nach Lehm benannt hat) alle SFTP unterstützen und die meisten auch mit SSH-Pubkeys umgehen können.

So oder so: Der Platinstandard für Kommandozielenzugriff und Dateiübertragung heißt SSH. Wo das nicht möglich ist, kann man auf WebDAV über HTTPS ausweichen. (Von Leuten die mit Windows Servern geschlagen sind weiß ich, daß das auf ihrer Plattform das Mittel der Wahl ist, auch wenn man OpenSSH wohl auch dort mit ein paar Klimmzügen zum Laufen bekommt.)