1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Fileserver: FTP sollte mit 50 endlich…

Overheadverschwendung

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Overheadverschwendung

    Autor: tux. 19.04.21 - 15:19

    Es ist ein wenig schade, dass auch in Zeiten steigender mobiler Nutzung von Internetdiensten die Verschwendung von Overhead ("HTTP statt FTP") noch empfohlen wird. FTP hat minimalen Protokolloverhead, es durch HTTP - Hypertextübertragungsprotokoll, nicht Dateiübertragungsprotokoll - zu ersetzen ist mit "dämlich" noch vorsichtig formuliert IMHO.

  2. Re: Overheadverschwendung

    Autor: 1e3ste4 19.04.21 - 15:24

    Noch so einer, der keine Ahnung hat.

    Welchen "Overhead" hat HTTP denn bitte?

    Ganz im Gegenteil: FTP ist mit den benötigten zwei parallel laufenden Ports und den PASV-Modus, damit FTP überhaupt durch irgendeine Firewall kommt, umständlich in Firewalls zu behandeln. Beim normalen FTP öffnet der Server eine Verbindung zum Client (sic!).

  3. Re: Overheadverschwendung

    Autor: Allandor 19.04.21 - 15:27

    Zumal, es ja nicht bei HTTP endet, sondern dann noch Verschlüsselung etc dazu kommt. Overhead ohne ende.
    Habe bis heute nicht verstanden warum heutzutage alles verschlüsselt sein muss. Das erschwert eigentlich nur das Caching von Daten wodurch im Endeffekt effektiv deutlich mehr über die Leitung muss als früher.
    Jaja, ich weiß, Sicherheit etc, aber bei manchen Daten ist es einfach nicht wichtig. Z.B. das lesen von Golem Artikeln ist jetzt nichts was man extra verschlüsseln müsste (inkl. der angezeigten Bilder & Videos). Klar wäre es dann einfacher mir Fakes unter zu schieben, aber da gibt es auch noch so genügend Möglichkeiten dies zu machen.

  4. Re: Overheadverschwendung

    Autor: tux. 19.04.21 - 15:27

    1e3ste4 schrieb:
    --------------------------------------------------------------------------------
    > Noch so einer, der keine Ahnung hat.

    Na, bewerten wir wieder die Kenntnisse von Fremden übers Internet?

    > Welchen "Overhead" hat HTTP denn bitte?

    Vergleich mal HTTP-Requestheader mit FTP-Requestheadern und dann frag noch mal.

  5. Re: Overheadverschwendung

    Autor: TrollNo1 19.04.21 - 15:28

    Je nachdem, in welchem Land du bist, und was in dem Golem-Artikel steht, hast du sehr wohl Interesse daran, dass der Inhalt verschlüsselt wird.

    Menschen, die mich im Internet siezen, sind mir suspekt.

  6. Re: Overheadverschwendung

    Autor: Allandor 19.04.21 - 15:42

    TrollNo1 schrieb:
    --------------------------------------------------------------------------------
    > Je nachdem, in welchem Land du bist, und was in dem Golem-Artikel steht,
    > hast du sehr wohl Interesse daran, dass der Inhalt verschlüsselt wird.

    Auch danach weiß noch jeder das du auf Golem warst, der an die entsprechenden Daten kommt. Bis vor ein paar Jährchen war sogar der IE der einzige verbreitete Browser, der die URL so weit es eben ging verschlüsselte (bei HTTPS ... und das bei dem ansonsten sicherheitstechnisch miserablen IE). In Chrome und Firefox waren die URL Parameter noch lange Zeit unverschlüsselt.

    Ändert aber nix dran. Solltest du in einem solchen Land leben, führt eh kein weg an VPN + entsprechender Netzwerke vorbei. Abgesehen davon gibt es heutzutage so viele Geräte, das du die Daten eh keine Nutzer zuordnen könntest, solange du die MAC zufällig wählen lässt und keine Benutzerdaten über HTTP schleifst.
    Abgesehen davon, das in den entsprechenden Staaten gern mal der ein oder andere Staatstrojaner mitliest und du dagegen eh nicht viel machen kannst, ohne extremen ärger zu bekommen.



    1 mal bearbeitet, zuletzt am 19.04.21 15:44 durch Allandor.

  7. Re: Overheadverschwendung

    Autor: MarcusK 19.04.21 - 15:50

    Allandor schrieb:
    --------------------------------------------------------------------------------
    > TrollNo1 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Je nachdem, in welchem Land du bist, und was in dem Golem-Artikel steht,
    > > hast du sehr wohl Interesse daran, dass der Inhalt verschlüsselt wird.
    >
    > Auch danach weiß noch jeder das du auf Golem warst, der an die
    > entsprechenden Daten kommt. Bis vor ein paar Jährchen war sogar der IE der
    > einzige verbreitete Browser, der die URL so weit es eben ging
    > verschlüsselte (bei HTTPS ... und das bei dem ansonsten
    > sicherheitstechnisch miserablen IE). In Chrome und Firefox waren die URL
    > Parameter noch lange Zeit unverschlüsselt.

    hast du dafür mal eine link? Ich müsste gar nicht wie man bei https daten unverschlüsselt übertragen sollte. Hier wurde ja erst nachträglich überhaupt die Möglichkeit geschaffen wenigstens den Hostname ( https://de.wikipedia.org/wiki/Server_Name_Indication ) mitzuschicken.

  8. Re: Overheadverschwendung

    Autor: ralfh 19.04.21 - 15:59

    Die Behauptung ist auch grober Unfug. Die URL, bzw. die Query String Parameter sind Teil des HTTP Requests (also Application Layer) und noch bevor auch nur ein einziges Bit davon übertragen wurde, muss der TLS/SSL Handshake und Verbindungsaufbau bereits erfolt sein (anders als bei anderen Protkollen wo ein Upgrade der TLS-Verbindung optional ist, z.B. bei SMTP via "STARTTLS").

    SNI ist in dem Zusammenhang ebenso uninteressant, weil da geht es ja eben darum eine sichere "Rezertifizierung" über TLS durchzuführen, nachdem bereits eine sichere Verbindung aufgebaut wurde (weil der Webserver ein signiertes Zertifikat senden muss, noch bevor dieser über den HTTP Request "Host" Header eine Zuordnung zu einem namensbasierten VHost treffen kann, der eventuell ein anderes Zertifikat verlangt).

  9. Re: Overheadverschwendung

    Autor: M.P. 19.04.21 - 16:00

    Wie oft ich bei TCPDUMP schon gesehen habe dass da mal wieder base64 über die Leitung getrommelt wird....

    Muss man nicht so machen, aber wird häufig so gemacht, weil binärdaten base64 codiert und mit fake content type besser überall durchkommt....

    aber "octet-stream" sieht man immer häufiger ;-)

  10. Re: Overheadverschwendung

    Autor: Tyrola 19.04.21 - 16:02

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > Allandor schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > TrollNo1 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Je nachdem, in welchem Land du bist, und was in dem Golem-Artikel
    > steht,
    > > > hast du sehr wohl Interesse daran, dass der Inhalt verschlüsselt wird.
    > >
    > > Auch danach weiß noch jeder das du auf Golem warst, der an die
    > > entsprechenden Daten kommt. Bis vor ein paar Jährchen war sogar der IE
    > der
    > > einzige verbreitete Browser, der die URL so weit es eben ging
    > > verschlüsselte (bei HTTPS ... und das bei dem ansonsten
    > > sicherheitstechnisch miserablen IE). In Chrome und Firefox waren die URL
    > > Parameter noch lange Zeit unverschlüsselt.
    >
    > hast du dafür mal eine link? Ich müsste gar nicht wie man bei https daten
    > unverschlüsselt übertragen sollte. Hier wurde ja erst nachträglich
    > überhaupt die Möglichkeit geschaffen wenigstens den Hostname (
    > de.wikipedia.org ) mitzuschicken.

    Ich denke er meint das DNS standardmäßig nicht verschlüsselt ist und man immerhin erkennen kann wo sich der User herumtreibt ohne genau zu sehen welche Inhalte der User genau augerufen hat. Stimmt zwar aber auch da wird daran gearbeitet, damit das künftig ebenfalls verschlüsselt läuft (DoH).

    Aber Verschlüsselung hat nicht nur den Vorteil "anonymer" durchs Web zu surfen sondern stellt mir auch sicher, dass der Inhalt nicht manipuliert wurde. Und wenn es nur ausgetauschte Werbebanner sind. Gerade mit FTP könnte man Dateien während des Uploads manipulieren und damit Dokumente o.Ä. super einfach fälschen.

    Ich finde den Overhead mit aktuellen Endgeräten wirklich keine Rede mehr wert, okay mobiles Datenvolumen vielleicht aber da hat vermutlich eh niemand ernsthaft vor große Datenmengen zu befördern wenn man sich bereits um wenige kbit/s Overhead ernsthaft Gedanken macht.

    Dazu kommt das die meisten Anwender von FTP vermutlich keine IT Experten sind und gar nicht im klaren darüber sind, dass wenn sie ihre (zum Beispiel) Buchhaltungsdaten auf den Firmen FTP vom öffentlichen WLAN aus hochladen problemlos von jedermann mitgelesen werden können.

    Das FTP Protokoll gehört dringend ersetzt. Und wenn man es nur durch SFTP ersetzt, ist es in meinen Augen ein kleiner Schritt in die richtige Richtung.

  11. Re: Overheadverschwendung

    Autor: ralfh 19.04.21 - 16:04

    Wenn man unverschlüsselte DNS-Lookups als Argument gegen HTTP anbringt, gelten die analog und genauso für FTP.

    Also ja, Domainnamen (das, was in HTTP 1.1 als Host-Header im HTTP Request landet) sind unverschlüsselt über DNS abgreifbar. Aber das hat mit HTTP an sich überhaupt nicht im Entferntesten was zu tun.



    1 mal bearbeitet, zuletzt am 19.04.21 16:05 durch ralfh.

  12. Re: Overheadverschwendung

    Autor: MarcusK 19.04.21 - 16:07

    ralfh schrieb:

    > SNI ist in dem Zusammenhang ebenso uninteressant, weil da geht es ja eben
    > darum eine sichere "Rezertifizierung" über TLS durchzuführen, nachdem
    > bereits eine sichere Verbindung aufgebaut wurde (weil der Webserver ein
    > signiertes Zertifikat senden muss, noch bevor dieser über den HTTP Request
    > "Host" Header eine Zuordnung zu einem namensbasierten VHost treffen kann,
    > der eventuell ein anderes Zertifikat verlangt).
    nein.
    https://de.wikipedia.org/wiki/Server_Name_Indication
    > Der server_name-Parameter wird unverschlüsselt übertragen

    wenn man es ganz dumm macht, könnte man dort auf die Idee kommen die URL Parameter mit zu übertragen - aber das hat kein Browser gemacht.

  13. Re: Overheadverschwendung

    Autor: Tyrola 19.04.21 - 16:13

    ralfh schrieb:
    --------------------------------------------------------------------------------
    > Wenn man unverschlüsselte DNS-Lookups als Argument gegen HTTP anbringt,
    > gelten die analog und genauso für FTP.
    >
    > Also ja, Domainnamen (das, was in HTTP 1.1 als Host-Header im HTTP Request
    > landet) sind unverschlüsselt über DNS abgreifbar. Aber das hat mit HTTP an
    > sich überhaupt nicht im Entferntesten was zu tun.

    HTTP ist ja genau so gut wie tot? Laut Google Chrome Statistik surfen die User zwischen 78-95% (je nach Platform) https Webseiten an. Im Detail siehts so aus (tendenz steigend).

    Linux User: 78%
    Windows User: 90%
    Android User: 93%
    Mac User: 95%
    Chrome OS User: 98%



    1 mal bearbeitet, zuletzt am 19.04.21 16:14 durch Tyrola.

  14. Re: Overheadverschwendung

    Autor: ralfh 19.04.21 - 16:15

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > nein.
    > de.wikipedia.org
    > > Der server_name-Parameter wird unverschlüsselt übertragen


    Nein zu was? Ich glaube nicht, dass wir einander widersprechen, bzw. dass es überhaupt einen Dissens gibt?

  15. Re: Overheadverschwendung

    Autor: MarcusK 19.04.21 - 16:17

    ralfh schrieb:
    --------------------------------------------------------------------------------
    > MarcusK schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > nein.
    > > de.wikipedia.org
    > > > Der server_name-Parameter wird unverschlüsselt übertragen
    >
    > Nein zu was? Ich glaube nicht, dass wir einander widersprechen, bzw. dass
    > es überhaupt einen Dissens gibt?

    Hierzu das nein

    > SNI ist in dem Zusammenhang ebenso uninteressant, weil da geht es ja eben darum eine
    > sichere "Rezertifizierung" über TLS durchzuführen, nachdem bereits eine sichere Verbindung
    > aufgebaut

    das "nachdem" ist falsch.

  16. Re: Overheadverschwendung

    Autor: ralfh 19.04.21 - 16:17

    Tyrola schrieb:
    --------------------------------------------------------------------------------
    > ralfh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wenn man unverschlüsselte DNS-Lookups als Argument gegen HTTP anbringt,
    > > gelten die analog und genauso für FTP.
    > >
    > > Also ja, Domainnamen (das, was in HTTP 1.1 als Host-Header im HTTP
    > Request
    > > landet) sind unverschlüsselt über DNS abgreifbar. Aber das hat mit HTTP
    > an
    > > sich überhaupt nicht im Entferntesten was zu tun.
    >
    > HTTP ist ja genau so gut wie tot? Laut Google Chrome Statistik surfen die
    > User zwischen 78-95% (je nach Platform) https Webseiten an. Im Detail
    > siehts so aus (tendenz steigend).
    >
    > Linux User: 78%
    > Windows User: 90%
    > Android User: 93%
    > Mac User: 95%
    > Chrome OS User: 98%

    HTTP bzw. HTTPS habe ich hier mal gleichbedeutend behandelt. Innerhalb einer gekapselten TLS Verbindung ist der HTTP-Standard (welcher nun auch immer konkret verwendet wird), ja nach wie vor der gleiche alte, analog FTP zu FTPS.

    Tot wäre es, würden wir alle SPDY verwenden bzw. HTTP/2.0 wobei das da so auch nicht pauschal gesagt werden könnte, weil HTTP/2 weiterhin einen HTTP-Unterbau hat.

  17. FTP ist das denkbar schlechteste Beispiel dafür...

    Autor: Vanger 19.04.21 - 16:22

    Ich stehe dem "Anything over HTTPS"-Trend auch kritisch gegenüber, DoH ist ein tolles Beispiel dafür zu welchen Absurditäten das führt. Mit FTP hast du aber wirklich ein schlechtes Beispiel gewählt... FTP ist ein schreckliches Protokoll, man denke an "Active Mode" vs. "Passive Mode". Gerade bei einem Dateiübertragungsprotokoll ist der Header-Overhead wenig relevant - anders als bspw. bei DoH, wenn die Header häufig größer sind als die Nutzdaten.

    Dennoch stimme dem Artikel nur teilweise zu. Nein, um FTP braucht man wirklich nicht trauern. HTTP als "die Alternative" darzustellen ist aber genauso falsch. HTTP ist für die unidirektionale Dateiübertragung, worum es bei den im Artikel genannten Beispielen (Linux-Kernel und Debian) ging, die wohl beste Alternative.

    Für eine bidirektionale Dateiübertragung ist HTTP denkbar ungeeignet. HTTP alleine unterstützt bidirektionale Dateiübertragung überhaupt nicht, dafür braucht's Protokollerweiterungen wie WebDAV - und auch das ist nur ein Teil der Wahrheit. Wenngleich der Artikel anderes suggeriert, nutzen Seafile und Nextcloud eigene Protokolle, die zwar auf HTTP und WebDAV aufbauen, diese aber z.T. deutlich erweitern. Diese Entscheidung beruht auch weniger auf der Überzeugung, dass das die beste technische Lösung sei, sondern auf Kompatibilitätsüberlegungen.

    Für bidirektionale Dateiübertragungen gibt es bessere Alternativen. Wenn es um Dateisynchronisation geht ist rsync das Maß der Dinge, für Remote-Dateizugriffe NFS. Hinsichtlich der sinnvollen Einsatzszenarien ist SFTP noch am nähesten an FTP. Allen Alternativen ist jedenfalls gemein, dass sie besser als FTP sind.

  18. Re: Overheadverschwendung

    Autor: ralfh 19.04.21 - 16:29

    MarcusK schrieb:
    --------------------------------------------------------------------------------
    > > SNI ist in dem Zusammenhang ebenso uninteressant, weil da geht es ja eben
    > darum eine
    > > sichere "Rezertifizierung" über TLS durchzuführen, nachdem bereits eine
    > sichere Verbindung
    > > aufgebaut
    >
    > das "nachdem" ist falsch.

    Das ist jetzt eine Frage der Semantik würde ich meinen (aber auch da reden wir zunächst einmal über den TLS-Standard, nicht HTTPS. Das "Problem" besteht genauso bei FTPS + SNI was einige Server durchaus unterstützen).

    Wir unterhalten uns hier glaube ich über die Unterschiede zwischen RFC 3546 und RFC 6066. Ich meinte nur letzterer würde die unverschlüsselten server_name Extension erlauben, wodurch keine Rezertifierung durchgeführt werden muss. Vielleicht kannst du mir sagen ob nur RFC 6066 Teil von TLS 1.3 ist? Ansonsten würde ich die Behauptung wagen, dass Browser beide Verfahren unterstützen müssten.

  19. Re: Overheadverschwendung

    Autor: MarcusK 19.04.21 - 16:32

    ralfh schrieb:
    --------------------------------------------------------------------------------
    > MarcusK schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > > SNI ist in dem Zusammenhang ebenso uninteressant, weil da geht es ja
    > eben
    > > darum eine
    > > > sichere "Rezertifizierung" über TLS durchzuführen, nachdem bereits
    > eine
    > > sichere Verbindung
    > > > aufgebaut
    > >
    > > das "nachdem" ist falsch.
    >
    > Das ist jetzt eine Frage der Semantik würde ich meinen (aber auch da reden
    > wir zunächst einmal über den TLS-Standard, nicht HTTPS. Das "Problem"
    > besteht genauso bei FTPS + SNI was einige Server durchaus unterstützen).
    >
    > Wir unterhalten uns hier glaube ich über die Unterschiede zwischen RFC 3546
    > und RFC 6066. Ich meinte nur letzterer würde die unverschlüsselten
    > server_name Extension erlauben, wodurch keine Rezertifierung durchgeführt
    > werden muss. Vielleicht kannst du mir sagen ob nur RFC 6066 Teil von TLS
    > 1.3 ist? Ansonsten würde ich die Behauptung wagen, dass Browser beide
    > Verfahren unterstützen müssten.

    nein, das kann ich leider nicht. Ich hatte nur einige mal das Netzwerk mitgelesen und den hostnamen im Klartext gesehen. Nach welchen RFC das jetzt war, war mir bis jetzt nicht wichtig. (wusste nicht mal das es das wieder verschiedene gibt)

  20. Re: FTP ist das denkbar schlechteste Beispiel dafür...

    Autor: fabiwanne 19.04.21 - 16:33

    Keine der genannten Lösungen kommt an die Performance von FTP dran. SMB vielleicht. Aber das ist ja genau so verhasst. Und so einfach wie ein FTP ist auch nur sftp zu administrieren. Dem Fehlt aber ganz massiv der anonnymos-Mode und die Performance ist auch eher bescheiden.
    Wenn irgend jemand eine funktionierende Alternative bringt: Gerne. FTP zu töten ohne eine bessere Alternativ zu haben ist aber Quatsch.

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. über Network Selection AG, Bussnang (Schweiz)
  2. BET3000 Deutschland Management GmbH, München
  3. Pädagogische Hochschule Schwäbisch Gmünd, Schwäbisch Gmünd
  4. Bundeskartellamt, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme