Du brauchst dich nicht 10 mal für deine Frage zu entschuldigen, das hier ist schließlich ein Forum, in welchem Leute diese Fragen stellen sollen.
FTP ist nicht schlecht, du kannst es nur nicht so gut für dein Vorhaben missbrauchen, FTP steht für "File Transfer Protocol" und das kann es sehr gut. Übrigens basiert FTP auf TCP, genauso wie eigentlich so ziemlich alle Protokolle im Internet auf TCP basieren (HTTP z. B. auch).

Dekar schrieb:

denke nicht das jeder Benutzer des Programms dazu bereit ist sich hinzusetzen um irgendwelche Ports zu öffnen

Muss er ja auch nicht, bei TCP werden ausgehende Verbindungen meistens durch die Firewall durchgelassen. Genauso wie bei FTP und HTTP muss bei TCP jedoch auch ein Server vorhanden sein und bei diesem kommen die Verbindungen rein - da muss der Port geöffnet sein und wenn du nur einen Server hast, muss das auch nur einmal passieren.
Der Grund, wieso FTP so beliebt ist, ist der, dass es viele kostenlose Server im Internet gibt. Bei TCP musst du dich selbst darum kümmern (VPS, Root Server oder dein Computer), obwohl es manchmal auch kostenlose zu finden gibt, welche dir dann gesponsort werden.

VincentTB schrieb:

FTP ist nicht schlecht

Doch. FTP sollte man gar nicht mehr verwenden, warum weißt Du ja hoffentlich. Wenn man das Ganze noch verschlüsselt (also FTPS nutzt), dann ist das aber durchaus in Ordnung, um Dateitransfers durchzuführen. Ist hier aber ja eh uninteressant.

Ansonsten sollte das hier mit TCP so klappen wie beschrieben.

Grüße

Das Problem mit den Ports hast du sowieso immer. Ob TCP, UDP oder irgendwas was darauf aufbaut, HTTP, FTP, ... alle brauchen Ports.

Ein RPC Framework wie grpc.io/ könnte dir helfen. (Nicht direkt bei der Port-Problematik, wurde jetzt ja oft genug erklärt. Server braucht nen offenen Port zum Lauschen, Client nicht. Falls du vom Server auf den Client zugreifen möchtest, lass trotzdem den Client die Verbindung aufbauen. Fertig.)
GRPC verwendet HTTP/2 und - konfigurierbar - TLS. Zusätzlich kannst du Client und Server in verschiedenen Sprachen entwickeln, wobei die Schnittstelle von GRPC gestellt wird.

TCP Clients brauchen keine offenen Ports? Wie kann ich das verstehn?

Du musst als Client bei Deinem Router keinen Port freigeben, sondern nur beim Server.

Grüße

Trade schrieb:

VincentTB schrieb:

FTP ist nicht schlecht

Doch.

Nö, in erster Linie um diesem unsinnigen FTP-Gebashe mal etwas entgegen zu setzen. Warum soll ich FTP (ohne das S) nicht nutzen, um in meinem lokalen Netzwerk oder auch VPN Datein zu verschieben? Ich kann verstehen, dass bei all den wundervollen Plänen von Leuten, auf FTP basierende Chats zu entwerfen oder grundsätzlich im Internet mit offenen FTP-Servers zu arbeiten, einige dazu übergegangen sind, Protokolle von vornerein zu verteufeln. Ändert allerdings recht wenig an der Tatsache, dass das wahre Problem komplett woanders liegt, nämlich im Punkt Verschlüsselung oder noch allgemeiner, dem Punkt Sicherheit.

FTP kann genauso viel und wenig schlecht sein wie unverschlüsseltes TCP, unverschlüsseltes HTTP usw. Es kommt ausschließlich darauf an, wie man es einsetzt. POP3, der E-Mail-Standard, inzwischen von IMAP fast vollständig abgelöst, ist auch unverschlüsselt und überträgt ebenfalls sensible Daten wie Nutzername und Passwort unverschlüsselt. Es entstehen auch haufenweise neue Protokolle, die unverschlüsselt sind, siehe MQTT. Weshalb sollte ich auch die Kommunikation zwischen meinen Maschinen verschlüsseln, wenn die mit ihrem Netzwerk komplett abgeschottet sind und nicht einmal den Hauch einer Ahnung vom WWW haben?

