Dem Freundeskreis des FTP-Protokolls auf den Schlips getreten…

Ooooh, ich habe Liebesbriefe bekommen. [Noch’n Steinzeit-Update]

Ich hatte mich doch negativ zu Sony und FTP geäußert. Das hat einigen Leuten gar nicht gefallen. Und der Tonfall kommt ziemlich eindeutig aus dem Rudelprogramm der Amygdala.

Der erste Liebesbrief

HTTP ist ein Protokoll zum Übertragen von Text. Sagt der Name schon. Dass da irgendwelche Kasper jetzt Up- und Downloads drüber laufen lassen, ist ein Zeichen von Dekadenz. FTP (auch mit SSL) ist dafür halt optimiert. Der HTTP-Overhead ist mitunter größer als die Dateien.

— tux0r (@tux0r) October 27, 2021

Schlicht falsch.

Die Eignung von HTTP

HTTP ist – auch wenn es anlässlich der Entwicklung des Hypertext-Systems bestehend aus dem Hypertext Transfer Protocol (HTTP) und der Hypertext Markup Language (HTML), umgangssprachlich auch als Web bekannt, entwickelt und benannt wurde, und in der Ur-Version, der Entwurfsversion 0.9 der Protokollbeschreibung noch die Rede davon ist, dass HTML-Texte übertragen werden, macht das Protokoll keinerlei Vorgaben für den Inhalt, der eine beliebige Byte-Folge sein kann. Deshalb hat man mit der ersten offiziellen Version auch die Angabe des MIME-Types hinzugefügt, weil man damit nämlich beliebige Daten übertragen kann – sonst bräuchte man ja auch die Angabe des MIME-Types nicht (der angibt, um welche Daten es sich handelt). Zunächst hat man Bilder damit übertragen, inzwischen längst alles. Video, Programme, völlig egal. Youtube, Podcasts, Firmware-Updates, läuft alles über HTTP, weil das Protokoll eben völlig unabhängig vom Inhalt ist. Vor allem verändert HTTP den Inhalt nicht. Unter keinen Umständen.

HTTP ist längst der de-facto-Standard für Datentypen jeglichen Inhalts, weil es nicht auf den Inhalt ankommt.

Die Eignung von FTP

FTP dagegen ist das Protokoll, das auf die Übertragung von Text-Dateien ausgelegt ist, weil FTP per se Dateien zwischen den Zeichensätzen der beiden beteiligten Maschinen übersetzt, also beispielseweise zwischen EBCDIC und ASCII oder zwischen den Formaten der Consolen-Drucker und deren Zeilenenden CR, LF, CRLF, NL, VT, FF konvertiert, also die Dateien verändert. Klassischer Fehler war, bei der Übertragung von Dateien mit Sonderzeichen oder Bildern oder Programmen zu verbessen, vorher den BINARY-Befehl einzugeben, der die Übertragung abschaltet, und dann nur Datenmüll und kaputte Dateien zu bekommen, weil FTP die Zeichensätze konvertiert hat, auch wenn es ein Bild-Datei war.

Der Aufwand: TCP

FTP ist dafür überhaupt nicht „optimiert“. Im Gegenteil ist FTP weit entfernt davon, optimal zu sein. Und die Aussage, dass der HTTP-Overhead „mitunter größer als die Dateien“ ist, zeugt von blanker Unkenntnis und fehlendem Verständnis davon, was da eigentlich passiert. Abgesehen davon, dass die Datei schon sehr kurz sein muss, um kürzer als der HTTP-Header zu sein.

Der erste Punkt betrifft nämlich den TCP-Verbindungsaufbau. Bei FTP laufen die Kommandos über eine TCP-Verbindung, die Daten über eine weitere, und zwar eine pro Datei. Um n Dateien zu übertragen brauche ich also n+1 TCP-Verbindungen, wenn ich die Kommando-Verbindung offen halten und für alle benutzen kann (was aber in IoT-Anwendungen, Gadgets, Mobilanwendungen usw. oft nicht geht), und 2n Verbindungen, wenn ich jedesmal (etwa für jedes Bild einer Kamera) eine neue FTP-Verbindung aufmachen muss, etwa weil die Zeit zu lange dauert, man in einem Mobilfunknetz ist, wo Verbindungen schnell terminiert werden, oder man mit einem Kleingerät wie eben einer Kamera arbeitet, die die Verbindung nicht offen halten kann. Beispielsweise akkubetriebene WLAN-Geräte, die WLAN nur bei Bedarf einschalten, weil das nämlich Strom zieht. Und dann zum Beispiel auch per DHCP neue IP-Adressen bekommen. Und gerade die IoT-Geräte und Gadgets, die oft kein volles Betriebssystem haben, sondern TCP/IP nur über Bibliotheksaufrufe abbilden, sind oft nicht in der Lage (oder so programmiert), dass sie Verbindungen über einen Prozeduraufruf hinweg offenhalten, sondern die Verbindungen jedesmal neu aufbauen, weil Verbindungen als Datentyp in einer prozedurlokalen Variable gespeichert werden, und das bei jeder Dateiübertragung neu aufgerufen wird, wenn das – wie so oft – auf einer GUI beruht, in der der Benutzer dann die Bilder einzeln auswählt.

Bei HTTP dagegen brauche ich höchstens eine TCP-Verbindung pro übertragener Datei. Also nur n Verbindungen. Das ist bei einem übertragenen Bild schon mal nur die Hälfte, nämlich 1 statt 2. Oder bei Einzelaufbau der Verbindung und 1000 Bildern eben 1000 statt 2000. Wichtiger ist aber: Seit HTTP/1.0 experimentell und seit HTTP/1.1 offiziell gibt es die HTTP persistent connection, also die Möglichkeit, eine bestehende TCP-Verbindung für weitere HTTP-Requests offenzuhalten. Und damit kann ich sämtliche Bilder über eine einzige Verbindung übertragen. HTTP/2.0 kann die sogar multiplexen, womit ein Stocken bei einer Übertragung nicht die anderen aufhält.

Also: Für n Bilder brauche ich bei FTP n+1 TCP-Verbindungen, wenn ich die Verbindung dabei offenhalten kann, und 2n Verbindungen, wenn nicht. Bei HTTP dagegen brauche ich nur 1 TCP-Verbindung, wenn ich sie offenhalten kann, und n TCP-Verbindungen, wenn nicht.

Der Aufbau von TCP-Verbindungen ist aber teuer in Bezug auf die Zeit. Nicht nur, weil dabei statt der reinen Übertragungsgeschwindigkeit als Durchsatz auch die Latenzzeit zum Tragen kommt und das leicht in den Sekundenbereich geraten kann. Nicht nur, weil das Betriebssystem zum Aufbau den 3-Pakete-Handshake (SYN-SYN+ACK-ACK) durchführen und jedesmal auf die Antwort warten muss, sondern auch, weil Firewalls und Betriebssystem neue Verbindungen erst untersuchen und ihn ihre Datentabellen eintragen und die Prozesse darüber informieren müssen, statt wie bei bestehenden Verbindungen die Pakete direkt per Tabelle durchzuwinken.

Übertrage ich beispielsweise 1000 Bilder, kann also der Aufwand bezüglich des Verbindungsaufbaus bei FTP gegenüber HTTP bei dem Doppelten (wenn Verbindungen jedesmal komplett neu aufgebaut werden, also 2n bei FTP und n bei HTTP) oder Tausendfachen (wenn Verbindungen gehalten werden, also n+1 bei FTP und 1 bei HTTP) liegen.

Der Aufwand: TLS (Verschlüsselung)

Was ich eben über die Zahl der TCP-Verbindungen gesagt habe, gilt genauso für die Zahl der TLS-Verschlüsselungsverbindungen (dazu unten mehr), die ja pro TCP-Verbindungen aufgebaut werden. Auch da ist der Aufbau der Verbindung das, was Zeit kostet, weil da wieder Handshakes stattfinden müssen, bei der jeder auf die Antwort des anderen warten muss, also die Latenzzeiten zum Tragen kommen, und vor allem: Weil beim Verbindungsaufbau zum Aushandeln des Sitzungsschlüssels asymmetrische Kryptographie zum Einsatz kommt. Das ist die mit den langen Primzahlen, der Exponentialrechnung und sowas. Das dauert laaange. Steht die Verbindung erst mal, kommen schnelle Blockchiffren zum Einsatz, die viel weniger Zeit brauchen, und die neuere Prozessoren sogar im Befehlssatz drin haben.

Auch da schlägt also das, was ich oben über die Zahl der Verbindungsaufbauten gesagt habe, voll zu.

Der Aufwand: Das Protokoll (Applikationsebene)

Was bei Datenübertragungen auch Zeit kostet, ist, wenn man auf Antworten des anderen warten muss. Wenn man also einen Befehl hinschickt und Daten überträgt, und dann warten muss, bis die Antwort kommt. Weil dann nicht (nur) die Übertragungskapazität, der Durchsatz, eine Rolle spielen, sondern die Latenzzeit. (Beispiel: Es ist ein Unterschied, ob ich einen LKW zur Backfabrik schicke, Brötchen holen, oder mit dem Rad zur Bäckerei fahre. Der LKW hat zwar den höheren Durchsatz und kann mir mehr liefern, aber auch die höhere Latenzzeit, weil der ein paar Stunden braucht, bis er wieder da ist. Will ich also nur ein paar Brötchen für den Frühstückstisch, ist die Latenzzeit wichtiger als der Durchsatz.)

FTP ist da katastrophal. Der Client muss nämlich für eine Dateiübertragung normalerweise mindestens diese Kommandos ausführen (auch wenn man das von der Kommandozeile aus nicht merkt, was darunter alles abläuft:

1. Auf Server-Prompt warten
2. USER username und auf Antwort warten
3. PASS passwort und auf Antwort warten
4. PORT-Befehl und auf Antwort warten, wenn der Client aktiv-FTP-will und keinen Zugriff auf den geschützten Port 20 hat
5. PASV-Befehl und auf Antwort warten, wenn der Client Passiv-FTP will oder das Netz oder der Server nur das zulässt.
6. Datenformat-Befehl um Datentyp Binary einzustellen und auf Antwort warten
7. CWD-Befehl, wenn die Daten nicht in das Root-Verzeichnis des Servers, sondern in ein Unterverzeichnis geschrieben werden sollen, wobei nicht alle FTP-Server Argumente aus mehreren Pfadelementen akzeptieren, also pro Directory ein Befehl ausgegeben werden muss, natürlich auf Antwort warten
8. Der Übertragungsbefehl zum Hoch- oder Runterladen der Datei

Könnt Ihr in RFC 959 nachlesen.

Das heißt, dass um nur eine einzige Datei zu übertragen etwa 8 Protokoll-Schritte erforderlich sind und damit 17 Richtungswechsel (der erste Schritt braucht kein Kommando). Und das dann noch doppelt oder dreifach, wenn eine Firewall oder Proxy dazwischen ist, die die Befehle jedesmal zwischeninterpretieren müssen, um die Port-Befehle verstehen und für NAT übersetzen und in Regeln umsetzen müssen.

Zwar ist TCP bidirektional, ein Rechner muss also nicht zwingend alles lesen, bevor er schreiben kann, weil es hier aber auf die Antworten ankommt, und jede Seite auf das reagieren muss, was die andere sendet, führt das dazu, dass jede Seite erst warten muss, bis alles angekommen ist, bevor sie selbst senden kann. TCP kann zwar Vollduplex, aber FTP erzwingt Halb-Duplex samt Puffer-Leerung.

Richtungswechsel kosten aber Zeit, weil jedesmal die Reaktion abgewartet werden muss, also die Latenzzeiten des Netz und bis auf der anderen Seite die Puffer leer und an die Anwendung durchgelaufen und bearbeitet sind.

HTTP dagegen kommt mit einem einzigen Befehl und einer einzigen Antwort aus, also einem einzigen Richtungswechsel. Der Client sendet Befehl samt Authentifikation und Zielverzeichnis mit den Daten in einem Rutsch und wartet einmal auf die Antwort des Servers. Fertig. Können Firewall und Proxy verzögerungsfrei durchreichen.

Der Aufwand: Der Header

Auch das Argument mit dem Overhead durch den Header, der länger sein könnte als die Datei selbst, zieht nicht. Denn erstens braucht FTP weitaus mehr Overhead, bis all die Befehle durch und beantwortet sind. Zweitens muss man nicht so geschwätzig wie ein Browser sein, sondern kann sich auf die Pflichtangaben beschränken, und die sind sehr kurz. Drittens macht der HTTP-Header im Vergleich zu den mehreren Megabyte einer Fotodatei gar nichts aus. Viertens braucht der HTTP-Header keinen TCP-Richtungswechsel, weil er zusammen mit den anderen Daten übertragen wird, und passt meistens (jedenfalls, wenn man wie hier das notwendige verwendet) in ein einzelnes IP-Fragment. Und wenn, wie der Leser anmault, die Daten kürzer als der Header sind (kann z. B. bei REST-API-Anwendungen sogar oft vorkommen), passt oft der gesamte Request in ein einzelnes IP-Paket, der Header hat also praktisch keine Auswirkungen auf die Zeit. Wer Bilder hochlädt, muss beispielsweise seinen Browser-Typ nicht angeben, weil er keine maßgeschneiderten Webseiten braucht. Die Language-Typ nicht, die verstandenen MIME-Types nicht. Bei solchen Nicht-Browser-Anwendungen, die nur etwas hochladen, kann der Header ganz kurz ausfallen, nur die Pflichtfelder enthalten.

Fazit

Fazit: Was der Leser da schreibt, ist komplett falsch.

HTTP ist das optimierte Protokoll. Nicht FTP.

Ich will nichts gegen FTP sagen. Es war ein Meilenstein und äußerst nützlich. Aber es stammt aus der frühesten Anfangszeit und ist über 40 Jahre alt. Damals hatte man gänzlich andere Anforderungen, man kannte, wusste, konnte und brauchte es damals nicht besser.

Vor allem ist FTP für Maschinen der damaligen, extrem niedrigen Rechenleistung und Speicherkapazität ausgelegt. FTP-Server und Client können als Software sehr klein und einfach ausfallen, was man auch brauchte, wenn man nur ein MHz Prozessortakt und nur ein paar kByte Speicher hat. Und vor allem: Auf die Übertragungszeit kam es damals überhaupt nicht an, sondern nur darauf, dass es überhaupt mal funktioniert.

Ein andere Problem ist, dass da in der Frühzeit auch alles erst mal experimentell und nicht auf Qualität oder gar Sicherheit ausgelegt war, und sobald mal irgendwas funktionierte, egal wie schlecht, alle Leute draufsprangen und das zum Quasi-Standard wurde. So kam es auch zu Krücken wie DNS oder SMTP, die vor dem Kontext ihrer damaligen Zeit und des damaligen Standes der Technik und des Wissens, naja, sagen wir in Ordnung waren, aber heute eigentlich katastrophal veraltet sind.

Der zweite Liebesbrief

Per E-Mail:

Ich würde Dir empfehlen, mal die Bedienungsanleitung der Sony Kamera zu lesen und was da so über Root-Zertifikate, die in der Kamera gespeichert werden, SSL, IPsec und Blah und Bluna steht, dann wüsstest Du auch, wie die Kamera sich wirklich über “FTP” verbindet!

Du verbreitest echt nur Geschwätz! Wikipedia-Informatiker?

Wikipedia-Informatiker?

Nein, Diplom-Informatiker, der von ca. 1988 bis 1998 Unix-Systemadministrator an der Uni war und ein Institut betreut hat, und der von 1998 bis 2007 unzählige Firewalls installiert und Firmen an das Internet angeschlossen hat. Zumal ich ja auf den RFC und nicht die Wikipedia verwiesen habe.

Sony-Bedienungsanleitungen

Also in den Anleitungen meiner A6300 und meiner A7II steht nichts davon. Da ist die Rede von einer Handy-App und einer Software namens „PlayMemories Home“, wenn man Dateien von der Kamera auf einen Computer übertragen will.

Und die Anleitung der neuen A7IV, auf die ich mich bezog, ist, zumindest soweit ich das jetzt auf deren Webseite entdecken konnte, noch nicht verfügbar. Die Kamera ist ja auch noch nicht lieferbar und gerade erst angekündigt. Anleitungen werden immer erst mit dem Release der Software herausgegeben, weil sich das alles noch ändern kann, und die Software gerade bei neuen Kameras noch bis zuletzt gefeilt.

Welche Anleitung müsste ich denn da lesen? Alle?

Übrigens steht auch in der Anleitung der A7III dazu nur

You can use the camera’s Wi-Fi function to transfer images to the FTP

server.

For details, refer to the “FTP Help Guide.”

http://rd1.sony.net/help/di/ftp/h_zz/ und da steht es für verschiedene Kamera-Typen. Aber noch nicht die 7IV.

Es ist zwar tatsächlich so, dass einige der neueren Sony-Kameras erlauben, ein Root-Zertifikat einzugeben, also schon irgendwas mit Verschlüsselung machen, aber dazu schreibe ich im nächsten Abschnitt.

Ich bezog mich außerdem auf die Werbung.

FTP vs. FTPS

Wenn sie erlauben, ein Root-Zertifikat für FTP-Server einzugeben, machen sie tatsächlich etwas mit TLS. Ich bezog mich aber auf die Werbung.

In der Werbung steht FTP.

Im Gegensatz zu HTTP, bei dem man die Varianten mit und ohne TLS meint, wenn man davon redet, gilt dies bei FTP nicht. Dann hätten sie FTPS schreiben müssen.

Warum ist das so?

Aus dem einfachen Grund, dass HTTP so sauber entworfen ist, dass es völlig vom darunterliegenden Transportmechanismus getrennt ist (deshalb haben sie die URLs erfunden). Es spielt für HTTP keine Rolle, welcher Transportmechanismus darunterliegt, es geht auch völlig ohne Internet. Man kann HTTP völlig problemlos auch über Unix-Domain-Sockets oder was auch immer laufen lassen, ohne dass es dazu irgendeiner Protokolländerung oder -erweiterung bedürfe.

Bei FTP ist das nicht der Fall. Bei FTP sind Anwendung und die Steuerung der Transportschicht vermischt. Um FTP über TLS führen zu können, braucht man eine Protokollerweiterung und neue Befehle, und eine ausführliche Beschreibung (RFC 4217 und RFC 2228).

Das ist zwar eine Obermenge von FTP, und enthält FTP, es ist aber nunmal ein anderes Protokoll, weil es weitere Befehle und Funktionen benötigt, um überhaupt verschlüsseln zu können.

Wenn also jemand HTTP schreibt, dann schließt das die Verschlüsselung nicht aus, weil man HTTP unverändert über TLS o.ä. führen kann. HTTP und HTTPS sind dasselbe Anwendungsprotokoll. Wenn jemand dagegen FTP schreibt, dann meint er das unverschlüsselte, weil die Verschlüsselung nur über die Protokollerweiterung möglich ist.

Kurioserweise haben sie auch noch vergessen, dem Ding einen Namen zu geben, aber in Analogie zu HTTPS = HTTP+SSL (SSL = alte Version, Vorgänger von TLS) hat sich FTPS eingebürgert.

Implicit vs. Explicit

Nicht sauber durchdefiniert, faktisch doppeldeutig, gibt es zwei FTPS-Verianten (ähnlich wie bei SMTP und IMAP), nämlich einmal die Variante, die von vornherein die Verbindung über TLS aufmacht und andere Ports (990/989 statt 21/20) und dann darin das normale Protokoll spricht, und die, die auf den normalen Ports erst das normale Protokoll öffnet und dann darin einen Start-Befehl gibt.

Was verschlüsselt FTPS überhaupt?

Nächste Falle, auf die schon viele reingefallen sind.

Wenn man liest, dass FTPS eben FTP mit Verschlüsselung, SSL oder TLS steht, dann denkt man, das sei verschlüsselt.

Isset aba nich. Jedenfalls nicht immer.

Denn FTPS verschlüsselt weder die Kommando-, noch die Datenverschlüsselung zwingend. In beiden Fällen kommt es darauf an, dass der Client diese überhaupt wünscht. Man kann also FTPS machen und – ungewollt, unwissentlich – trotzdem im Klartext übertragen. Das hatte damals schon sehr umstrittene Gründe, die – und da verweise ich jetzt doch mal auf die Wikipedia, weil dort schön zusammengefasst – heute nicht mehr gültig sind. Nämlich, weil Verschlüsselung damals eine sehr teure Sache war, teuer in Rechenzeit und Stromverbrauch. Die Prozessoren hatten das noch nicht eingebaut, und dann sagte man sich,

• wenn die Daten nicht vertraulich sind, dann sparen wir uns die aufwendige Verschlüsselung,
• die Verbindung läuft über VPN, ist also schon verschlüsselt,
• die Daten selbst sind schon – z. B. mit PGP – verschlüsselt,
• die Verschlüsselung ist verboten, etwa beim Transport aus den USA heraus.

Da sind viele drauf reingefallen. Deshalb hat dieses Gebastel zur Rettung eines veralteten Protokolls auch nie jemand ernst genommen. Das war noch nie etwas anderes als eine Krücke, die man an ein damals schon veraltetes Protokoll angeflanscht hat.

Was genau Sony da nun treibt? – Tja, sieht und liest man nicht. Kann sein, kann auch nicht sein.

Das muss man sich immer in Netz per Sniffer genau ansehen, was da läuft. Anleitungen helfen da nicht weiter.

Downgrade-Resistenz

Das Problem an Protokollen, bei denen die Verschlüsselung optional ist, dass sie per se und in den Implementierungen oft anfällig gegen sogenannte Downgrade-Attacken sind. Solange ein Angreifer nur passiv mithört und die Daten nicht verändern kann, ist alles sicher, weil sich beide Seiten auf eine Verschlüsselung einigen.

Kann sich der Angreifer aber aktiv reinschalten und den Part einer Seite übernehmen, kann er sich bei manchen Protokollen, die dagegen anfällig sind, und behaupten, er sei der Server X, biete aber keine (oder nur eine schlechtere) Verschlüsselung an. Und manchmal reagieren die Clients dann mit „dann halt eben ohne“.

Das heißt, es reicht nicht, die Anleitung zu lesen oder einer Sony mal zuzuschauen, man müsste auch das explizit austesten.

Firewall-Traversal

FTP und mehr noch FTPS sind für Firewalls hochproblematisch, weil die da die Kommandoverbindung nicht nur mithören, sondern teils sogar verändern müssen, um die separaten Datenverbindungen richtig durchleiten zu können. FTP ist so ein richtiges Scheiß-Protokoll.

Das geht aber nicht (ohne weiteres), wenn die Verbindung verschlüsselt und signiert ist, wie es TLS eben so treibt. Also muss man die Firewall als Proxy davorschalten, was enormen Zusatzaufwand an Konfiguration und Rechenzeit voraussetzt, weil die Verbindung dann auch – bei modernen, schnellen Firewalls – nicht per Hardware-Firewall durchgeleitet werden kann. Das muss man alles einstellen, und viele moderne, günstigere Firewalls können das nicht (mehr), weil FTP einfach sowas von out und 80er/90er ist.

Viele Amateur-Admins und Nutzer selektieren die Einstellungen dann nur nach geht/geht nicht und machen FTP dann faktisch unverschlüsselt, weil es so dann überhaupt zum Laufen zu bringen ist.

Extra-Küsschen

Und weil wir gerade so schön dabei sind, bekommt der Freundeskreis des FTP-Protokolls von mir noch ein paar Extra-Küsschen.

IPv6

Inzwischen ist IPv6 nicht nur etabliert, sondern die IPv4-Adressen gehen tatsächlich aus. Es ist für Provider inzwischen ziemlich schwer, noch an Kontingente von IPv4 zu kommen. Deshalb gibt es zunehmend Netzwerke, Cloud-Server, besonders Mobilfunknetze, die nur noch IPv6 anbieten (und IPv4 vielleicht noch über NAT, Dual Stack light oder so). Oder happig Aufpreis für IPv4 nehmen.

Und? Kann FTP IPv6? Grundsätzlich nein. Weil FTP diesen Fundamentalfehler macht, die Steuerung der Transportschicht mit der Anwendung zu vermischen und das noch mit Steinzeittechnik. Der Befehl zur Übertragung der IP-Adresse und des Ports für die Datenverbindung lautet nämlich (Siehe RFC 959 Abschnitt 4.1.2.):

DATA PORT (PORT)

The argument is a HOST-PORT specification for the data port
to be used in data connection. There are defaults for both
the user and server data ports, and under normal
circumstances this command and its reply are not needed. If
this command is used, the argument is the concatenation of a
32-bit internet host address and a 16-bit TCP port address.
This address information is broken into 8-bit fields and the
value of each field is transmitted as a decimal number (in
character string representation). The fields are separated
by commas. A port command would be:

PORT h1,h2,h3,h4,p1,p2

where h1 is the high order 8 bits of the internet host
address.

Da stehen die Bytes noch einzeln drin, weil man es damals einfach haben und Rechenzeit für das Parsen sparen wollte. Da passt eine IPv6-Adresse schon von der Syntax her nicht rein. Freilich hat man auch dafür wie der eine „Protocol Extension“ gebaut, den RFC 2428. Wieder so einen Workaround, wieder eine Frickel-Bastel-Nummer, wieder ein neuer Befehl.

Kann die Sony das? Steht nicht dabei. Kann der Firmen-FTP-Server das? Weiß man auch nicht so genau.

Virtuelle Server

Was uns daran erinnert, dass ein FTP-Server immer eine eigene IP-Adresse braucht. Was zumindest unter IPv4 problematisch sein kann, wenn man da nur ganz wenige bekommen hat. Manche Firma, die eine eigene Standleitung hat, bekomme gerade mal einen /30-Bereich. Oder einen /32.

HTTP dagegen kennt das Konzept virtueller Server. Man kann hunderte, tausende Webserver auf derselben Maschine betreiben, die nur eine IP-Adresse hat. Weil der Client nach Aufbau der Verbindung dazusagt, mit welchem der Webserver er gerne sprechen möchte und das nicht nur durch die IP-Adresse bestimmt wird.

Mit FTP geht das nicht.

Serverless Computing

Mit HTTP kann man solche Dienste auch ganz ohne IP-Adresse und eigenen Server betreiben. Beispielsweise bietet Amazon in seiner AWS-Cloud AWS-Lambda-Processing an, wo man nur eine Funktion in einer Programmiersprache angibt und keinen vollständigen Server mehr betreibt. Abrechnung nach tatsächlich beanspruchter Rechenzeit und nicht nach Laufzeit einer virtuellen Maschine im Dauerlauf.

Ansprechen per HTTP oder REST-API über den URL, basierend auf dem Konzept der virtuellen Server (s.o.).

Wäre zum Beispiel prächtig geeignet, um Fotos etwa von Veranstaltungen wie der Expo, wo gute WLAN-Verbindung herrscht, automatisch an die Cloud hochzuladen mit ihrer hohen Performance und Netzanbindung und die Bilder automatisch in Speicherlösungen wie S3 abzulegen und von anderen Programmen abzurufen. Das wäre eine professionelle und hochverfügbare Lösung für Profifotografen mit hohen Anforderungen.

Mit FTP geht es jedenfalls nicht so einfach, weil man dafür eine virtuelle Maschine mit eigener IP-Adresse ständig vorhalten muss. Das kann man über eine automatische Installation zwar auch so hinbasteln, dass man sie erst dann installiert, wenn man sie braucht und danach wieder wegwirft, aber wenn man es eilig hat…

Containerisierung

Derzeit trendender Stand der Technik ist, Server als Container zu implementieren. Auch wenn man da unterschiedlicher Meinung sein kann, hat es durchaus enorme Vorteile, den Server und seine Implementierung so zu kapseln, dass sie wiederverwendbar und schnell und identisch installierbar sind.

Derzeit aktuell sind dazu eben Docker-Container. Manche NAS-Systeme (z.B. Synology) sind inzwischen in der Lage, Docker-Container auszuführen, und Kubernetes kommt gerade groß in Mode. Es hat seine Nachteile, aber unbestreitbar auch seine Vorteile.

Nur: Zu einer Container-Spezifikation gehört auch, auf welchen Ports das Ding lauschen soll. Und das kollidert mit der PASV-Variante von FTP, weil da jeder Port in Frage kommt. Viele Clients und Netzwerke funktionieren aber nur mit der PASV-Variante.

Ergebnis

FTP passt überhaupt nicht mehr in die moderne IT-Landschaft und ist wirklich Steinzeit. Ein ruhmreiches, aber völlig veraltetes Protokoll. Und vor allem: Unnötig. Es hat keinerlei Funktion oder Nutzen, der nicht von HTTP weitaus besser und robuster abgebildet werden könnte.

Im Gegenteil, es wäre weitaus nützlicher und sinnvoller, wenn die Kamerahersteller sich auf eine REST-API oder sowas einigen würden und dann damit eine Verarbeitungskette angestoßen werden würde. Weil man heute nämlich auch nicht mehr in Kategorien wie „ich lege was auf die Festplatte“ denkt, sondern prozess- und ablauforientiert, oder neudeutsch „message-driven“, und das Anfertigen eines Fotos genau so etwas ist. Das kann man für FTP zwar auch implementieren, aber HTTP hat das praktisch schon im Blut.

Es fehlt mir jedes Verständnis dafür, dass Kamerahersteller heute noch mit so einem Mist ankommen, auch wenn ich weiß, dass das gewissermaßen ein Verkaufsargument ist, weil viele Agenturen und Fotografen sich zwar auch für die Creme und Boheme des Internet hält, weil sie einen Mac auf dem Tisch stehen haben, faktisch aber nur eine Laienspieltruppe sind, die an etwas festhält, weil sie einmal etwas zum Funktionieren gebracht und einen Soziologen oder Kunsthistoriker als Netzwerkadmin eingestellt haben.

Mir gehen diese Leute so auf die Nerven, die wie die zwei Schreiberlinge so Halb- oder Viertel- oder Google-Wissen haben, und dann meinen, nicht nur alles besser zu wissen, sondern nur noch per Feind-Beschimpfung (=Markierung der ist vom fremden Rudel, im Prinzip wie „Nazi“ schreien) auftreten. Und dann Amygdala-gesteuert auf alles als Feind losgehen, was sie als Infragestellen ihres Leithammels oder ihrer Community-Sitten auffassen.

Kein Mensch, der ernstlich Ahnung von IT hat und nicht gerade Spezialanforderungen wie die Rückwärtskompatibilität zu irgendeiner Dampfmaschine oder einem Relikt aus dem zweiten Weltkrieg hat, verwendet noch FTP. Eigentlich waren wir von 20 Jahren schon an dem Punkt, an dem wir damals als Beratungsfirma jedem davon abgeraten haben, noch FTP einzusetzen, schon gar nicht öffentlich zugänglich im Internet.

Andere Leser schreiben mir sowas:

Ich bin SAP Entwickler und arbeite bei diversen Schweizer Unternehmen (mittel bis gross). Jedes dieser Unternehmen verwendet immer noch FTP bei verschiedenen Schnittstellen (inkl. SFTP, FTP/S).

Ja. Die hatten auch die Crypto AG und Omnisec im Pelz.

Ein anderer

Hallo Herr Danisch,

zu ihrem Artikel des ftp-“Missbrauchs” durch Sony.
Ich war relativ erstaunt das Brother einen relativ günstigen Dokumentenscanner anbietet der einige Protokolle zur Übertragung der Scans zur Auswahl hat. Neben webdav und auch ftp war ich sehr erfreut das auch eine Möglichkeit via ssh angeboten wird. Zugegeben, die Einrichtung ist etwas hackelig, key-pair auf dem Gerät erstellen und dann den public key exportieren, aber insgesamt doch erfreulich verständlich (Wenn man sich einmal durchgearbeitet hat).

Das wäre doch gerade für die etwas professionelleren Nutzer ziemlich gut (In der Annahme das sie zumindest eine Person haben die sich um die Technik kümmert).

Andererseits war ich gerade sehr erstaunt dass das openssh-binary auf einer nicht ganz aktuellen Distribution schon 711 KiB belegt… bestimmt könnte man das etwa abspecken.

Mit freundlichen Grüßen,

Das ist doch schon mal prima, wenn der auch modernere Sachen anbieten. Da würde ich ganz klar webdav nehmen. ssh nur dann, wenn es triftige Gründe dafür gibt und die Server-Seite entsprechend konfiguriert ist, dass da nichts anderes aufgerufen werden kann (als vermutlich sftp), damit der Scanner keine Befehle ausführen kann.

Warum kann das Brother, aber nicht Sony?

Hallo Hadmut,

zu Deinem FTP-Beitrag fiel mir gleich wieder der TED-Talk von Marcus Raum ein:
https://www.youtube.com/watch?v=o59mQhBiUo4

22 Minuten die sich sehr lohnen und auf die vielen Probleme der legacy Protokolle wir FTP eingeht. Und auch unterhaltsam.

Viele Grüße,

Kannte ich noch nicht. Ich habe es auch noch nicht gesehen, nur an ein paar Stellen geklickt, und was der da als Folie (2009) zeigt, ist richtig und beschreibt genau die Probleme. Zumal Marcus Ranum von Firewalls richtig Ahnung hat, der hatte ja damals auch das Firewall-Toolkit herausgegeben.

Mir fehlt jedes Verständnis dafür, wenn „High-Tech-Unternehmen“ wie Sony noch mit einem derartigen Scheiß daherkommen – auch wenn mir klar ist, dass sie deshalb damit werben, weil es in der Künstler- und Medienbranche so viele bornierte Laien gibt, die an ihrem Uralt-Geraffels festhalten und die Kamera nicht nach den Anforderungen oder dem Objektivpark, sondern passend zum FTP-Server kaufen, weil sie den zum Laufen bekommen haben und an der 40 Jahre alten Software keiner was anrühren darf.

Update: Ein Leser hat sich das Ranum-Video angesehen:

Und bei der Portierung auf TCP/IP wurde das einfach so belassen…

— retiredfarmer (@liveandletmow) October 28, 2021

Huahahahaha.