FTP unverschlüsselt - als Protokoll auf Anwendungsebene?

[samalbra]

Hallo,
ich weiß von FTP, dass es ein unverschlüsseltes Protokoll ist. Mir ist aber nicht klar, wieso man überhaupt bei Protokollen von Verschlüsselung spricht. Ein Protokoll legt Regeln fest, wie die verschiedenen Schichten ( z.B. im OSI-Modell) miteinander kommunizieren.
FTP betrifft dabei die Anwendungsschicht. Erst die nächste Schicht, die Darstellungsschicht, ist für die Verschlüsselung zuständig.
Wieso sagt man also, dass FTP unsicher ist, da es nicht verschlüsselt ist. Ist nicht jedes Protokoll dieser Schicht unverschlüsselt und die Verschlüsselung findet erst im nächsten Schritt, unabhängig von der Wahl des Protokolls, statt?

 

[d2boxSteve]

FTP ist eine Anwendung ... es basiert auf den Protikollen TCP und UDP.

Was Protokolle wie UDP unf TCP angeht hast du vollkommen Recht .... FTP ist aber auf der Anwenderschicht und da muss bereits verschlüsselt werden :=)

 

[Nilson]

Ein Protokoll legt Regeln fest, wie die verschiedenen Schichten ( z.B. im OSI-Modell) miteinander kommunizieren.

Wikipedia ist da andere Meinung:

Protokolle in der Telekommunikation und Informatik sind Regeln, welche das Format, den Inhalt, die Bedeutung und die Reihenfolge gesendeter Nachrichten zwischen verschiedenen Instanzen (der gleichen Schicht) festlegen

https://de.wikipedia.org/wiki/Protokoll#Telekommunikation_und_Informatik

Und ja, wie d2boxSteve richtig, anmerkt ist ftp (wie z.B. auch http, IMAP etc.) Anwendungssicht und damit auch für die Verschlüsselung (falls vorhanden) zuständig.

 

[Marco01_809]

Diese Schichten sind oberhalb Schicht 4 eh Unfug, weil die meisten Protokolle so weit durchspezifiziert sind, dass sie die Aufgaben der oberen 3 Schichten übernehmen.

Und FTP ist eben nicht nur die Anwendungsschicht. Es regelt ja auch die Sitzung (Schicht 5) und spezifiziert, wie die Daten übertragen werden (Schicht 6).
Wer sollte das auch sonst machen? In deinem Stack hast du unten ein Kabel, darüber werden Ethernet-Frames geschickt, darin enthalten sind IP-Pakete, darin wiederum sind TCP-Pakete und dadrin stehen schon direkt die Nachrichten die FTP-Client und -Server austauschen. Dazwischen kommt da nix, was Verschlüsselung machen kann. Also außer VPNs oder SSH-Tunnel oder so, aber die werden in den OSI-Schichten eh nicht berücksichtigt. Ergo muss der Aufbau einer verschlüsselten Verbindung als Teil von FTP spezifiziert sein. Da handeln Client und Server dann aus, dass sie unter die FTP-Kommunikation noch eine SSL/TLS-Verschlüsselung legen.

 

[Nilson]

@Marco01_809

bei TCP/IP heißt alles überhalb der Transportschicht Anwendungsschicht
https://de.wikipedia.org/wiki/Internetprotokollfamilie#TCP/IP-Referenzmodell

 

[Marco01_809]

Nilson: Da der OP explizit das OSI-Modell erwähnt und auch von der Darstellungsschicht spricht, die es im TCP/IP-Modell nicht gibt, war jenes Modell sicher nicht die Basis seiner Überlegungen.

 

[Nilson]

Ok, </Klugscheiss Mode>

 

[Hancock]

Die Frage ist immer, wie sicher soll es sein?

Keine Daten lesen? Dann reicht es, wenn die Daten vor dem Übertragen verschlüsselt werden.
​Keine Dateinamen lesen? Dann muss FTP verschlüsseln.
​Keine Metadaten lesen (Port/...)? Dann muss auch TCP verschlüsselt werden (IPSec z.B.)
Keine MAC-Adressen lesen? Dann muss auch die Transportschicht verschlüsselt werden (z.B. WLAN mit WPA2..., wobei ich mir da nicht sicher bin, ob man da die MAC z.B. doch noch rausbekommt).

​Das war nur das Lesen, jetzt die aktiven Methoden:

​Authentifizierung: Challenge-Response, da sonst ne Replay-Attacke möglich ist.
​Session-Hijack: Jede Nachricht muss signiert sein.

Da ein gutes Verschlüsselungsverfahren auch authentifiziert, ist die nahelegende Lösung beides zu tun. Die unterste Schicht, bei der das möglich ist, ist IP mit IPSec, aber das hat massiv Probleme mit NAT. TCP wäre die nächste Schicht, welche man verschlüsseln könnte. Was dem am nächsten kommt, ist TLS, welches eine TCP-Verbindung transparent verschlüsselt. TLS wird bei HTTP, FTP, IMAP, POP, SMTP, ... auch verwendet. TLS kommt, da es quasi ein Zwischenlayer ist, wunderbar mit NAT's und portblockierende Firewalls klar.

 

[samalbra]

Jetzt macht das alles Sinn. Habe mich wohl zu sehr an das OSI-Modell und die Anwendungsschicht geklammert. Vielen Dank euch allen

 

[Piktogramm]

Die Frage ist immer, wie sicher soll es sein?

Keine Daten lesen? Dann reicht es, wenn die Daten vor dem Übertragen verschlüsselt werden.
​[...]

Abgesehen davon, dass FTP auch die Zugangsdaten im Klartext raus schreit und eben nicht nur die Nutzdaten.

 

[Hancock]

Das fällt in dem Beispiel auch unter Dateinamen , sollten die Dateien verschlüsselt sein, bringen einem die Zugangsdaten nix (als passiver Beobachter).

 

[Piktogramm]

Man kommt aber wunderbar auf die via FTP erreichbaren Ordner ran und kann da fröhlich lesen, schreiben und modifizieren. Zudem haben viele Leute ja die Angewohnheit fröhlich Passwörter wiederzuverwenden was die Angriffsszenarien erweitert.

An sich kann man einen sehr einfachen Flowchart für alle Anwendungsgebiete machen:
Sollte ich plain FTP nutzen? --> NEIN!

Und Anstatt SFTP oder FTPs einzusetzen kann man auch oft auch gleich via SSH auf die gewünschte Kiste drauf

 

[Marco01_809]

SFTP ist doch SSH... irgendwas muss man ja zum Dateien übertragen benutzen. Und SFTP ist da die beste Wahl, da es den sicheren Kommunikationskanal über SSH inklusive der Authentifizierung nutzt.

 

[Piktogramm]

Jain, normalerweise sollte der Standard bei Dateioperationen scp sein (unixoide System, ich habe keine Ahnung was die SS-Implementierung von Windows 10 macht). Wobei die SCP Implementierungen oft auch SFTP verstehen.

Edit:
Und die Option sich Ordner von entfernten Rechner via sshfs einzubinden ist auch ganz nett.