FTP hat und hatte in seiner langen Geschichte schon immer einen klaren Zweck, den es noch immer erfüllt. Selbstverständlich ist das Protokoll inzwischen alt und viele Aufgaben muss man zwingend über andere Wege lösen. Aber bitte erklärt es anderen Nutzern dann auf diese Weise, anstatt einfach zu sagen, FTP sei 'schlecht'.

Auch innerhalb eines eigenen Netzwerks ergibt es Sinn, nicht darauf zu hoffen, dass sich keiner (physisch) Zugang verschafft hat und jegliche kommunikation per MITM mithört. Ich denke, es gibt relativ wenige Anwendungsfälle, bei denen reines FTP noch angemessen ist, z.B. wenn aus Performancegründen auf Verschlüsselung verzichtet werden muss.

lukekogv schrieb:

einmal den Hauch einer Ahnung vom WWW haben?

Das WWW ist nicht dasselbe wie das Internet...

lukekogv schrieb:

FTP hat und hatte in seiner langen Geschichte schon immer einen klaren Zweck, den es noch immer erfüllt.

Das Argument ist so sinnvoll wie zu sagen:

• DOS erfüllt immer noch seinen Zweck
• Autos ohne Airbags oder Sicherheitsgurten erfüllen immer noch ihren Zweck
• Höhlen erfüllen immer noch ihren Zweck als Schalfmöglichkeit

Relativ wenige Anwendungsfälle?

Es gibt bei Indutrieanlagengen genügend Maschinen welche weiterhin nur FTP als Kommunikationsmittel kennen!

Quadsoft schrieb:

lukekogv schrieb:

FTP hat und hatte in seiner langen Geschichte schon immer einen klaren Zweck, den es noch immer erfüllt.

Das Argument ist so sinnvoll wie zu sagen ...

Direkt im nächsten Satz schreibe ich davon, dass man viele Aufgaben anders lösen muss und dementsprechend ist dies durchaus ein sinnvolles Argument für die Aussage, dass man Protokolle gerade gegenüber Nichtwissenden nicht einfach so als 'schlecht' bezeichnen sollte, sondern ganz allgemein eher differenzierter denken und bewerten muss. User XY wollte vor Jahren mal ein Chat-Programm basierend auf FTP schreiben und fragte hier um Hilfe. Es entlud sich ein Sturm der Entrüstung, bei dem die lautesten Stimmen nur enthielten, FTP sei 'scheiße'. Dementsprechend taucht User XY (exemplarisch) in jedem Thread auf, in dem über FTP geredet wird und verbreitet die frohe Kunde: "FTP ist schlecht". Dass diese Form der Aufklärung jedoch nur sehr begrenzt hilft, zeigt dieser Thread sehr gut. Anstatt zu erklären oder auf weitere Informationen zu verweisen, was FTP oder auch TCP überhaupt sind, wird über mögliche Probleme mit Firewalls diskutiert. Die Aussage, TCP bräuchte gegenüber FTP offene Firewall-Ports ist hochgradig unsinning und entstammt vermutlich einer ähnlich einseitigen Belehrung aus früherer Zeit.

Nun mal ein wenig zurück zum Thema: Bitte vergleicht nicht FTP und TCP! FTP liegt als Protokoll in der Anwendungsschicht des sogenannten OSI-Modells (WICHTIG) oder auch des DoD-Modells. Als solches verwendet es ein Protokoll der darunterliegenden Transportschicht, nämlich das hier vielzitierte TCP. FTP ist also quasi auch TCP. Letztendlich ist auch HTTP TCP und all ihre verschlüsselten Pendants ebenfalls. TCP kümmert sich darum, dass eine Verbindung zwischen zwei Parteien zwecks Kommunikation aufgebaut wird. Dabei bietet eine der Parteien einen sogenannten Socket an und die andere verbindet sich zu diesem. Was dann kommuniziert wird, wird in der Anwendungsschicht entschieden. So sorgt das HTTP-Protokoll beispielsweise dafür, dass die eine Partei eine Anfrage (Request) abgibt und eine Antwort (Response) zurückbekommt. Danach wird die Verbindung wieder getrennt und für jede einzelne Anfrage erneut aufgebaut. Auch beim FTP wird für jede Anfrage (Upload, Download, Dateiauflistung) eine separate Verbindung erstellt. Es ist selbstverständlich auch möglich, eine solche TCP-Verbindung längerfristig aufrecht zu erhalten.

Nun zum Thema FIREWALLS: Firewalls blocken in erster Linie die Verbindung zu einem angebotenen Socket. Dieser Socket ist meist Teil des Servers, der die Kommunikation ausmacht. Wenn man beispielsweise eine Website besucht oder eine App verwendet, werden die Daten an den Server gesendet und bei diesem muss in der Firewall an geeigneter Stelle ein Port offen sein, durch den ein Webbrowser oder eine App kommunizieren kann. Auch der Gegenüber, mit dem man durch die App oder über die Website kommuniziert, verbindet sich zu diesem Server, wodurch keine zusätzliche Firewall geöffnet werden muss. Dies gilt für alle Protokolle, die auf TCP basieren, also auch für FTP und HTTP. Falls ihr euch fragt, ob sämtliche Kommunikation über TCP läuft, nein, es gibt auch andere Protokolle der Transportschicht, so beispielsweise UDP. Während TCP einen eingebauten Mechanismus hat, der überprüft, ob gesendete Pakete auch angekommen sind, verschickt UDP diese einfach ohne zu wissen ob sie ankommen. Dies wird häufig in Bereiche wie Video-/Audioübertragung eingesetzt, da es deutlich schneller ist und dort nicht zwingend jedes Paket ankommen muss. Auch für UDP gelten solche Firewalls.

Ich hoffe, ich konnte hier ein wenig aufklären oder, was noch schöner wäre, zum weiteren eigenständigen Recherchieren anregen. Um es noch einmal zusammenzufassen: Ich möchte nicht das File Transfer Protokoll oder dessen weit verbreitete Anwendung verteidigen, sondern ausschließlich darauf hinweisen, dass es klüger ist, jemandem zu sagen weshalb er etwas nicht verwenden sollte, anstatt einfach zu sagen 'Bliblablub ist scheiße'. Es hift niemandem, wenn der User FTP meidet, um dann sein eigenes TCP-Protokoll zu verwenden, in dem die Nutzerdaten im Klartext durch die Gegend fliegen.

PS: Mir ist durchaus der Unterschied zwischen dem Internet und dem World Wide Web bewusst und habe den falschen Begriff gewählt, da ich in einer vorherigen Version ein wenig mit dem 'World Wide'-Teil rumgespielt habe um diese globale Kommunikation zu unterstreichen

PPS: Mir ist gerade erst aufgefallen, dass VincentTB den Zusammenhang (FTP <=> TCP) schon recht früh erläutert hat. Letztendlich ist dieser Beitrag also nur eine etwas ausführlichere Ergänzung, die zudem nochmal einmal auf die Art und Weise eingeht, wie hier in meinen Augen etwas zu undifferenziert Protokolle betrachtet werden

lukekogv schrieb:

auf FTP basierende Chats zu entwerfen [...] einige dazu übergegangen sind, Protokolle von vornerein zu verteufeln.

Nein. Das sind Fälle, in denen FTP sowieso nichts zu suchen hat, unabhängig davon, ob es verschlüsselt ist oder nicht. Mit FTPS gehört so oder so kein Chat gemacht, weil es einfach ein Dateitransferprotokoll ist und nicht diese Aufgabe erfüllen soll.
Das ist aber nicht der Grund, warum FTP als schlecht bezeichnet wird oder es von vornerein "verteufelt" wird. In so einem Fall ist es von Anfang an die Anwendung, die falsch ist.

Und wie Du schon ganz richtig gesagt hast, ändert das aber trotzdem nichts an der Tatsache, dass das Protokoll an sich einfach unsicher ist und jeder an der Verbindung rumfriemeln kann, was einer der eigentlichen Gründe ist.

lukekogv schrieb:

Aber bitte erklärt es anderen Nutzern dann auf diese Weise, anstatt einfach zu sagen, FTP sei 'schlecht'.

Das haben wir schon ziemlich oft gemacht. Und weil VincentTB durchaus hier öfters aktiv ist und mitliest, habe ich das in dem Fall nicht weiter ausgeführt. Zudem haben wir das dann in einem unabhängigen Teil vom VBP weiter diskutiert. Aber gut, da stimme ich Dir zu, das kann man ruhig dann jedes Mal im Post argumentativ ausführen.

Quadsoft schrieb:

Auch innerhalb eines eigenen Netzwerks ergibt es Sinn, nicht darauf zu hoffen, dass sich keiner (physisch) Zugang verschafft hat und jegliche kommunikation per MITM mithört.

That. Des Weiteren macht FTP nicht nur sicherheitstechnisch Probleme. Gerade auf mobilen Verbindungen und in Firmennetzwerken funktioniert es oft nicht richtig.

Mittlerweile sollte man stattdessen neben FTPS auch auf SFTP setzen. FTP ist eben nicht mehr zeitgemäß und es gibt heutzutage wesentlich bessere Alternativen. Aber wenn man's nutzen will, dann halt FTPS und das Zeugs zumindest verschlüsseln.

Grüße

@lukekogv
Ich finds klasse, dass du das hier so ausführlich erklärst, da habe ich auch wieder was gelernt, dies hier ist so ein Thread, auf den man dann vielleicht in Zukunft mal verlinken kann, weil er es echt gut und ausführlich zusammenfasst

Übrigens, um das ganze etwas abzurunden, hat der gute alte SemperVideo dazu mal ein schönes Video veröffentlicht, wo er auch zeigt, wie einfach es ist, mit z. B. Wireshark Benutzername/Passwort und die gesendeten Dateien auszulesen.

Dekar schrieb:

Ich fasse mich bei einer Frage kurz, ich suche eine alternative zu FTP bzw. TCP - Ich möchte von einem Server an einen Clienten Befehle senden und der Client soll je nach Befehl dementsprechend reagieren.

Die leidige FTP-Chat Geschichte habe ich erwähnt, da der erste Post letztendlich auch ein Konzept vorgestellt hat, für das FTP (in jeder Form) unsinning ist, unabhängig vom Sicherheitsaspekt. Wichtig ist in meinen Augen daher, dem OP diesen Sachverhalt eindeutig klar zu machen und ihm zudem klar zu machen, worüber er bei FTP und TCP letztendlich redet. Ich habe auch schon (nicht nur hier auf VBP) zahlreiche Eigenimplementierungen von TCP-basierten Protokollen gesehen, die ebenso krasse Sicherheitslücken enthielten. Daher ist mir diese Devise "FTP -> schlecht, TCP -> gut" zu einfach, mal abgesehen von der fehlenden inneren Logik.

Um auf die eigentliche Frage zurück zu kommen: Der Server kann (so ist seine Natur) keine Befehle an die Clients senden, außer diese haben sich zuvor mit ihm verbunden und halten diese Verbindung aufrecht. Wollte sich der Server mit den Clients verbinden, so würden diese quasi als Server agieren und bräuchten eine geöffnete Firewall. Das gilt erstmal protokollunabhängig.

lukekogv schrieb:

Daher ist mir diese Devise "FTP -> schlecht, TCP -> gut" zu einfach

Da hast Du natürlich recht. Ich wollte mich allerdings auch nur auf FTP beziehen und keine Aussage über TCP machen.

lukekogv schrieb:

mal abgesehen von der fehlenden inneren Logik.

Eben.

lukekogv schrieb:

Ich habe auch schon (nicht nur hier auf VBP) zahlreiche Eigenimplementierungen von TCP-basierten Protokollen gesehen, die ebenso krasse Sicherheitslücken enthielten.

Das ist natürlich die andere Sache. Nur, weil es dann auf TCP aufbaut, muss es ja nicht sicher sein und man kann Fehler machen. Sonst wäre FTP ja folglich auch sicher und man könnte da keine Fehler machen. Aber bei FTP sind eben schon zu viele Schwachstellen enthalten, was aber eben weniger daher kommt, dass die keinen Plan hatten, sondern dass es da einfach noch nicht die Form des Internets gab, wie heute.
Wenn Du allerdings auf TCP/UDP aufbaust, hast Du die Möglichkeit, es richtig zu machen.

Ich verstehe Deinen Standpunkt natürlich und finde es auch gut, dass Du hier den Zusammenhang und Unterschied zwischen FTP und TCP erklärt hast.

Grüße

VincentTB schrieb:

dazu mal ein schönes Video veröffentlicht

Ja Moment, "schön" würde ich das jetzt nicht unbedingt nennen, denn wenn ich mich nicht irre benutzt er da offensichtlich einen Hub und nicht Switch oder Router. Nur der Hub verteilt die Pakete an alle im Netz. Ein Switch oder Router macht das nicht und somit bekommen die anderen im Netz auch gar nix von der Kommunikation mit. Da müsste schon einen MITM Attacke gefahren werden. Das wird im Video aber gar nicht gesagt.