FTP via VPN vs. SFTP
Tobias Dahlen
kann mir bitte jemand bzgl. der obigen Übertragungswege weiterhelfen.
Mir geht es darum welcher Übertragungsweg sicherer ist und warum.
Dabei soll nur der Übertragungsweg berücksichtigt werden, d.h. welche
Sicherheitsrisiken beim Sender/Empfänger lokal bestehen soll keine
Rolle spielen.
Hat bitte jemand ein paar erleuchtende Hinweise. Ich habe schon einige
Zeit gegoogelt, aber noch keine konkrete Antwort auf meine Frage
gefunden.
Danke.
Gruß
Tobias
Maik Zumstrull
> kann mir bitte jemand bzgl. der obigen Übertragungswege weiterhelfen.
> Mir geht es darum welcher Übertragungsweg sicherer ist und warum.
VPN ist in einem Punkt sicherer: Mit SFTP weiß ein lauschender
Angreifer immerhin noch, welche beiden Rechner gerade über welches
Protokoll miteinander reden; über VPN nur noch, dass irgendwer in den
beiden verbundenen LANs am kommunizieren ist und wie viele Daten dabei
fließen.
An den Inhalt der übertragenen Dateien kommt er bei beiden Varianten
nicht.
Bernd Eckenfels
> kann mir bitte jemand bzgl. der obigen Übertragungswege weiterhelfen.
> Mir geht es darum welcher Übertragungsweg sicherer ist und warum.
Die Unterschiede sind marginal und haengen von den Umstaenden ab (zu denen
du nichts geschrieben hast). Von daher ist die Lösung sicherer die du
einfacher benutzen kannst.
Gruss
Bernd
Thomas Dreher
Ich gehe jetzt mal davon aus, daß ssh file transfer protocol und nicht
secure file transfer protocol gemeint ist.
sftp an sich beinhaltet aber weder Verschlüsselung noch
Authentifizierung, dafür ist ssh zuständig.
Um deine Frage zu beantworten, müßte man wissen, in welcher Hinsicht der
Übertragungsweg "sicherer" sein soll. Wogegen?
Gruß
Thomas
Thomas Dreher
> Tobias Dahlen <tobias...@gmx.de> wrote:
>
>> kann mir bitte jemand bzgl. der obigen Übertragungswege weiterhelfen.
>> Mir geht es darum welcher Übertragungsweg sicherer ist und warum.
>
> VPN ist in einem Punkt sicherer: Mit SFTP weiß ein lauschender
> Angreifer immerhin noch, welche beiden Rechner gerade über welches
> Protokoll miteinander reden;
Das aber nur, wenn dazwischen nicht maskiert wird.
> über VPN nur noch, dass irgendwer in den
> beiden verbundenen LANs am kommunizieren ist und wie viele Daten dabei
> fließen.
Da kann durchaus auch ein einzelner Rechner angebunden sein, das kann
man in dieser Pauschalität nicht sagen.
> An den Inhalt der übertragenen Dateien kommt er bei beiden Varianten
> nicht.
Ack.
Gruß
Thomas
--
"Mord ist keine Lösung."
-- Oliver Schad <o.s...@web.de> in de.alt.sysadmin.recovery
Maik Zumstrull
> >> kann mir bitte jemand bzgl. der obigen Übertragungswege
> >> weiterhelfen. Mir geht es darum welcher Übertragungsweg sicherer
> >> ist und warum.
> >
> > VPN ist in einem Punkt sicherer: Mit SFTP weiß ein lauschender
> > Angreifer immerhin noch, welche beiden Rechner gerade über welches
> > Protokoll miteinander reden;
>
> Das aber nur, wenn dazwischen nicht maskiert wird.
Jein. Viele NAT-Lösungen maskieren so, dass man noch mit ziemlich hoher
Treffsicherheit erraten kann, wie viele Rechner dahinter hängen und
welche TCP-Verbindung zu welchem Rechner gehört. (Wenn man das Argument
zulässt, muss man aber natürlich auch einbeziehen, dass es VPN-Lösungen
mit ähnlichen Fehlern geben wird.)
> > über VPN nur noch, dass irgendwer in den
> > beiden verbundenen LANs am kommunizieren ist und wie viele Daten
> > dabei fließen.
>
> Da kann durchaus auch ein einzelner Rechner angebunden sein,
Ja, natürlich -- das wird der Angreifer durch Schnüffeln an der
Verbindung aber nicht feststellen können, wenn IPSec korrekt eingesetzt
wird.
Thomas Dreher
> Thomas Dreher <vaga...@linuxsumpf.de> wrote:
>
>> >> kann mir bitte jemand bzgl. der obigen Übertragungswege
>> >> weiterhelfen. Mir geht es darum welcher Übertragungsweg sicherer
>> >> ist und warum.
>> >
>> > VPN ist in einem Punkt sicherer: Mit SFTP weiß ein lauschender
>> > Angreifer immerhin noch, welche beiden Rechner gerade über welches
>> > Protokoll miteinander reden;
>>
>> Das aber nur, wenn dazwischen nicht maskiert wird.
>
> Jein. Viele NAT-Lösungen maskieren so, dass man noch mit ziemlich hoher
> Treffsicherheit erraten kann, wie viele Rechner dahinter hängen und
> welche TCP-Verbindung zu welchem Rechner gehört. (Wenn man das Argument
> zulässt, muss man aber natürlich auch einbeziehen, dass es VPN-Lösungen
> mit ähnlichen Fehlern geben wird.)
Rein interessehalber - gibt es bereits irgendwelche Arbeiten oder Tests,
die dieses Thema behandeln? Wirklich konkrete Angaben, wie der Link von
Lutz, in dem DNS-untaugliche SOHO-Router mit Testergebnissen genannt
werden, sind leider ziemlich rar.
>> > über VPN nur noch, dass irgendwer in den
>> > beiden verbundenen LANs am kommunizieren ist und wie viele Daten
>> > dabei fließen.
>>
>> Da kann durchaus auch ein einzelner Rechner angebunden sein,
>
> Ja, natürlich -- das wird der Angreifer durch Schnüffeln an der
> Verbindung aber nicht feststellen können, wenn IPSec korrekt eingesetzt
> wird.
Stimmt. Er sieht da nur das Gateway, die Header der Pakete liegen ja
schon im Tunnel.
Maik Zumstrull
> > Jein. Viele NAT-Lösungen maskieren so, dass man noch mit ziemlich
> > hoher Treffsicherheit erraten kann, wie viele Rechner dahinter
> > hängen und welche TCP-Verbindung zu welchem Rechner gehört.
> Rein interessehalber - gibt es bereits irgendwelche Arbeiten oder
> Tests, die dieses Thema behandeln?
Eine der ersten ist A Technique for Counting NATted Hosts von Steven M.
Bellovin. Andere sollten mindestens über Referenzen zu finden sein.
Tobias Dahlen
>Tobias Dahlen <tobias...@gmx.de> writes:
>
>> Hallo,
>>
>> kann mir bitte jemand bzgl. der obigen Übertragungswege weiterhelfen.
>> Mir geht es darum welcher Übertragungsweg sicherer ist und warum.
>> Dabei soll nur der Übertragungsweg berücksichtigt werden, d.h. welche
>> Sicherheitsrisiken beim Sender/Empfänger lokal bestehen soll keine
>> Rolle spielen.
>>
>> Hat bitte jemand ein paar erleuchtende Hinweise. Ich habe schon einige
>> Zeit gegoogelt, aber noch keine konkrete Antwort auf meine Frage
>> gefunden.
>
>Ich gehe jetzt mal davon aus, daß ssh file transfer protocol und nicht
>secure file transfer protocol gemeint ist.
Das ist richtig.
>sftp an sich beinhaltet aber weder Verschlüsselung noch
>Authentifizierung, dafür ist ssh zuständig.
Da hast Du natürlich Recht. SFTP wird ja üblicherweise in Kombination
mit SSH eingesetzt, an diese Variante habe ich gedacht.
>Um deine Frage zu beantworten, müßte man wissen, in welcher Hinsicht der
>Übertragungsweg "sicherer" sein soll. Wogegen?
Die zu übertragenden Dateninhalte dürfen nicht von dritten
eingesehen/entschlüsselt werden können. Zudem muss der Absender
erkennen können, wenn bei der Übertragung ein Fehler aufgetreten ist,
der dazu führte, dass die Daten nicht beim Empfänger angekommen sind.
Gruß
Tobias
Tobias Dahlen
Ich hole die Daten von einem SFTP-Server ab, der in der DMZ steht, das
steht bereits fest. Die eigentliche Kommunikation, um die es mir geht,
ist die zwischen den Absendern und dem Empfänger (also der
SFTP-Server, von dem ich die Daten abhole).
Dass die Unterschiede marginal sind, hilft mir schonmal weiter. Ich
werde nur gelegentlich mit solchen Aussagen konfrontiert, dass SFTP zu
unsicher sei, da ja kein verschlüsselter Tunnel zwischen zwei
festgelegten Kommunikationspartnern aufgebaut wird. Diese Begründung
konnte ich bisher nicht nachvollziehen.
Gruß
Tobias
Bernd Eckenfels
> Dass die Unterschiede marginal sind, hilft mir schonmal weiter. Ich
> werde nur gelegentlich mit solchen Aussagen konfrontiert, dass SFTP zu
> unsicher sei, da ja kein verschlüsselter Tunnel zwischen zwei
> festgelegten Kommunikationspartnern aufgebaut wird. Diese Begründung
> konnte ich bisher nicht nachvollziehen.
Beide sind Transport-Verschluesselung. Also die Daten liegen vor/nach dem
Transport unverschluesselt vor, und die Transportsicherung kann nicht mehr
nachvollzogen werden (im Gegensatz zu Fileverschluesselung mit PKCS7/smime
oder PGP).
Im Falle von SFTP ist der Angriffsvektor eigentlich kleiner (nicht das
gesamte Partnernetz kann zugreifen, sondern nur der sftp client mit dem
richtigen key oder passwort.
So gesehen wuerde ich sftp als sicherer ansehen. Nachteilig ist die Resitenz
gegen DDOS angriffe. So nen TCP Port ist schneller lahmgelegt als nen VPN
Server (vorausgesetzt es ist ein vernuenftiger). Aber im Endeffekt kann man
natuerlich beides DOSen wenn man will.
Ein SFTP Server ist mit der oeffentlichen IP natuerlich mehr exponiert wenn
er nicht hinter einem VPN gate steht. aber wenn dort keine anderen Dienste
verfügbar sind: kein PRoblem.
Hier gibts noch zig andere Pro und Contra Argumente, das kommt wie gesagt
sehr auf das genaue Umfeld an.
Gruss
Bernd
Juergen P. Meier
FTPS meinst du vermutlich, oder? SFTP ist die ftp-aehnliche
cp-over-SSH Implementierung von SSH.
Bei FTPS geht kein NAT. IPSEC-VPN hingegen unterstuetzt NAT.
Juergen
Juergen P. Meier
>
> Im Falle von SFTP ist der Angriffsvektor eigentlich kleiner (nicht das
> gesamte Partnernetz kann zugreifen, sondern nur der sftp client mit dem
> richtigen key oder passwort.
Falsch. SSH Implementierungen von SFTP sind nur schwer gegen local
privilege escalation exploits abzusichern.
> So gesehen wuerde ich sftp als sicherer ansehen. Nachteilig ist die Resitenz
> gegen DDOS angriffe. So nen TCP Port ist schneller lahmgelegt als nen VPN
> Server (vorausgesetzt es ist ein vernuenftiger). Aber im Endeffekt kann man
> natuerlich beides DOSen wenn man will.
Das halte ich fuer nicht relevant. Ein VPN ist nicht schwerer DoS-bar
als ein TCP Server. IMO sogar leichter.
> Ein SFTP Server ist mit der oeffentlichen IP natuerlich mehr exponiert wenn
> er nicht hinter einem VPN gate steht. aber wenn dort keine anderen Dienste
> verfügbar sind: kein PRoblem.
Vorallem wenn die SSH-Implementierung Loecher hat, oder der Kernel des
OS, auf dem sie laeuft lokale Loecher hat.
> Hier gibts noch zig andere Pro und Contra Argumente, das kommt wie gesagt
> sehr auf das genaue Umfeld an.
ACK.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
> Die zu übertragenden Dateninhalte dürfen nicht von dritten
> eingesehen/entschlüsselt werden können. Zudem muss der Absender
> erkennen können, wenn bei der Übertragung ein Fehler aufgetreten ist,
> der dazu führte, dass die Daten nicht beim Empfänger angekommen sind.
Das erlauben alle Varianten:
FTP ueber VPN, SCP/SFTP, und FTPS.
Juergen Ilse
Juergen P. Meier <nospa...@jors.net> wrote:
> FTPS meinst du vermutlich, oder? SFTP ist die ftp-aehnliche
> cp-over-SSH Implementierung von SSH.
> Bei FTPS geht kein NAT.
Das kommt darauf an. Von FTPS gibt es drei verschiedene Varianten (die
vierte waere schlicht unverschluesseltes FTP): Verschluesselter Daten-
kanal und unverschluesselter Kontrollkanal, unverschluesselter Daten-
kanal und verschluesselter Kontrollkanal und sowohl Daten- als auch
Kontrollkanal verschluesselt. Bei verschluesseltem Kontrollkanal ist
mit PAT nichts mehr zu wollen, bei der Variante mit unverschluesseltem
Kontrollkanal waere AFAIK NAT und PAT noch moeglich. Eigentlich wuerde
man (wenn man auf moeglichst hohe Sicherheit Wert legt) wohl die Vari-
ante bevorzuegen, bei der alles verschluesselt ist, und fuer die hast
du recht ...
> IPSEC-VPN hingegen unterstuetzt NAT.
Was genau meinst du damit? Du kannst mittels NAT-Traversal (letztens
hatte ich den RFC erst herausgesucht, auch wenn ich jetzt die Nummer
nicht mehr weiss: anscheinend ist es vom Status "IETF-Draft" zum
Status "proposed Standard" geworden) ein IPSEC-VPN durch NAT hindurch-
bekommen, und du kannst natuerlich *hinter* jedem VPN-Endpunkt noch
natten. Was genau soll mit IPSEC-VPN im Zusammenhang mit NAT prinzipiell
nicht gehen? Wenn man sich beim IPSEC-VPN allerdings auf AH beschraenken
will, haettest du recht, denn das bekommt man auch durch NATT nicht
hindurch ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Juergen P. Meier
>> Bei FTPS geht kein NAT.
>
> Das kommt darauf an. Von FTPS gibt es drei verschiedene Varianten (die
> vierte waere schlicht unverschluesseltes FTP): Verschluesselter Daten-
> kanal und unverschluesselter Kontrollkanal, unverschluesselter Daten-
> kanal und verschluesselter Kontrollkanal und sowohl Daten- als auch
> Kontrollkanal verschluesselt. Bei verschluesseltem Kontrollkanal ist
> mit PAT nichts mehr zu wollen, bei der Variante mit unverschluesseltem
> Kontrollkanal waere AFAIK NAT und PAT noch moeglich. Eigentlich wuerde
> man (wenn man auf moeglichst hohe Sicherheit Wert legt) wohl die Vari-
> ante bevorzuegen, bei der alles verschluesselt ist, und fuer die hast
> du recht ...
AUTH TLS (RFC 2228) als Variante von "verschluesseltem FTP" zu bezeichnen
halte ich fuer falsch. Da werden lediglich Logindaten verschluesselt.
Bleiben die beiden Varianten RFC 4217 (Vollverschluesselung gemaess
2228) und FTP via SSL/TLS (kein Standard, verbreitete Implementierung).
beide unterstuetzen prinzipiell kein NAT (getrennte TCP Kanaele fuer
Steuerung und Daten, beide jeweils verschluesselt, bei der ersten
Variante ist der Steuerkanal ueber Port 21 bei der zweiten idR. ueber
Port 990 aufgebaut, bei der ersten ist TLS explizit ausgehandelt, bei
der zweiten implizit).
>> IPSEC-VPN hingegen unterstuetzt NAT.
>
> Was genau meinst du damit? Du kannst mittels NAT-Traversal (letztens
Fast alle realen Implementierungen, genauer: alle Praxisrelevanten,
von IPSEC-VPN beherrschen mindestens eine Form von NAT-Traversal.
Viele sogar die von der IETF im Standardisierungsprozess befindliche
NAT-T.
> hatte ich den RFC erst herausgesucht, auch wenn ich jetzt die Nummer
> nicht mehr weiss: anscheinend ist es vom Status "IETF-Draft" zum
> Status "proposed Standard" geworden) ein IPSEC-VPN durch NAT hindurch-
> bekommen, und du kannst natuerlich *hinter* jedem VPN-Endpunkt noch
> natten. Was genau soll mit IPSEC-VPN im Zusammenhang mit NAT prinzipiell
> nicht gehen? Wenn man sich beim IPSEC-VPN allerdings auf AH beschraenken
Was fragst du mich das? Hab ich irgendwo behauptet, dass da was
prinzipiell nicht gehen wuerde?
> will, haettest du recht, denn das bekommt man auch durch NATT nicht
> hindurch ...
Hier geht es nicht um AH.
Juergen Ilse
Juergen P. Meier <nospa...@jors.net> wrote:
> Juergen Ilse <il...@usenet-verwaltung.de>:
>>> IPSEC-VPN hingegen unterstuetzt NAT.
>> Was genau meinst du damit? Du kannst mittels NAT-Traversal (letztens
> Fast alle realen Implementierungen, genauer: alle Praxisrelevanten,
> von IPSEC-VPN beherrschen mindestens eine Form von NAT-Traversal.
> Viele sogar die von der IETF im Standardisierungsprozess befindliche
> NAT-T.
Sorry, irgendwie hatte ich beim lesen des Beitrags ein nicht vorhandenes
"nicht" in deinen Satz "hineinhalluziniert" ...
Bernd Eckenfels
> privilege escalation exploits abzusichern.
Welches privileg soll das sein? (mein sshd ist ein java programm und laeuft
als user "b2bftp" :)
Gruss
Bernd
Bernd Eckenfels
FTPS ist FTP mit SSL
> SFTP ist die ftp-aehnliche
> cp-over-SSH Implementierung von SSH.
Aber nicht scp. SFTP geht auch problemlos bei NAT.
Gruss
Bernd
Bernd Eckenfels
> 2228) und FTP via SSL/TLS (kein Standard, verbreitete Implementierung).
> beide unterstuetzen prinzipiell kein NAT (getrennte TCP Kanaele fuer
> Steuerung und Daten, beide jeweils verschluesselt, bei der ersten
> Variante ist der Steuerkanal ueber Port 21 bei der zweiten idR. ueber
> Port 990 aufgebaut, bei der ersten ist TLS explizit ausgehandelt, bei
> der zweiten implizit).
Auf welcher Seite ist das NAT/PAT und reden wir von passiv oder aktiv?
Gruss
Bernd
Bernd Eckenfels
FTPS ist FTP mit SSL (irgendeine Art *g*)
> SFTP ist die ftp-aehnliche
> cp-over-SSH Implementierung von SSH.
Aber nicht scp. ssh's SFTP geht auch problemlos bei NAT - wuerde ich
jederzeit einem TLS faehigen ftpd vorziehen.
Gruss
Bernd
Tobias Dahlen
>Tobias Dahlen <tobias...@gmx.de>:
>> kann mir bitte jemand bzgl. der obigen Übertragungswege weiterhelfen.
>> Mir geht es darum welcher Übertragungsweg sicherer ist und warum.
>> Dabei soll nur der Übertragungsweg berücksichtigt werden, d.h. welche
>> Sicherheitsrisiken beim Sender/Empfänger lokal bestehen soll keine
>> Rolle spielen.
>>
>> Hat bitte jemand ein paar erleuchtende Hinweise. Ich habe schon einige
>> Zeit gegoogelt, aber noch keine konkrete Antwort auf meine Frage
>> gefunden.
>
>FTPS meinst du vermutlich, oder? SFTP ist die ftp-aehnliche
>cp-over-SSH Implementierung von SSH.
Nee, ich meinte schon SFTP, also SSH File Transfer Protocol. Und
dieses soll auch in Kombination mit SSH eingesetzt werden.
Gruß
Tobias
Richard W. Könning
>Juergen Ilse <il...@usenet-verwaltung.de>:
>>> Bei FTPS geht kein NAT.
>>
>> Das kommt darauf an. Von FTPS gibt es drei verschiedene Varianten (die
>> vierte waere schlicht unverschluesseltes FTP): Verschluesselter Daten-
>> kanal und unverschluesselter Kontrollkanal, unverschluesselter Daten-
>> kanal und verschluesselter Kontrollkanal und sowohl Daten- als auch
>> Kontrollkanal verschluesselt. Bei verschluesseltem Kontrollkanal ist
>> mit PAT nichts mehr zu wollen, bei der Variante mit unverschluesseltem
>> Kontrollkanal waere AFAIK NAT und PAT noch moeglich. Eigentlich wuerde
>> man (wenn man auf moeglichst hohe Sicherheit Wert legt) wohl die Vari-
>> ante bevorzuegen, bei der alles verschluesselt ist, und fuer die hast
>> du recht ...
>
>AUTH TLS (RFC 2228) als Variante von "verschluesseltem FTP" zu bezeichnen
>halte ich fuer falsch. Da werden lediglich Logindaten verschluesselt.
Es wird der Kontrollkanal verschlüsselt (wenn man dies nicht wieder
per CCC-Kommando aufhebt). Wieso soll jemand mehr verschlüsseln, wenn
es ihm nur um die Geheimhaltung der Login-Daten, nicht aber der
transferierten Daten geht?
>Bleiben die beiden Varianten RFC 4217 (Vollverschluesselung gemaess
RFC 4217 ist eine Implementierung von RFC 2228 mit Hilfe von
SSL/TLS...
>2228) und FTP via SSL/TLS (kein Standard, verbreitete Implementierung).
und erlaubt alle drei von Juergen (Ilse) genannten Varianten (genauer
gesagt, die Verschlüsselung des Kontrollkanals kann nach dem Transfer
des Passworts wieder per CCC-Kommando aufgehoben werden, wobei dieses
Feature iirc erst in einer der späteren Drafts von RFC 4217 eingeführt
wurde).
>beide unterstuetzen prinzipiell kein NAT (getrennte TCP Kanaele fuer
>Steuerung und Daten, beide jeweils verschluesselt, bei der ersten
>Variante ist der Steuerkanal ueber Port 21 bei der zweiten idR. ueber
>Port 990 aufgebaut, bei der ersten ist TLS explizit ausgehandelt, bei
>der zweiten implizit).
Das, was Du als "FTP via SSL/TLS" bezeichnest, unterscheidet sich von
dem FTP via SSL/TLS gemäß RFC 4217 nur durch die Aushandlung, bei
ersterem findet ein implizites Aushandeln anhand der Portnummer statt,
bei letzterem ein explizites Aushandeln per Kommandos.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Juergen P. Meier
Ertugrul Söylemez
Bernd Eckenfels <ec...@lina.inka.de> wrote:
> > SFTP ist die ftp-aehnliche
> > cp-over-SSH Implementierung von SSH.
>
> Aber nicht scp. ssh's SFTP geht auch problemlos bei NAT - wuerde ich
> jederzeit einem TLS faehigen ftpd vorziehen.
So pauschal kann man das leider nicht sagen, da SSH eben immer noch die
"Secure Shell" ist. Das bedeutet, dass du dem Benutzer evtl. mehr
erlaubst, als du ihm erlauben willst.
Es sollte einfach mal ein neues FTP geben. Alle folgen dem
Web 2.0-Hype. Es gibt die Homepage 2.0, das Büro 2.0, die Memoiren 2.0,
und wir laden immer noch alles per FTP 1.0 hoch. Da stimmt doch
grundsätzlich etwas nicht.
Andererseits haben wir uns so sehr an die fast schon jämmerlichen
Workarounds gewöhnt, dass wir gar nichts Neues mehr wollen. Es müsste
schon eine Internet-Revolution geben, damit sich da etwas tut. Meiner
Meinung nach verläuft die Entwicklung von neuen Technologien viel zu
langsam, obwohl es wirklich nicht schwer ist, FTP durch etwas Sichereres
und Flexibleres zu ersetzen, denn FTP ist bereits der schlimmstmögliche
Fall.
MfG,
Ertugrul.
Richard W. Könning
>On Wed, 27 Feb 2008 21:45:57 +0000 (UTC)
>Bernd Eckenfels <ec...@lina.inka.de> wrote:
>
>> > SFTP ist die ftp-aehnliche
>> > cp-over-SSH Implementierung von SSH.
>>
>> Aber nicht scp. ssh's SFTP geht auch problemlos bei NAT - wuerde ich
>> jederzeit einem TLS faehigen ftpd vorziehen.
>
>So pauschal kann man das leider nicht sagen, da SSH eben immer noch die
>"Secure Shell" ist. Das bedeutet, dass du dem Benutzer evtl. mehr
>erlaubst, als du ihm erlauben willst.
>
>Es sollte einfach mal ein neues FTP geben. Alle folgen dem
Es gibt imho genügend FT-Protokolle, da braucht man nicht noch mehr.
>Web 2.0-Hype. Es gibt die Homepage 2.0, das Büro 2.0, die Memoiren 2.0,
>und wir laden immer noch alles per FTP 1.0 hoch. Da stimmt doch
>grundsätzlich etwas nicht.
>
>Andererseits haben wir uns so sehr an die fast schon jämmerlichen
>Workarounds gewöhnt, dass wir gar nichts Neues mehr wollen. Es müsste
>schon eine Internet-Revolution geben, damit sich da etwas tut. Meiner
>Meinung nach verläuft die Entwicklung von neuen Technologien viel zu
>langsam, obwohl es wirklich nicht schwer ist, FTP durch etwas Sichereres
>und Flexibleres zu ersetzen, denn FTP ist bereits der schlimmstmögliche
>Fall.
Wo ist Dein Problem mit FTP? (btw, welchem? FTP gemäß RFC 959 oder
SFTP aus der SSH-Protokollsuite?)
Ertugrul Söylemez
Richard W. Könning <Richard....@t-online.de> wrote:
> > Es sollte einfach mal ein neues FTP geben. Alle folgen dem
>
> Es gibt imho genügend FT-Protokolle, da braucht man nicht noch mehr.
Ja, aber es sollte doch einfach mal _das_ FTP der Neuzeit geben. Wir
haben ja schließlich auch _das_ Hypertext-Protokoll und _das_
Shell-Protokoll. Es muss ein richtig gutes Dateitransfer-Protokoll
geben, das flexibel und zufriedenstellend für möglichst alle Szenarien
ist.
> > Web 2.0-Hype. Es gibt die Homepage 2.0, das Büro 2.0, die Memoiren
> > 2.0, und wir laden immer noch alles per FTP 1.0 hoch. Da stimmt
> > doch grundsätzlich etwas nicht.
> >
> > Andererseits haben wir uns so sehr an die fast schon jämmerlichen
> > Workarounds gewöhnt, dass wir gar nichts Neues mehr wollen. Es
> > müsste schon eine Internet-Revolution geben, damit sich da etwas
> > tut. Meiner Meinung nach verläuft die Entwicklung von neuen
> > Technologien viel zu langsam, obwohl es wirklich nicht schwer ist,
> > FTP durch etwas Sichereres und Flexibleres zu ersetzen, denn FTP ist
> > bereits der schlimmstmögliche Fall.
>
> Wo ist Dein Problem mit FTP? (btw, welchem? FTP gemäß RFC 959 oder
> SFTP aus der SSH-Protokollsuite?)
Mein Problem mit FTP (aus RFC 959) ist Sicherheit und Flexibilität, mein
Problem mit SFTP (aus der SSH-Suite) ist, dass es sehr leicht ist, dem
Nutzer versehentlich mehr Privilegien zu geben als er braucht.
Es gibt für einige Zwecke zu viele Protokolle. Einer davon ist
Dateiübertragung. Es sollte ein gutes Protokoll geben, das jeder
implementiert. So wie FTP, nur sicher und flexibel.
Sebastian G.
> Ja, aber es sollte doch einfach mal _das_ FTP der Neuzeit geben. Wir
> haben ja schließlich auch _das_ Hypertext-Protokoll und _das_
> Shell-Protokoll. Es muss ein richtig gutes Dateitransfer-Protokoll
> geben, das flexibel und zufriedenstellend für möglichst alle Szenarien
> ist.
Also FTP.
> Mein Problem mit FTP (aus RFC 959) ist Sicherheit und Flexibilität,
Sicherheit ist Aufgabe von Layer 6, da gibt's SSL und TLS.
Wo genau mangelt es dir bei FTP and Flexibilitaet?
> Es gibt für einige Zwecke zu viele Protokolle. Einer davon ist
> Dateiübertragung. Es sollte ein gutes Protokoll geben, das jeder
> implementiert. So wie FTP, nur sicher und flexibel.
SMB? Fehlt allerdings noch ein brauchbarer Client fuer Windows.
Ertugrul Söylemez
"Sebastian G." <se...@seppig.de> wrote:
> > Ja, aber es sollte doch einfach mal _das_ FTP der Neuzeit geben.
> > Wir haben ja schließlich auch _das_ Hypertext-Protokoll und _das_
> > Shell-Protokoll. Es muss ein richtig gutes Dateitransfer-Protokoll
> > geben, das flexibel und zufriedenstellend für möglichst alle
> > Szenarien ist.
>
> Also FTP.
>
> > Mein Problem mit FTP (aus RFC 959) ist Sicherheit und Flexibilität,
>
> Sicherheit ist Aufgabe von Layer 6, da gibt's SSL und TLS.
> Wo genau mangelt es dir bei FTP and Flexibilitaet?
Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung selbst
lässt sich nicht, basierend auf der Authentifizierung, absichern.
Flexibilität: FTP ist nicht erweiterbar. Der separate Datenkanal wird
einem aufgezwungen.
FTP geht bedingungslos davon aus, dass sich die Kommunikationspartner
nicht kennen und eigentlich auch nichts voneinander wissen wollen. Der
Client will sich nur schnell etwas herunterladen oder kurz eine Datei
hochladen. Dafür haben wir HTTP.
Außerdem wirkt FTP ein Bisschen wie ein extrem mieser Shell-Verschnitt.
Man kann den Inhalt des aktuellen Verzeichnisses abrufen, aber es gibt
keinen Standard, der das Format dieser Liste vorschreibt. Diese Liste
ist keine Kontrollkommunikation, sondern eine Datenkommunikation
(unnötig langsam), und so weiter und so fort.
> > Es gibt für einige Zwecke zu viele Protokolle. Einer davon ist
> > Dateiübertragung. Es sollte ein gutes Protokoll geben, das jeder
> > implementiert. So wie FTP, nur sicher und flexibel.
>
> SMB? Fehlt allerdings noch ein brauchbarer Client fuer Windows.
Ich kann nichts über die Sicherheit von SMB sagen. Die
Protokollunterlagen liegen derzeit noch bei Microsoft und bei einer Hand
voll Samba-Programmierern. Laut heise will Microsoft zwar seinen Kurs
in Richtung Offenheit wechseln, aber SMB bleibt dennoch ein
nichtstandardisiertes Microsoft-Protokoll.
Andreas Beck
> Ertugrul Söylemez wrote:
>> Ja, aber es sollte doch einfach mal _das_ FTP der Neuzeit geben. Wir
>> haben ja schließlich auch _das_ Hypertext-Protokoll und _das_
>> Shell-Protokoll. Es muss ein richtig gutes Dateitransfer-Protokoll
>> geben, das flexibel und zufriedenstellend für möglichst alle Szenarien
>> ist.
> Also FTP.
FTP saugt in NAT-Szenarien Meteoritenschwärme durch Strohhalme.
>> Mein Problem mit FTP (aus RFC 959) ist Sicherheit und Flexibilität,
> Sicherheit ist Aufgabe von Layer 6, da gibt's SSL und TLS.
> Wo genau mangelt es dir bei FTP and Flexibilitaet?
Ack. FTP ist flexibel. IMHO zu.
Kein Mensch braucht sowas wie FXP (von 3. Server ausgelöste Transfers
zwischen zwei anderen), die Unterscheidung active/passive tut weh, etc.
>> Es gibt für einige Zwecke zu viele Protokolle. Einer davon ist
>> Dateiübertragung. Es sollte ein gutes Protokoll geben, das jeder
>> implementiert. So wie FTP, nur sicher und flexibel.
> SMB? Fehlt allerdings noch ein brauchbarer Client fuer Windows.
So schlimm ist er nu auch nicht.
Außerdem gäbe es noch HTTP put.
Läuft mit SSL, wenn man will, braucht nur eine Verbindung, kann Ranges
übertragen, etc. pp.
Oder eben sftp. Jetzt mal von der Implementierung abgesehen.
Oder eben ein beliebiges halbwegs sicheres remote-fs.
CU, Andy
Juergen P. Meier
> On Fri, 29 Feb 2008 12:08:48 +0100
>
> schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
TLS/SSL und anderen sichere Auth-Methoden gibt es schon laenger fuer
FTP.
> Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung selbst
> lässt sich nicht, basierend auf der Authentifizierung, absichern.
Hae?
> Flexibilität: FTP ist nicht erweiterbar.
Das ist Grober Unsinn.
> Der separate Datenkanal wird
> einem aufgezwungen.
Das ist das einzig Wahre in deinem FUD-Haufen.
> FTP geht bedingungslos davon aus, dass sich die Kommunikationspartner
> nicht kennen und eigentlich auch nichts voneinander wissen wollen. Der
> Client will sich nur schnell etwas herunterladen oder kurz eine Datei
> hochladen. Dafür haben wir HTTP.
Unsinn.
> Außerdem wirkt FTP ein Bisschen wie ein extrem mieser Shell-Verschnitt.
> Man kann den Inhalt des aktuellen Verzeichnisses abrufen, aber es gibt
> keinen Standard, der das Format dieser Liste vorschreibt. Diese Liste
> ist keine Kontrollkommunikation, sondern eine Datenkommunikation
> (unnötig langsam), und so weiter und so fort.
Das ist ein Feature, kein Bug.
Ein so nuetzliches solches, dass FTP die letzten 35 Jahre ueberlebt
hat.
> Ich kann nichts über die Sicherheit von SMB sagen. Die
Und ich kann nichts gutes darueber sagen.
> Protokollunterlagen liegen derzeit noch bei Microsoft und bei einer Hand
> voll Samba-Programmierern. Laut heise will Microsoft zwar seinen Kurs
> in Richtung Offenheit wechseln, aber SMB bleibt dennoch ein
> nichtstandardisiertes Microsoft-Protokoll.
Ack.
Ertugrul Söylemez
"Juergen P. Meier" <nospa...@jors.net> wrote:
> > On Fri, 29 Feb 2008 12:08:48 +0100
> >
> > Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
> > schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
>
> TLS/SSL und anderen sichere Auth-Methoden gibt es schon laenger fuer
> FTP.
Was passiert, wenn ich schlüsselbasierte Authentifizierung will? Kann
das FTP? Ich rede von FTP und du schwafelst etwas von TLS. So gesehen
kann ich auch Telnet mit TLS absichern. Ist Telnet deswegen gut?
> > Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung
> > selbst lässt sich nicht, basierend auf der Authentifizierung,
> > absichern.
>
> Hae?
Der Schlüssel wird normalerweise nicht aus der Luft gesaugt. Er wird
z.B. mit einem authentifizierten DH-Schlüsseltausch vereinbart. Das
Wort, auf das es hier ankommt, ist "authentifiziert".
> > Flexibilität: FTP ist nicht erweiterbar.
>
> Das ist Grober Unsinn.
Es ist ein extrem hässlicher Trend im Usenet, Aussagen völlig ohne
Begründung zu verneinen oder gar anzugreifen. Wenn ich mich irre, dann
korrigiere mich bitte. Mich nur darauf hinzuweisen, dass ich mich irre,
ist -- ähnlich wie Metafragen -- in jeder Hinsicht kontraproduktiv.
> > Der separate Datenkanal wird einem aufgezwungen.
>
> Das ist das einzig Wahre in deinem FUD-Haufen.
Was heißt "FUD", und warum entspricht mein "Haufen" dieser Definition?
> > FTP geht bedingungslos davon aus, dass sich die Kommunikationspartner
> > nicht kennen und eigentlich auch nichts voneinander wissen wollen. Der
> > Client will sich nur schnell etwas herunterladen oder kurz eine Datei
> > hochladen. Dafür haben wir HTTP.
>
> Unsinn.
Begründe bitte.
> > Außerdem wirkt FTP ein Bisschen wie ein extrem mieser
> > Shell-Verschnitt. Man kann den Inhalt des aktuellen Verzeichnisses
> > abrufen, aber es gibt keinen Standard, der das Format dieser Liste
> > vorschreibt. Diese Liste ist keine Kontrollkommunikation, sondern
> > eine Datenkommunikation (unnötig langsam), und so weiter und so
> > fort.
>
> Das ist ein Feature, kein Bug.
>
> Ein so nuetzliches solches, dass FTP die letzten 35 Jahre ueberlebt
> hat.
Es war damals ein Feature, als man per Kommandozeile mit FTP gearbeitet
hat. Dieses "Feature" wurde im Laufe der Jahre so missverstanden, dass
es sich keine FTP-Serversoftware erlauben könnte, ein Dateilisting
anders darzustellen als von der breiten Masse diktatiert.
Nichts hätte dagegengesprochen, das Format des Dateilistings dennoch zu
standardisieren.
Sebastian G.
> On Fri, 29 Feb 2008 12:08:48 +0100
> "Sebastian G." <se...@seppig.de> wrote:
>
>>> Ja, aber es sollte doch einfach mal _das_ FTP der Neuzeit geben.
>>> Wir haben ja schließlich auch _das_ Hypertext-Protokoll und _das_
>>> Shell-Protokoll. Es muss ein richtig gutes Dateitransfer-Protokoll
>>> geben, das flexibel und zufriedenstellend für möglichst alle
>>> Szenarien ist.
>> Also FTP.
>>
>>> Mein Problem mit FTP (aus RFC 959) ist Sicherheit und Flexibilität,
>> Sicherheit ist Aufgabe von Layer 6, da gibt's SSL und TLS.
>> Wo genau mangelt es dir bei FTP and Flexibilitaet?
>
> Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
> schwäbisch sage würd, unter aller Sau.
Uebergabe von Nutzername und Passwort, also das, was so ziemlich an jeder
stelle verwendet wird. Challenge-Response gibt's auch.
> Flexibilität: FTP ist nicht erweiterbar. Der separate Datenkanal wird
> einem aufgezwungen.
Aha...
> FTP geht bedingungslos davon aus, dass sich die Kommunikationspartner
> nicht kennen und eigentlich auch nichts voneinander wissen wollen.
Was fuer ein Unsinn.
> Außerdem wirkt FTP ein Bisschen wie ein extrem mieser Shell-Verschnitt.
> Man kann den Inhalt des aktuellen Verzeichnisses abrufen, aber es gibt
> keinen Standard, der das Format dieser Liste vorschreibt.
Gut, es ist halt ein faktischen Standard,
> Diese Liste ist keine Kontrollkommunikation, sondern eine Datenkommunikation
> (unnötig langsam)
Huh? Eine kurze Kommunikation, die steuerrelevante Daten enthaelt, eben
nicht auch einen separaten Kanal abzwaelzen, sei langsam?
> Laut heise will Microsoft zwar seinen Kurs
> in Richtung Offenheit wechseln, aber SMB bleibt dennoch ein
> nichtstandardisiertes Microsoft-Protokoll.
http://www.tools.ietf.org/html/draft-heizer-cifs-v1-spec-00
http://www.tools.ietf.org/html/draft-leach-cifs-v1-spec-01
http://www.tools.ietf.org/html/draft-leach-cifs-browser-spec-00
Den ganzen Windows-spezifischen Kram fuer DCE-RPC und NetBT braucht man nicht.
Sebastian G.
> FTP saugt in NAT-Szenarien Meteoritenschwärme durch Strohhalme.
Stimmt. Und das ist jetzt nicht die Schuld von NAT, weil...
> Kein Mensch braucht sowas wie FXP (von 3. Server ausgelöste Transfers
> zwischen zwei anderen),
FXP ist kein Teil von standardkonformem FTP, sondern vielmehr ein Hack auf
der Basis kaputter Implementierungen.
> die Unterscheidung active/passive tut weh,
Logisch, sie ist unnoetig.
> Außerdem gäbe es noch HTTP put.
>
> Läuft mit SSL, wenn man will, braucht nur eine Verbindung, kann Ranges
> übertragen, etc. pp.
Und fuer jeden Range muss man den laufenden Transfer anhalten, 'nen Request
senden, Bestaetigung abwarten, und dann erst senden/empfangen. Genau das
gleiche Overhead-Problem hat FTP auch.
Deshalb erwaehnte ich ja SMB, weil das da sehr effizient vonstatten geht.
> Oder eben ein beliebiges halbwegs sicheres remote-fs.
Moechte man auch Windows abdecken (es ging darum, dass es mindestens so
verbreitet ist wie FTP), so bliebe einem da eigentlich nur SMB/CIFS oder NFS.
Sebastian G.
> On Fri, 29 Feb 2008 11:49:38 +0000 (UTC)
> "Juergen P. Meier" <nospa...@jors.net> wrote:
>
>>> On Fri, 29 Feb 2008 12:08:48 +0100
>>>
>>> Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
>>> schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
>> TLS/SSL und anderen sichere Auth-Methoden gibt es schon laenger fuer
>> FTP.
>
> Was passiert, wenn ich schlüsselbasierte Authentifizierung will? Kann
> das FTP?
Ja, kann es. Sowohl im Prolog als auch nachtraeglich via PROT P.
> Ich rede von FTP und du schwafelst etwas von TLS. So gesehen
> kann ich auch Telnet mit TLS absichern. Ist Telnet deswegen gut?
Telnet over TLS waere als SSH-Ersatz durchaus nicht uebel.
>>> Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung
>>> selbst lässt sich nicht, basierend auf der Authentifizierung,
>>> absichern.
>> Hae?
>
> Der Schlüssel wird normalerweise nicht aus der Luft gesaugt. Er wird
> z.B. mit einem authentifizierten DH-Schlüsseltausch vereinbart. Das
> Wort, auf das es hier ankommt, ist "authentifiziert".
Bei Implicit-SSL ist der Datenkanal genauso authentifiziert wie der
Steuerkanal beim Verbindungsaufbau, bei Explicit-SSL kannst du sogar eine
getrennte Authentifizierung verlangen.
>>> Flexibilität: FTP ist nicht erweiterbar.
>> Das ist Grober Unsinn.
>
> Es ist ein extrem hässlicher Trend im Usenet, Aussagen völlig ohne
> Begründung zu verneinen oder gar anzugreifen. Wenn ich mich irre, dann
> korrigiere mich bitte. Mich nur darauf hinzuweisen, dass ich mich irre,
> ist -- ähnlich wie Metafragen -- in jeder Hinsicht kontraproduktiv.
Der FTP-Steuerkanal basiert auf Befehlen. Man kann weitere Befehle
hinzufuegen, was schon mehrfach erfolgte.
>>> FTP geht bedingungslos davon aus, dass sich die Kommunikationspartner
>>> nicht kennen und eigentlich auch nichts voneinander wissen wollen. Der
>>> Client will sich nur schnell etwas herunterladen oder kurz eine Datei
>>> hochladen. Dafür haben wir HTTP.
>> Unsinn.
>
> Begründe bitte.
Deine Beschreibung impliziert offensichtlich statusfreie Protokolle, was auf
HTTP ja durchaus zutrifft; auf FTP allerdings nicht. Herrje, dort muss sich
der Nutzer im Prolog gar mit Nutzername und Passwort authentifizieren!
Juergen P. Meier
> On Fri, 29 Feb 2008 11:49:38 +0000 (UTC)
> "Juergen P. Meier" <nospa...@jors.net> wrote:
>
>> > On Fri, 29 Feb 2008 12:08:48 +0100
>> >
>> > Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
>> > schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
>>
>> TLS/SSL und anderen sichere Auth-Methoden gibt es schon laenger fuer
>> FTP.
>
> Was passiert, wenn ich schlüsselbasierte Authentifizierung will? Kann
> das FTP? Ich rede von FTP und du schwafelst etwas von TLS. So gesehen
Ja.
ftp -x ftp.example.org
Oder anderer Client:
ftp -z secure ftp.example.org
> kann ich auch Telnet mit TLS absichern. Ist Telnet deswegen gut?
telnet -x? Ja.
>> > Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung
>> > selbst lässt sich nicht, basierend auf der Authentifizierung,
>> > absichern.
>>
>> Hae?
>
> Der Schlüssel wird normalerweise nicht aus der Luft gesaugt. Er wird
> z.B. mit einem authentifizierten DH-Schlüsseltausch vereinbart. Das
> Wort, auf das es hier ankommt, ist "authentifiziert".
Ja und? Wiso sollte die Datenuebertragung nicht authentifiziert sein?
Oder verwechselst du hier die Authentifikation auf Anwendungsschicht
mit der auf Transportschicht?
>> > Flexibilität: FTP ist nicht erweiterbar.
>>
>> Das ist Grober Unsinn.
>
> Es ist ein extrem hässlicher Trend im Usenet, Aussagen völlig ohne
> Begründung zu verneinen oder gar anzugreifen. Wenn ich mich irre, dann
> korrigiere mich bitte. Mich nur darauf hinzuweisen, dass ich mich irre,
> ist -- ähnlich wie Metafragen -- in jeder Hinsicht kontraproduktiv.
FTP als "nicht erweiterbar" zu bezeichnen ist in etwa so, als ob du
Luft als nicht kompremierbar bezeichnen wuerdest.
Das ist so Absurd, dass es keiner Arugmentation mehr bedarf.
>> > Der separate Datenkanal wird einem aufgezwungen.
>>
>> Das ist das einzig Wahre in deinem FUD-Haufen.
>
> Was heißt "FUD", und warum entspricht mein "Haufen" dieser Definition?
Google koennte dir das erklaeren.
>> > FTP geht bedingungslos davon aus, dass sich die Kommunikationspartner
>> > nicht kennen und eigentlich auch nichts voneinander wissen wollen. Der
>> > Client will sich nur schnell etwas herunterladen oder kurz eine Datei
>> > hochladen. Dafür haben wir HTTP.
>>
>> Unsinn.
>
> Begründe bitte.
Dass FTP nicht bedingungslos davon ausgeht, dass sich
Kommunikationspartner nicht kennen?
Gerne:
FTP geht davon aus, dass sich die Kommunikationspartner kennen, mit
der Ausnahme anonymen bzw. authentiikationsfreien Zugangs. Letztes ist
praktisch nirgends mehr implementiert.
>> > Außerdem wirkt FTP ein Bisschen wie ein extrem mieser
>> > Shell-Verschnitt. Man kann den Inhalt des aktuellen Verzeichnisses
>> > abrufen, aber es gibt keinen Standard, der das Format dieser Liste
>> > vorschreibt. Diese Liste ist keine Kontrollkommunikation, sondern
>> > eine Datenkommunikation (unnötig langsam), und so weiter und so
>> > fort.
>>
>> Das ist ein Feature, kein Bug.
>>
>> Ein so nuetzliches solches, dass FTP die letzten 35 Jahre ueberlebt
>> hat.
>
> Es war damals ein Feature, als man per Kommandozeile mit FTP gearbeitet
> hat. Dieses "Feature" wurde im Laufe der Jahre so missverstanden, dass
> es sich keine FTP-Serversoftware erlauben könnte, ein Dateilisting
> anders darzustellen als von der breiten Masse diktatiert.
>
> Nichts hätte dagegengesprochen, das Format des Dateilistings dennoch zu
> standardisieren.
Mir duenkt du weist schlicht nicht, was FTP eigentlich ist, welche
Funktionalitaet es hat, wie es erweitert werden kann und was man alles
damit anstellen kann.
Du gehst von einem Spezialfall aus und reflektierst das unqualifiziert
auf das Protokoll. Das ist nicht sonderlich zielfuehrend.
Juergen P. Meier
> Und fuer jeden Range muss man den laufenden Transfer anhalten, 'nen Request
> senden, Bestaetigung abwarten, und dann erst senden/empfangen. Genau das
> gleiche Overhead-Problem hat FTP auch.
FTP kann out-of-band Steuerung.
>> Oder eben ein beliebiges halbwegs sicheres remote-fs.
>
> Moechte man auch Windows abdecken (es ging darum, dass es mindestens so
> verbreitet ist wie FTP), so bliebe einem da eigentlich nur SMB/CIFS oder NFS.
Was mich wundert ist, dass Mickeysoft nicht einfach seine RPC
Methoden in FTP eingebaut hat.
Ertugrul Söylemez
"Sebastian G." <se...@seppig.de> wrote:
> >>> Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
> >>> schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
> >>
> >> TLS/SSL und anderen sichere Auth-Methoden gibt es schon laenger
> >> fuer FTP.
> >
> > Was passiert, wenn ich schlüsselbasierte Authentifizierung will?
> > Kann das FTP?
>
> Ja, kann es. Sowohl im Prolog als auch nachtraeglich via PROT P.
Das FTP (entsprechend RFC 959) kann das nicht. Es gibt USER und es gibt
PASS. STARTTLS ist bereits eine Erweiterung, ebenso wie PROT.
> > Ich rede von FTP und du schwafelst etwas von TLS. So gesehen kann
> > ich auch Telnet mit TLS absichern. Ist Telnet deswegen gut?
>
> Telnet over TLS waere als SSH-Ersatz durchaus nicht uebel.
>
> [...]
>
> Bei Implicit-SSL ist der Datenkanal genauso authentifiziert wie der
> Steuerkanal beim Verbindungsaufbau, bei Explicit-SSL kannst du sogar
> eine getrennte Authentifizierung verlangen.
Deswegen ist Telnet aber nicht gut. Ihr schwafelt ständig von
Zusatzprotokollen und von Erweiterungen. Ich rede von FTP (bzw. hier
von Telnet). Das kann doch nicht so schwer zu begreifen sein ...
SSL und TLS können (oder sollten) nicht die Authentifizierung der
Anwendungsschicht übernehmen. Sie sollten den Host authentifizieren,
nicht den User. Bei Telnet oder FTP mit Passwort-Authentifizierung geht
das ja noch, aber ich will schlüsselbasierte Authentifizierung.
> >>> Flexibilität: FTP ist nicht erweiterbar.
> >>
> >> Das ist Grober Unsinn.
> >
> > Es ist ein extrem hässlicher Trend im Usenet, Aussagen völlig ohne
> > Begründung zu verneinen oder gar anzugreifen. Wenn ich mich irre,
> > dann korrigiere mich bitte. Mich nur darauf hinzuweisen, dass ich
> > mich irre, ist -- ähnlich wie Metafragen -- in jeder Hinsicht
> > kontraproduktiv.
>
> Der FTP-Steuerkanal basiert auf Befehlen. Man kann weitere Befehle
> hinzufuegen, was schon mehrfach erfolgte.
... und damit jedes mal den Standard brechen oder einschränken.
> >>> FTP geht bedingungslos davon aus, dass sich die
> >>> Kommunikationspartner nicht kennen und eigentlich auch nichts
> >>> voneinander wissen wollen. Der Client will sich nur schnell etwas
> >>> herunterladen oder kurz eine Datei hochladen. Dafür haben wir
> >>> HTTP.
> >>
> >> Unsinn.
> >
> > Begründe bitte.
>
> Deine Beschreibung impliziert offensichtlich statusfreie Protokolle,
> was auf HTTP ja durchaus zutrifft; auf FTP allerdings nicht. Herrje,
> dort muss sich der Nutzer im Prolog gar mit Nutzername und Passwort
> authentifizieren!
Nein, tut sie nicht. Für alles, was über das einfache Hochladen einer
Datei oder eines Verzeichnisses hinausgeht, ist FTP an sich einfach
unzureichend. Hätte ich denn sonst einen Grund, z.B. für Backups
Rsync/SSH gegenüber FTP vorzuziehen? Die Vorteile von Rsync liegen ja
wohl auf der Hand. Der Nachteile von FTP überwiegen weit den Nachteil
von Rsync/SSH, dass Shell-Zugriff nötig ist.
Ertugrul Söylemez
"Juergen P. Meier" <nospa...@jors.net> wrote:
> >>> Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung
> >>> selbst lässt sich nicht, basierend auf der Authentifizierung,
> >>> absichern.
> >>
> >> Hae?
> >
> > Der Schlüssel wird normalerweise nicht aus der Luft gesaugt. Er
> > wird z.B. mit einem authentifizierten DH-Schlüsseltausch vereinbart.
> > Das Wort, auf das es hier ankommt, ist "authentifiziert".
>
> Ja und? Wiso sollte die Datenuebertragung nicht authentifiziert sein?
> Oder verwechselst du hier die Authentifikation auf Anwendungsschicht
> mit der auf Transportschicht?
Nein, du gehst davon aus, dass eine SSL/TLS-Schale um FTP gelegt wird.
Davon gehe ich gerade nicht aus. Näheres dazu, siehe meine Antwort an
Sebastian.
> >>> Flexibilität: FTP ist nicht erweiterbar.
> >>
> >> Das ist Grober Unsinn.
> >
> > Es ist ein extrem hässlicher Trend im Usenet, Aussagen völlig ohne
> > Begründung zu verneinen oder gar anzugreifen. Wenn ich mich irre,
> > dann korrigiere mich bitte. Mich nur darauf hinzuweisen, dass ich
> > mich irre, ist -- ähnlich wie Metafragen -- in jeder Hinsicht
> > kontraproduktiv.
>
> FTP als "nicht erweiterbar" zu bezeichnen ist in etwa so, als ob du
> Luft als nicht kompremierbar bezeichnen wuerdest.
>
> Das ist so Absurd, dass es keiner Arugmentation mehr bedarf.
Auch hierzu, siehe meine Antwort an Sebastian.
> >>> Der separate Datenkanal wird einem aufgezwungen.
> >>
> >> Das ist das einzig Wahre in deinem FUD-Haufen.
> >
> > Was heißt "FUD", und warum entspricht mein "Haufen" dieser
> > Definition?
>
> Google koennte dir das erklaeren.
Auszug aus der "Jargon File":
"FUD /fuhd/ n. Defined by Gene Amdahl after he left IBM to found his
own company: "FUD is the fear, uncertainty, and doubt that IBM sales
people instill in the minds of potential customers who might be
considering [Amdahl] products." The idea, of course, was to persuade
them to go with safe IBM gear rather than with competitors'
equipment. This implicit coercion was traditionally accomplished by
promising that Good Things would happen to people who stuck with IBM,
but Dark Shadows loomed over the future of competitors' equipment or
software. See {IBM}. After 1990 the term FUD was associated
increasingly frequently with {Microsoft}, and has become generalized
to refer to any kind of disinformation used as a competitive weapon."
> >>> FTP geht bedingungslos davon aus, dass sich die
> >>> Kommunikationspartner nicht kennen und eigentlich auch nichts
> >>> voneinander wissen wollen. Der Client will sich nur schnell etwas
> >>> herunterladen oder kurz eine Datei hochladen. Dafür haben wir
> >>> HTTP.
> >>
> >> Unsinn.
> >
> > Begründe bitte.
>
> Dass FTP nicht bedingungslos davon ausgeht, dass sich
> Kommunikationspartner nicht kennen?
>
> Gerne:
>
> FTP geht davon aus, dass sich die Kommunikationspartner kennen, mit
> der Ausnahme anonymen bzw. authentiikationsfreien Zugangs.
Du weißt selber, dass die FTP-eigene Authentifizierung ohne
Schutzschicht nichts taugt.
> Letztes ist praktisch nirgends mehr implementiert.
Doch, praktisch überall, nur in den Implementierungen defaultmäßig
deaktiviert.
> > Es war damals ein Feature, als man per Kommandozeile mit FTP
> > gearbeitet hat. Dieses "Feature" wurde im Laufe der Jahre so
> > missverstanden, dass es sich keine FTP-Serversoftware erlauben
> > könnte, ein Dateilisting anders darzustellen als von der breiten
> > Masse diktatiert.
> >
> > Nichts hätte dagegengesprochen, das Format des Dateilistings dennoch zu
> > standardisieren.
>
> Mir duenkt du weist schlicht nicht, was FTP eigentlich ist, welche
> Funktionalitaet es hat, wie es erweitert werden kann und was man alles
> damit anstellen kann.
>
> Du gehst von einem Spezialfall aus und reflektierst das unqualifiziert
> auf das Protokoll. Das ist nicht sonderlich zielfuehrend.
Und dieser Spezialfall heißt "RFC 959". Entschuldige, wenn du etwas
anderes unter "FTP" verstehst als das "File Transfer Protocol" aus
RFC 959.
Sebastian G.
> Sebastian G. <se...@seppig.de>:
>> Und fuer jeden Range muss man den laufenden Transfer anhalten, 'nen Request
>> senden, Bestaetigung abwarten, und dann erst senden/empfangen. Genau das
>> gleiche Overhead-Problem hat FTP auch.
>
> FTP kann out-of-band Steuerung.
Ich weiss, trotzdem ist der Overhead bei kleinen Dateien oder Ranges leider
prohibitiv.
> Was mich wundert ist, dass Mickeysoft nicht einfach seine RPC
> Methoden in FTP eingebaut hat.
DCE-RPC over HTTP haben sie bereits...
Ertugrul Söylemez
"Sebastian G." <se...@seppig.de> wrote:
> > Diese Liste ist keine Kontrollkommunikation, sondern eine
> > Datenkommunikation (unnötig langsam)
>
> Huh? Eine kurze Kommunikation, die steuerrelevante Daten enthaelt,
> eben nicht auch einen separaten Kanal abzwaelzen, sei langsam?
Der separate Kanal muss erst einmal aufgebaut werden -- und das jedes
mal.
Sebastian G.
> SSL und TLS können (oder sollten) nicht die Authentifizierung der
> Anwendungsschicht übernehmen. Sie sollten den Host authentifizieren,
> nicht den User. Bei Telnet oder FTP mit Passwort-Authentifizierung geht
> das ja noch, aber ich will schlüsselbasierte Authentifizierung.
Wie bereits erwaehnt:
1. Eine FTP-Erweiterung unterstuetzt Challenge/Response-Authentifizierung.
2. STARTTLS und PROT P ermoeglichen, dass nach der
Passwort-Authentifizierung zusaetzlich eine schluesselbasierte
Authentifizierung mit TSL und Client-Zertifikationen angestossen wird.
>> Der FTP-Steuerkanal basiert auf Befehlen. Man kann weitere Befehle
>> hinzufuegen, was schon mehrfach erfolgte.
>
> ... und damit jedes mal den Standard brechen oder einschränken.
Man kann bei FTP auch nach unterstuetzten Kommandos fragen.
> Hätte ich denn sonst einen Grund, z.B. für Backups Rsync/SSH gegenüber FTP vorzuziehen?
Ja. RSync arbeitet differentiell.
Sebastian G.
Nochmal: Dateilisten kommen bei FTP im Kommunikationskanal, deshalb muss ja
eben kein separater Kanal aufgebaut werden.
Ertugrul Söylemez
"Sebastian G." <se...@seppig.de> wrote:
Das muss eine Erweiterung sein, die ich nicht kenne.
Juergen P. Meier
> On Fri, 29 Feb 2008 13:37:23 +0000 (UTC)
> "Juergen P. Meier" <nospa...@jors.net> wrote:
>
>> >>> Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung
>> >>> selbst lässt sich nicht, basierend auf der Authentifizierung,
>> >>> absichern.
>> >>
>> >> Hae?
>> >
>> > Der Schlüssel wird normalerweise nicht aus der Luft gesaugt. Er
>> > wird z.B. mit einem authentifizierten DH-Schlüsseltausch vereinbart.
>> > Das Wort, auf das es hier ankommt, ist "authentifiziert".
>>
>> Ja und? Wiso sollte die Datenuebertragung nicht authentifiziert sein?
>> Oder verwechselst du hier die Authentifikation auf Anwendungsschicht
>> mit der auf Transportschicht?
>
> Nein, du gehst davon aus, dass eine SSL/TLS-Schale um FTP gelegt wird.
Nein.
TLS/SSL ist in FTP /integriert/ worden. Und das schon vor etlichen
Jahren.
> Davon gehe ich gerade nicht aus. Näheres dazu, siehe meine Antwort an
> Sebastian.
Auf der einen Seite kritisierst du, dass FTP nicht erweiterbar sei,
und auf der anderen behauptest du, alle Sicherheitsfeatures seien nur
Erweiterungen.
That's Silly.
>> > Begründe bitte.
>>
>> Dass FTP nicht bedingungslos davon ausgeht, dass sich
>> Kommunikationspartner nicht kennen?
>>
>> Gerne:
>>
>> FTP geht davon aus, dass sich die Kommunikationspartner kennen, mit
>> der Ausnahme anonymen bzw. authentiikationsfreien Zugangs.
>
> Du weißt selber, dass die FTP-eigene Authentifizierung ohne
> Schutzschicht nichts taugt.
TLS-Geschuetzte Username/Passwort-Auth reicht oftmals voellig aus.
Sie taugt also und ist FTP-Eigen.
>> Letztes ist praktisch nirgends mehr implementiert.
>
> Doch, praktisch überall, nur in den Implementierungen defaultmäßig
> deaktiviert.
Welchen FTP Server kennst du, der ohne USER/PASS zugriff erlaubt?
Ich differenziere extra zwischen anonymem und autthentifikationsfreiem
Zugriff.
>> Mir duenkt du weist schlicht nicht, was FTP eigentlich ist, welche
>> Funktionalitaet es hat, wie es erweitert werden kann und was man alles
>> damit anstellen kann.
>>
>> Du gehst von einem Spezialfall aus und reflektierst das unqualifiziert
>> auf das Protokoll. Das ist nicht sonderlich zielfuehrend.
>
> Und dieser Spezialfall heißt "RFC 959". Entschuldige, wenn du etwas
> anderes unter "FTP" verstehst als das "File Transfer Protocol" aus
> RFC 959.
Falsch. Das FTP Protokoll, dass in RFC 959 beschrieben ist, ist
flexiebel, erweiterbar (959 stellt selbst eine solche Erweiterung um
ganze sieben neue Methoden dar) und hat mit dem, was heute noch
weitlaeufig implementiert ist nicht allzu viel zu tun.
Ertugrul Söylemez
"Juergen P. Meier" <nospa...@jors.net> wrote:
> >> Ja und? Wiso sollte die Datenuebertragung nicht authentifiziert
> >> sein? Oder verwechselst du hier die Authentifikation auf
> >> Anwendungsschicht mit der auf Transportschicht?
> >
> > Nein, du gehst davon aus, dass eine SSL/TLS-Schale um FTP gelegt
> > wird.
>
> Nein.
>
> TLS/SSL ist in FTP /integriert/ worden. Und das schon vor etlichen
> Jahren.
Wenn das wirklich so ist, dann habe ich diesen Teil der FTP-Entwicklung
verschlafen. Aber bitte verrate mir noch, wo ich die Dokumente zum
entsprechenden Standard finde.
> > Davon gehe ich gerade nicht aus. Näheres dazu, siehe meine Antwort
> > an Sebastian.
>
> Auf der einen Seite kritisierst du, dass FTP nicht erweiterbar sei,
> und auf der anderen behauptest du, alle Sicherheitsfeatures seien nur
> Erweiterungen.
>
> That's Silly.
Nein, das ist doch gerade das Problem, das ich anspreche. Alle
derartigen Sicherheitsfeatures sind standardverletzende Erweiterungen.
> > Du weißt selber, dass die FTP-eigene Authentifizierung ohne
> > Schutzschicht nichts taugt.
>
> TLS-Geschuetzte Username/Passwort-Auth reicht oftmals voellig aus.
> Sie taugt also und ist FTP-Eigen.
Das kannst du so nicht sagen. TLS mit USER/PASS reicht aus, wenn man
ein von einer CA signiertes Zertifikat für den Server hat, oder die
Vertrauenswürdigkeit von mindestens einem Zertifikat auf irgendeine
andere Art hergestellt wird.
> >> Letztes ist praktisch nirgends mehr implementiert.
> >
> > Doch, praktisch überall, nur in den Implementierungen defaultmäßig
> > deaktiviert.
>
> Welchen FTP Server kennst du, der ohne USER/PASS zugriff erlaubt? Ich
> differenziere extra zwischen anonymem und autthentifikationsfreiem
> Zugriff.
Übersehen, sorry. Aber anonymen und unauthentifizierten Zugriff halte
ich für beinahe äquivalent. Beim anonymen Zugriff kann der Benutzer
eine Email-Adresse hinterlegen, aber das ist auch schon das Höchste.
> >> Du gehst von einem Spezialfall aus und reflektierst das
> >> unqualifiziert auf das Protokoll. Das ist nicht sonderlich
> >> zielfuehrend.
> >
> > Und dieser Spezialfall heißt "RFC 959". Entschuldige, wenn du etwas
> > anderes unter "FTP" verstehst als das "File Transfer Protocol" aus
> > RFC 959.
>
> Falsch. Das FTP Protokoll, dass in RFC 959 beschrieben ist, ist
> flexiebel, erweiterbar (959 stellt selbst eine solche Erweiterung um
> ganze sieben neue Methoden dar) und hat mit dem, was heute noch
> weitlaeufig implementiert ist nicht allzu viel zu tun.
Du sagst damit also, man muss keinen neuen Standard definieren, um eine
neue Authentifizierungsmethode zu implementieren?
Juergen P. Meier
>> TLS/SSL ist in FTP /integriert/ worden. Und das schon vor etlichen
>> Jahren.
>
> Wenn das wirklich so ist, dann habe ich diesen Teil der FTP-Entwicklung
> verschlafen. Aber bitte verrate mir noch, wo ich die Dokumente zum
> entsprechenden Standard finde.
Bei der IETF. Die RFC-Nummer wurde dir bereits genannt.
>> Falsch. Das FTP Protokoll, dass in RFC 959 beschrieben ist, ist
>> flexiebel, erweiterbar (959 stellt selbst eine solche Erweiterung um
>> ganze sieben neue Methoden dar) und hat mit dem, was heute noch
>> weitlaeufig implementiert ist nicht allzu viel zu tun.
>
> Du sagst damit also, man muss keinen neuen Standard definieren, um eine
> neue Authentifizierungsmethode zu implementieren?
Korrekt, den der FTP Standard ist seit >35 Jahren weitsichtig genug, um
so neue Modeerscheinungen wie TCP/IP(v4), ACLs, POSIX, Non-ASCII Files,
IPv6 und eben auch SSL/TLS einfach so zu integrieren, ohne neu erfunden
werden zu muessen. FTP ist das Paradebeispiel eines /erweiterbaren/
Protokolls. Du koenntest mit FTP auch RPC und NFS nachbauen.
Es ist so universell, dass es speziellere Protokolle gibt, die ihre
jeweilige Aufgabe natuerlich optimaler erfuellen (SMTP, HTTP, TFTP,
RPC...).
Dummerweise laesst sich FTP in seiner Komplexitaet aber auf keines
dieser vergleichsweise spezialisierten Protokolle vollstanedig - d.h.
ohne Verluste - abbilden. Wenn das nicht so waere, gaebe es schon
seit 20 Jahren kein FTP mehr.
Es gibt viel an FTP herumzukritisieren, aber du hast groesstenteils
unpassende und schlichtweg unrichtige Kritikpunkte aufgefuehrt.
Ertugrul Söylemez
"Juergen P. Meier" <nospa...@jors.net> wrote:
Dann verstehe ich wirklich nicht, warum zur Hölle es mir mit FTP so
schwer fällt, schlüsselbasierte Authetifizierung ohne viel Aufwand
umzusetzen. Insbesondere will ich keine CA aufsetzen müssen.
Juergen P. Meier
> Dann verstehe ich wirklich nicht, warum zur Hölle es mir mit FTP so
> schwer fällt, schlüsselbasierte Authetifizierung ohne viel Aufwand
> umzusetzen. Insbesondere will ich keine CA aufsetzen müssen.
Fuer TLS bzw. X.509-Zertifikatsbasierte Authentifizierung brauchst du
prinzipiell eine CA.
Und OpenPGP ist hier in der Tat nicht impelementiert.
OpenPGP zur Authentifikation bie Datenaustausch wird halt fast
ausschliesslich in Verbindung mit E-Mails verwendet. Auf
Applikationsebene und darueberliegenden Schichten.
Und sonst sind mir keine Standardverfahren der Authentifikation (bzw.
Identifikation) mittes assymetrischer kryptographischer Schluesel
bekannt.
Ertugrul Söylemez
"Juergen P. Meier" <nospa...@jors.net> wrote:
Naja, das ist ja wieder nur Authentifizierung auf Host-Ebene. TLS ist
hier einfach nicht die Lösung, die ich suche. Natürlich ist
User-Authentifizierung auch mit TLS möglich, aber dafür liegt TLS in der
falschen Schicht, und in der Tat ist es auch ein ziemlicher PITA, das
einzurichten -- zumindest mit den FTP-Serverimplementierungen, die ich
bis jetzt getestet habe.
Bernd Eckenfels
> Es sollte einfach mal ein neues FTP geben.
Nennt sich webdav :)
Gruss
Bernd
Richard W. Könning
>On Fri, 29 Feb 2008 12:08:48 +0100
>"Sebastian G." <se...@seppig.de> wrote:
>
>> > Ja, aber es sollte doch einfach mal _das_ FTP der Neuzeit geben.
>> > Wir haben ja schließlich auch _das_ Hypertext-Protokoll und _das_
>> > Shell-Protokoll. Es muss ein richtig gutes Dateitransfer-Protokoll
>> > geben, das flexibel und zufriedenstellend für möglichst alle
>> > Szenarien ist.
>>
>> Also FTP.
>>
>> > Mein Problem mit FTP (aus RFC 959) ist Sicherheit und Flexibilität,
>>
>> Sicherheit ist Aufgabe von Layer 6, da gibt's SSL und TLS.
>> Wo genau mangelt es dir bei FTP and Flexibilitaet?
>
>Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
>schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
>Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung selbst
>lässt sich nicht, basierend auf der Authentifizierung, absichern.
Falsch, RFC 2228 existiert.
>Flexibilität: FTP ist nicht erweiterbar. Der separate Datenkanal wird
>einem aufgezwungen.
Wenn man sich die historische Entwicklung von FTP ansieht, dann kommt
man kaum zum Schluß, FTP sei nicht erweiterbar. RFC 959 ist mehr als
22 Jahre alt, RFC 765 sogar 28 Jahre. RFC 4217 wiederum ist erst vor
drei Jahren der Sammlung von FTP-RFCs hinzugefügt worden.
Der separate Datenkanal ist sicherlich "gewöhnungsbedürftig", aber man
kann damit leben.
>FTP geht bedingungslos davon aus, dass sich die Kommunikationspartner
>nicht kennen und eigentlich auch nichts voneinander wissen wollen. Der
Ich weiß nicht, wie Du darauf kommst. Ich muß bei meinen FTP-Transfers
regelmäßig User-Name, Account und Passwort angeben; wenn ich eins
davon nicht kenne, komme ich nicht rein.
>Client will sich nur schnell etwas herunterladen oder kurz eine Datei
>hochladen. Dafür haben wir HTTP.
>
>Außerdem wirkt FTP ein Bisschen wie ein extrem mieser Shell-Verschnitt.
Da FTP mehr oder weniger auf Telnet aufsetzt, ist das nicht sonderlich
verwunderlich.
>Man kann den Inhalt des aktuellen Verzeichnisses abrufen, aber es gibt
>keinen Standard, der das Format dieser Liste vorschreibt. Diese Liste
RFC 3659 existiert, Implementationen der darin beschriebenen Kommandos
MLST und MLSD existieren ebenfalls.
>ist keine Kontrollkommunikation, sondern eine Datenkommunikation
>(unnötig langsam), und so weiter und so fort.
Es gibt auch Listings über die Kontrollverbindung (per STAT-Kommando),
aber diese sind eher ungebräuchlich. Bei sehr großer RTT mag das
Argument "Listing per langsamer Datenverbindung" ziehen, im
allgemeinen ist das aber eher selten ein Problem.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Richard W. Könning
>On Fri, 29 Feb 2008 11:49:38 +0000 (UTC)
>"Juergen P. Meier" <nospa...@jors.net> wrote:
>
>> > On Fri, 29 Feb 2008 12:08:48 +0100
>> >
>> > Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
>> > schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
>>
>> TLS/SSL und anderen sichere Auth-Methoden gibt es schon laenger fuer
>> FTP.
>
>Was passiert, wenn ich schlüsselbasierte Authentifizierung will? Kann
>das FTP? Ich rede von FTP und du schwafelst etwas von TLS. So gesehen
TLS ist nun mal ein häufig für die Absicherung von FTP (und anderen
Protokollen wie HTTP, SMTP, POP3, IMAP...) verwendetes Protokoll, d.h.
wenn man über die Absicherung von FTP (oder HTTP,...) redet, dann
kommt man fast zwangsläufig auf TLS zu reden.
>kann ich auch Telnet mit TLS absichern. Ist Telnet deswegen gut?
Implementationen von Telnet over TLS existieren. Ich sehe nicht, warum
Telnet schlecht sein sollte, außer, daß es mit SSH etwas gibt, das in
den allermeisten Fällen besser ist. Und da das Bessere der Feind des
Guten ist,...
>> > Anwendungsbeispiele keine guten Methoden. Die Dateiübertragung
>> > selbst lässt sich nicht, basierend auf der Authentifizierung,
>> > absichern.
>>
>> Hae?
>
>Der Schlüssel wird normalerweise nicht aus der Luft gesaugt. Er wird
>z.B. mit einem authentifizierten DH-Schlüsseltausch vereinbart. Das
>Wort, auf das es hier ankommt, ist "authentifiziert".
Genau hierfür gibt es z.B. TLS.
>> > Außerdem wirkt FTP ein Bisschen wie ein extrem mieser
>> > Shell-Verschnitt. Man kann den Inhalt des aktuellen Verzeichnisses
>> > abrufen, aber es gibt keinen Standard, der das Format dieser Liste
>> > vorschreibt. Diese Liste ist keine Kontrollkommunikation, sondern
>> > eine Datenkommunikation (unnötig langsam), und so weiter und so
>> > fort.
>>
>> Das ist ein Feature, kein Bug.
>>
>> Ein so nuetzliches solches, dass FTP die letzten 35 Jahre ueberlebt
>> hat.
>
>Es war damals ein Feature, als man per Kommandozeile mit FTP gearbeitet
>hat. Dieses "Feature" wurde im Laufe der Jahre so missverstanden, dass
>es sich keine FTP-Serversoftware erlauben könnte, ein Dateilisting
>anders darzustellen als von der breiten Masse diktatiert.
>
>Nichts hätte dagegengesprochen, das Format des Dateilistings dennoch zu
>standardisieren.
Es gibt einen solchen Standard: RFC 3659.
Richard W. Könning
>On Fri, 29 Feb 2008 14:42:25 +0100
>"Sebastian G." <se...@seppig.de> wrote:
>
>> >>> Sicherheit: Das Authentifizierungssystem von FTP ist, wie i uff
>> >>> schwäbisch sage würd, unter aller Sau. Es gibt per RFC für viele
>> >>
>> >> TLS/SSL und anderen sichere Auth-Methoden gibt es schon laenger
>> >> fuer FTP.
>> >
>> > Was passiert, wenn ich schlüsselbasierte Authentifizierung will?
>> > Kann das FTP?
>>
>> Ja, kann es. Sowohl im Prolog als auch nachtraeglich via PROT P.
>
>Das FTP (entsprechend RFC 959) kann das nicht. Es gibt USER und es gibt
Ja und? Die FTP-Welt ist nicht bei RFC 959 stehen geblieben.
>PASS. STARTTLS ist bereits eine Erweiterung, ebenso wie PROT.
Wo ist das Problem?
>> > Ich rede von FTP und du schwafelst etwas von TLS. So gesehen kann
>> > ich auch Telnet mit TLS absichern. Ist Telnet deswegen gut?
>>
>> Telnet over TLS waere als SSH-Ersatz durchaus nicht uebel.
>>
>> [...]
>>
>> Bei Implicit-SSL ist der Datenkanal genauso authentifiziert wie der
>> Steuerkanal beim Verbindungsaufbau, bei Explicit-SSL kannst du sogar
>> eine getrennte Authentifizierung verlangen.
>
>Deswegen ist Telnet aber nicht gut. Ihr schwafelt ständig von
>Zusatzprotokollen und von Erweiterungen. Ich rede von FTP (bzw. hier
>von Telnet). Das kann doch nicht so schwer zu begreifen sein ...
Dein Problem scheint im mangelnden Verständnis des RFC-Wesens zu
liegen. Wenn z.B. Protokolle weiterentwickelt werden, dann wird eher
selten der alte RFC durch einen komplett neuen ersetzt (obwohl auch
das vorkommt: FTP: 765 -> 959, Mail: 821, 822 -> 2821, 2822), sondern
es werden Erweiterungs-RFCs veröffentlicht, in denen die Erweiterungen
(und evtl. die Teile, die wegfallen) beschrieben werden. D.h. eine dem
aktuellen RFC-Stand entsprechende FTP-Implementierung beruht auf RFC
959 als Basis plus einem ganzen Strauß weiterer RFCs.
>SSL und TLS können (oder sollten) nicht die Authentifizierung der
>Anwendungsschicht übernehmen. Sie sollten den Host authentifizieren,
>nicht den User. Bei Telnet oder FTP mit Passwort-Authentifizierung geht
>das ja noch, aber ich will schlüsselbasierte Authentifizierung.
Hierfür gibt es RFC 2228, der den allgemeinen Rahmen für so etwas
vorgibt. Eine konkrete Anwendung von RFC 2228 ist RFC 4217, wo TLS für
die Absicherung verwendet wird. TLS wiederum bietet eine ständig
wachsende Sammlung von Cipher-Suites an, in der auch etwas für Dich
drin sein sollte. So könnte man z.B. TLS mit Client-Zertifikaten
verwenden, um auch die Authentifizierung per TLS zu machen. Das
betrifft aber nicht mehr das FTP-*Protokoll*, sondern nur die
entsprechende Implementierung von FTP-Client und -Server.
>> >>> Flexibilität: FTP ist nicht erweiterbar.
>> >>
>> >> Das ist Grober Unsinn.
>> >
>> > Es ist ein extrem hässlicher Trend im Usenet, Aussagen völlig ohne
>> > Begründung zu verneinen oder gar anzugreifen. Wenn ich mich irre,
>> > dann korrigiere mich bitte. Mich nur darauf hinzuweisen, dass ich
>> > mich irre, ist -- ähnlich wie Metafragen -- in jeder Hinsicht
>> > kontraproduktiv.
>>
>> Der FTP-Steuerkanal basiert auf Befehlen. Man kann weitere Befehle
>> hinzufuegen, was schon mehrfach erfolgte.
>
>... und damit jedes mal den Standard brechen oder einschränken.
Wenn die zusätzlichen Kommandos per RFC definiert sind, dann wird kein
Standard gebrochen. RFC 959 ist eine notwendige, aber heutzutage keine
hinreichende Beschreibung der von einer FTP-Implementation zu
beachtenden Standards.
Richard W. Könning
>On Fri, 29 Feb 2008 15:38:57 +0100
>"Sebastian G." <se...@seppig.de> wrote:
>
>> >>> Diese Liste ist keine Kontrollkommunikation, sondern eine
>> >>> Datenkommunikation (unnötig langsam)
>> >>
>> >> Huh? Eine kurze Kommunikation, die steuerrelevante Daten enthaelt,
>> >> eben nicht auch einen separaten Kanal abzwaelzen, sei langsam?
>> >
>> > Der separate Kanal muss erst einmal aufgebaut werden -- und das
>> > jedes mal.
>>
>> Nochmal: Dateilisten kommen bei FTP im Kommunikationskanal, deshalb
>> muss ja eben kein separater Kanal aufgebaut werden.
Dateilisten kommen gewöhnlich über die Datenverbindung...
>Das muss eine Erweiterung sein, die ich nicht kenne.
können allerdings auch über die Kontrollverbindung kommen, siehe die
Beschreibung des STAT-Kommandos in RFC 959, Seite 33-34. Ich habe das
allerdings auch jahrelang übersehen; und FTP-Clients und -Server , die
diese Funktionalität nicht implementiert haben, können in der freien
Wildbahn gut überleben, sonderlich verbreitet scheint also die Nutzung
dieses Features nicht zu sein.
Richard W. Könning
>Andreas Beck wrote:
>
>> Kein Mensch braucht sowas wie FXP (von 3. Server ausgelöste Transfers
>> zwischen zwei anderen),
>
>FXP ist kein Teil von standardkonformem FTP, sondern vielmehr ein Hack auf
>der Basis kaputter Implementierungen.
FXP folgt aus der Anwendung von RFC 959 (genauer: PORT- und
PASV-Kommando), ist also sehr wohl standardkonform.
Richard W. Könning
>On Fri, 29 Feb 2008 13:37:23 +0000 (UTC)
>"Juergen P. Meier" <nospa...@jors.net> wrote:
>
>> FTP geht davon aus, dass sich die Kommunikationspartner kennen, mit
>> der Ausnahme anonymen bzw. authentiikationsfreien Zugangs.
>
>Du weißt selber, dass die FTP-eigene Authentifizierung ohne
>Schutzschicht nichts taugt.
Ja und? SFTP kommt ganz ohne Authentifizierung aus, weil es sich
völlig auf SSH verläßt.
Richard W. Könning
>On Fri, 29 Feb 2008 14:56:05 +0000 (UTC)
>"Juergen P. Meier" <nospa...@jors.net> wrote:
>
>> >> Ja und? Wiso sollte die Datenuebertragung nicht authentifiziert
>> >> sein? Oder verwechselst du hier die Authentifikation auf
>> >> Anwendungsschicht mit der auf Transportschicht?
>> >
>> > Nein, du gehst davon aus, dass eine SSL/TLS-Schale um FTP gelegt
>> > wird.
>>
>> Nein.
>>
>> TLS/SSL ist in FTP /integriert/ worden. Und das schon vor etlichen
>> Jahren.
>
>Wenn das wirklich so ist, dann habe ich diesen Teil der FTP-Entwicklung
>verschlafen. Aber bitte verrate mir noch, wo ich die Dokumente zum
>entsprechenden Standard finde.
Für FTP mit TLS: RFC 4217, der wiederum auf RFC 2228 basiert.
>> > Davon gehe ich gerade nicht aus. Näheres dazu, siehe meine Antwort
>> > an Sebastian.
>>
>> Auf der einen Seite kritisierst du, dass FTP nicht erweiterbar sei,
>> und auf der anderen behauptest du, alle Sicherheitsfeatures seien nur
>> Erweiterungen.
>>
>> That's Silly.
>
>Nein, das ist doch gerade das Problem, das ich anspreche. Alle
>derartigen Sicherheitsfeatures sind standardverletzende Erweiterungen.
Welchen FTP-Standard verletzt RFC 4217?
>> >> Du gehst von einem Spezialfall aus und reflektierst das
>> >> unqualifiziert auf das Protokoll. Das ist nicht sonderlich
>> >> zielfuehrend.
>> >
>> > Und dieser Spezialfall heißt "RFC 959". Entschuldige, wenn du etwas
>> > anderes unter "FTP" verstehst als das "File Transfer Protocol" aus
>> > RFC 959.
>>
>> Falsch. Das FTP Protokoll, dass in RFC 959 beschrieben ist, ist
>> flexiebel, erweiterbar (959 stellt selbst eine solche Erweiterung um
>> ganze sieben neue Methoden dar) und hat mit dem, was heute noch
>> weitlaeufig implementiert ist nicht allzu viel zu tun.
>
>Du sagst damit also, man muss keinen neuen Standard definieren, um eine
>neue Authentifizierungsmethode zu implementieren?
Das kommt darauf an. Wenn Du die Authentifizierungsmethode als
TLS-Cipher-Suite implementierst, dann hat RFC 4217 schon alles gesagt,
was für das FTP-Protokoll relevant ist. Willst Du ein Protokoll
ungleich TLS verwenden, dann mußt Du Dir RFC 2228 hernehmen und Dein
Protokoll (analog zu RFC 4217) auf die dort beschriebenen Kommandos
abbilden. Sollte der Interessentenkreis für Deine Lösung größer sein,
bietet es sich an, einen eigenen RFC auf den Weg zu bringen. Als
weiteres Beispiel für ein auf RFC 2228 basierendes Protokoll sei noch
RFC 2773 genannt.
Ein anderes Problem ist, daß FTP-Client- und -Server-Implementierung
zusammenpassen müssen, d.h. wenn der FTP-Server ein
TLS-Client-Zertifikat erwartet, dann sollte der FTP-Client in der Lage
sein, eins zu schicken. Das sind aber Dinge, die nicht durch RFCs
geregelt werden.
Richard W. Könning
>On Fri, 29 Feb 2008 16:49:18 +0000 (UTC)
>"Juergen P. Meier" <nospa...@jors.net> wrote:
>
>> > Dann verstehe ich wirklich nicht, warum zur Hölle es mir mit FTP so
>> > schwer fällt, schlüsselbasierte Authetifizierung ohne viel Aufwand
>> > umzusetzen. Insbesondere will ich keine CA aufsetzen müssen.
>>
>> Fuer TLS bzw. X.509-Zertifikatsbasierte Authentifizierung brauchst du
>> prinzipiell eine CA.
>>
>> Und OpenPGP ist hier in der Tat nicht impelementiert.
>>
>> OpenPGP zur Authentifikation bie Datenaustausch wird halt fast
>> ausschliesslich in Verbindung mit E-Mails verwendet. Auf
>> Applikationsebene und darueberliegenden Schichten.
>>
>> Und sonst sind mir keine Standardverfahren der Authentifikation (bzw.
>> Identifikation) mittes assymetrischer kryptographischer Schluesel
>> bekannt.
>
>Naja, das ist ja wieder nur Authentifizierung auf Host-Ebene. TLS ist
>hier einfach nicht die Lösung, die ich suche. Natürlich ist
>User-Authentifizierung auch mit TLS möglich, aber dafür liegt TLS in der
>falschen Schicht, und in der Tat ist es auch ein ziemlicher PITA, das
Wieso liegt TLS in der falschen Schicht?
>einzurichten -- zumindest mit den FTP-Serverimplementierungen, die ich
>bis jetzt getestet habe.
Das hat aber nichts mehr mit Transport-Protokollen zu tun.
Andreas Beck
> Andreas Beck wrote:
>> FTP saugt in NAT-Szenarien Meteoritenschwärme durch Strohhalme.
> Stimmt. Und das ist jetzt nicht die Schuld von NAT, weil...
Klar ist das ein NAT-Problem. Und NAT sollte möglichst schnell sterben.
Blöderweise ist es z.Zt. so verbreitet, dass man es und die damit
verbundenen Probleme nicht so leicht ignorieren kann.
>> Kein Mensch braucht sowas wie FXP (von 3. Server ausgelöste Transfers
>> zwischen zwei anderen),
> FXP ist kein Teil von standardkonformem FTP, sondern vielmehr ein Hack auf
> der Basis kaputter Implementierungen.
Kaputt würde ich nicht sagen. Aber ... vom Sinngehalt her seltsam.
>> Außerdem gäbe es noch HTTP put.
>> Läuft mit SSL, wenn man will, braucht nur eine Verbindung, kann Ranges
>> übertragen, etc. pp.
> Und fuer jeden Range muss man den laufenden Transfer anhalten, 'nen Request
> senden, Bestaetigung abwarten, und dann erst senden/empfangen. Genau das
> gleiche Overhead-Problem hat FTP auch.
Schon. Aber so what. Ja, man kann vieles noch verbessern, aber "so gut
wie FTP" wäre für viele Zwecke ja schon gut genug.
> Deshalb erwaehnte ich ja SMB, weil das da sehr effizient vonstatten geht.
Und es ist ein Remote-FS. Das ist scheinbar eh das einzige, was ein ONU
bedient kriegt. Alle ONU-tauglichen FTP-Frontends zeigen sich mehr oder
weniger als Dateisystem-Browser. Und ehrlich gesagt: ich mag diese Sicht
auch.
>> Oder eben ein beliebiges halbwegs sicheres remote-fs.
> Moechte man auch Windows abdecken (es ging darum, dass es mindestens so
> verbreitet ist wie FTP), so bliebe einem da eigentlich nur SMB/CIFS oder NFS.
NFS beißt sich mit "sicher".
CU, Andy
Sebastian G.
> Sebastian G. wrote:
>> Andreas Beck wrote:
>>> FTP saugt in NAT-Szenarien Meteoritenschwärme durch Strohhalme.
>> Stimmt. Und das ist jetzt nicht die Schuld von NAT, weil...
>
> Klar ist das ein NAT-Problem. Und NAT sollte möglichst schnell sterben.
> Blöderweise ist es z.Zt. so verbreitet, dass man es und die damit
> verbundenen Probleme nicht so leicht ignorieren kann.
>
>>> Kein Mensch braucht sowas wie FXP (von 3. Server ausgelöste Transfers
>>> zwischen zwei anderen),
>> FXP ist kein Teil von standardkonformem FTP, sondern vielmehr ein Hack auf
>> der Basis kaputter Implementierungen.
>
> Kaputt würde ich nicht sagen. Aber ... vom Sinngehalt her seltsam.
Nein, wirklich kaputt. FTP sieht vor, dass der PORT-Kommando stets den
gleichen Host spezifiziert, mit dem der Server gerade redet, und gerade bei
verwendung von TLS laesst sich des hervorragend forcieren.
>> Deshalb erwaehnte ich ja SMB, weil das da sehr effizient vonstatten geht.
>
> Und es ist ein Remote-FS. Das ist scheinbar eh das einzige, was ein ONU
> bedient kriegt.
Also ich kenne sowohl Kernel-Module als auch FUSE-Treiber fuer Linux, ebenso
wie einige Redirector fuer Windows, mit denen man FTP als Remote-FS mounten
kann. Herrje, bei Linux heisst es sogar ftpvfs (vfs = virtual file system).
Leider unterstuetzen dir fuer Windows keine Ranges, d.h. es wird stets die
komplette Datei transferiert.
> NFS beißt sich mit "sicher".
Nicht bei Version 4.
Joachim Meyer
> Die Protokollunterlagen liegen derzeit noch bei Microsoft und bei einer
> Hand voll Samba-Programmierern.
http://www.microsoft.com/downloads/details.aspx?FamilyID=1445765D-F965-4F7D-BAF5-BDFD87378102
Richard W. Könning
>Andreas Beck wrote:
>
>> Sebastian G. wrote:
>>> Andreas Beck wrote:
>>>> Kein Mensch braucht sowas wie FXP (von 3. Server ausgelöste Transfers
>>>> zwischen zwei anderen),
>>> FXP ist kein Teil von standardkonformem FTP, sondern vielmehr ein Hack auf
>>> der Basis kaputter Implementierungen.
>>
>> Kaputt würde ich nicht sagen. Aber ... vom Sinngehalt her seltsam.
>
>
>Nein, wirklich kaputt. FTP sieht vor, dass der PORT-Kommando stets den
>gleichen Host spezifiziert, mit dem der Server gerade redet, und gerade bei
Wo soll FTP das vorsehen? Warum enthält dann der PORT-Parameter auch
die Host-Adresse? Und vor allem, warum beschreibt RFC 959 auf den
Seiten 44 und 45 FXP (ohne dem einen Namen zu geben), wenn FTP das gar
nicht vorsieht? Reden wir wirklich vom gleichen FTP?
Sebastian G.
> Warum enthält dann der PORT-Parameter auch die Host-Adresse?
Weil der Host halt hinter IP-Masquerading haengen kann und folglich eine
andere Adresse mitteilen muss, unter der er erreichbar ist.
Juergen Ilse
Dieser Versuch einer Begruendung ist idiotisch. Und IIRC ist die Moeglich-
keit, ueber die hier diskutiert wird, tatsaechlich bereits in RFC959 ge-
nannt, es ist also alles andere als eine "neue Prokollerweiterung".
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Richard W. Könning
Warum hätte man 1985 IP-Masquerading machen sollen? Kannte man damals
überhaupt schon den Begriff? Und woher hätte der Host wissen sollen,
mit welcher Adresse er beim Partner erscheint?
Die Antworten auf diese Fragen sind aber egal, weil aus dem von Dir
weggeschnittenen Teil meines Postings klar wird, daß FXP im
FTP-Basis-RFC explizit beschrieben ist.
Wenn man verloren hat, dann hat man verloren; beim nächsten Mal rate
ich zur RFC-Lektüre vorm Posten, denn RFCs lesen bildet.
Arno Welzel
Und woher soll der Host wissen, unter welcher Adresse er nach aussen hin
erreichbar ist? Das Masquerading wird üblicherweise _nicht_ vom Host
gemacht. Tatsächlich wird durch "NAT-Helper" genau das bei Bedarf selber
umgebaut. Die FTP-Server wissen davon nichts.
Ertugrul Söylemez
Bernd Eckenfels <ec...@lina.inka.de> wrote:
> > Es sollte einfach mal ein neues FTP geben.
>
> Nennt sich webdav :)
Ich glaube nicht, dass das die Probleme löst, die ich angeführt habe. =)
Ein Vorteil von WebDAV ist aber, dass es keinen separaten Datenkanal
erfordert. Kann allerdings natürlich in bestimmten Szenarien auch ein
Nachteil sein.
Ertugrul Söylemez
Richard W. Könning <Richard....@t-online.de> wrote:
> [...]
Eine kollektive Antwort auf alle Beiträge, um nicht 100 Subthreads
gleichzeitig zu führen, in denen im Wesentlichen überall das gleiche
drinsteht. =)
Ich habe an einem bestimmten Punkt abgebrochen, die FTP-Entwicklung zu
verfolgen. Was mich besonders daran stört, ist dass es ohne die
Sicherheitsschicht nicht auskommt. Das ist mein Hauptargument gegen
FTP. Mit den "langsamen" Dateilistings und dem separaten Datenkanal
komme ich klar; das ist wohl das geringste Problem.
Um Sicherheit zu gewinnen und schlüsselbasierte Authentifizierung zu
verwenden, muss ich mir eine CA aufziehen. Ich muss nach
Implementierungen sehen, die Client-Zertifikate akzeptiert, prüft und
schließlich mit einem bestimmten User assoziiert. Weder habe ich eine
derartige Konfiguration schon einmal in der Wildnis gesehen, noch könnte
ich ohne zu zögern eine solche Server-Implementierung nennen.
Wenn du das kannst, wäre ich dir sehr dankbar. Dann wäre ich auch
wieder von FTP überzeugt.
Ertugrul Söylemez
Richard W. Könning <Richard....@t-online.de> wrote:
> > Naja, das ist ja wieder nur Authentifizierung auf Host-Ebene. TLS
> > ist hier einfach nicht die Lösung, die ich suche. Natürlich ist
> > User-Authentifizierung auch mit TLS möglich, aber dafür liegt TLS in
> > der falschen Schicht, und in der Tat ist es auch ein ziemlicher
> > PITA, das
>
> Wieso liegt TLS in der falschen Schicht?
Weil ich nicht nur Client-Zertifikate prüfen will. Ich möchte
Client-Zertifikate mit einem bestimmten User assoziieren, wie das
z.B. bei SSH-Schlüsseln üblich ist.
Rainer Sokoll
> Ein Vorteil von WebDAV ist aber, dass es keinen separaten Datenkanal
> erfordert. Kann allerdings natürlich in bestimmten Szenarien auch ein
> Nachteil sein.
Also ich empfinde den separaten Datenkanal als einen konzeptionellen
Vorteil von ftp. Freilich ist die Implementierung suboptimal.
Rainer
Ertugrul Söylemez
Rainer Sokoll <rai...@sokoll.com> wrote:
Er kann ein Nachteil sein, und genau deswegen finde ich es nicht gut,
dass er einem aufgezwungen wird. Wäre er optional, wäre die Sache ganz
anders.
Bernd Eckenfels
> Weil ich nicht nur Client-Zertifikate prüfen will. Ich möchte
> Client-Zertifikate mit einem bestimmten User assoziieren, wie das
> z.B. bei SSH-Schlüsseln üblich ist.
Und wo ist das Problem? Das geht genauso.
Gruss
Bernd
Bernd Eckenfels
> Um Sicherheit zu gewinnen und schlüsselbasierte Authentifizierung zu
> verwenden, muss ich mir eine CA aufziehen. Ich muss nach
> Implementierungen sehen, die Client-Zertifikate akzeptiert, prüft und
> schließlich mit einem bestimmten User assoziiert.
Das gilt aber sowohl für HTTP/S (WebDav) als auch SSH sowie FTP oder auch
AS1/2/3. Ich sehe da keine Besonderheit bei FTP.
> Weder habe ich eine
> derartige Konfiguration schon einmal in der Wildnis gesehen, noch könnte
> ich ohne zu zögern eine solche Server-Implementierung nennen.
Server-Seitig können das doch die meisten FTP Server?
http://www.xlightftpd.com/tutorial/SSLTransferMode.html
http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-TLS.html
IIS kann das sogar mit AD Integration.
> Wenn du das kannst, wäre ich dir sehr dankbar. Dann wäre ich auch
> wieder von FTP überzeugt.
Ich glaub es will dich keiner von FTP ueebrzeugen, aber deine schlechte
Meinung basiert auf den falschen Annahmen.
Gruss
Bernd
Bernd Eckenfels
>> Nennt sich webdav :)
> Ich glaube nicht, dass das die Probleme löst, die ich angeführt habe. =)
Welche?
Gruss
Bernd
Richard W. Könning
Ebenso wie Bernd sehe ich da kein grundsätzliches Problem. Es kommt
halt auf den konkreten FTP-Server an, ob er die Möglichkeit bietet,
z.B. CNs auf User abzubilden.
Richard W. Könning
>On Sat, 01 Mar 2008 03:42:38 +0100
>Richard W. Könning <Richard....@t-online.de> wrote:
>
>> [...]
>
>Ich habe an einem bestimmten Punkt abgebrochen, die FTP-Entwicklung zu
>verfolgen. Was mich besonders daran stört, ist dass es ohne die
>Sicherheitsschicht nicht auskommt. Das ist mein Hauptargument gegen
Ich sehe keinen Unterschied zu anderen Transferprotokollen, die TLS
oder SSH als Sicherheitsprotokoll verwenden.
>FTP. Mit den "langsamen" Dateilistings und dem separaten Datenkanal
>komme ich klar; das ist wohl das geringste Problem.
>
>Um Sicherheit zu gewinnen und schlüsselbasierte Authentifizierung zu
>verwenden, muss ich mir eine CA aufziehen. Ich muss nach
>Implementierungen sehen, die Client-Zertifikate akzeptiert, prüft und
>schließlich mit einem bestimmten User assoziiert. Weder habe ich eine
"Akzeptieren" und "Prüfen" (im Sinne von: es gibt eine lückenlose
Zertifikatskette bis zu einer Root-CA, der man vertraut) ist bei
vielen Open- wie auch Closed-Source-Servern Standard. Die Abbildung
auf bestimmte User ist zugegebenermaßen seltener zu finden (ich habe
allerdings in den letzten Jahren auch nicht mehr so genau verfolgt, ob
sich in dieser Hinsicht was tut), weil vermutlich die meisten
Serverbetreiber noch auf User-Namen/Passwort setzen. Bei einem
OpenSource-Server wie ProFTPD sollte es allerdings kein allzugroßes
Problem sein, dies selber einzubauen, entsprechende Grundfähigkeiten
bzgl. Softwareentwicklung vorausgesetzt.
>derartige Konfiguration schon einmal in der Wildnis gesehen, noch könnte
>ich ohne zu zögern eine solche Server-Implementierung nennen.
>
>Wenn du das kannst, wäre ich dir sehr dankbar. Dann wäre ich auch
>wieder von FTP überzeugt.
Sollte die gewünschte Funktionalität nicht auf dem Markt vorhanden
sein, dann ist das nicht durch Mängel beim FTP-Protokoll begründet,
sondern nur darin, daß bislang wohl niemand den entsprechenden Bedarf
gesehen und mit einer Implementierung abgedeckt hat.
Eine gute Marktübersicht liefert die Website des RFC 4217 Autors:
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
Ohne genauer geprüft zu haben, vermute ich, daß die mit "[2] Can map
to base O/S userid" gekennzeichneten Server die von Dir gewünschte
Abbildung von Client-Cert auf User beherrschen, es gibt also wohl doch
schon einige Implementierungen.
Richard W. Könning
>Ertugrul Söylemez <e...@ertes.de> wrote:
>> Um Sicherheit zu gewinnen und schlüsselbasierte Authentifizierung zu
>> verwenden, muss ich mir eine CA aufziehen. Ich muss nach
>> Implementierungen sehen, die Client-Zertifikate akzeptiert, prüft und
>> schließlich mit einem bestimmten User assoziiert.
>
>Das gilt aber sowohl für HTTP/S (WebDav) als auch SSH sowie FTP oder auch
>AS1/2/3. Ich sehe da keine Besonderheit bei FTP.
>
>> Weder habe ich eine
>> derartige Konfiguration schon einmal in der Wildnis gesehen, noch könnte
>> ich ohne zu zögern eine solche Server-Implementierung nennen.
>
>Server-Seitig können das doch die meisten FTP Server?
>
>http://www.xlightftpd.com/tutorial/SSLTransferMode.html
>http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-TLS.html
Der ProFTPD konnte zumindestens als ich das letzte Mal den TLS-Code
mir angeschaut habe, noch keine Abbildung von Client-Zertifikaten auf
User-Id (auf der angegebenen ProFTPD-HowTo-Seite findet sich auch eine
entsprechende Bemerkung). Die TLSVerifyClient-Option besagt nur, ob
die entsprechende Zertifikatskette überprüft werden soll, nicht, ob
z.B. der CN des Zertifikats in irgendeiner Weise auf eine
(zugelassene) User-Id abgebildet werden kann. Es scheint aber andere
Server zu geben, die dies können, siehe hierzu
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html.
Noch eine Bemerkung zur ProFTPD-Seite: der Link zu www.runestig.com
ist nicht mehr gültig, da Peter Runestig vor einigen Jahren verstorben
ist. Er hat die TLS-Patches für den BSD-FTP-Client- und -Server und
den ursprünglichen TLS-Patch für den ProFTPD erstellt. Die BSD-Patches
sind inzwischen auf der Seite von Ford-Hutchinson zu finden, der
ProFTPD-Patch ist vom ProFTPD-Entwickler TJ Saunders deutlich
überarbeitet und an die ProFTPD-Modulstruktur angepaßt worden.
Ertugrul Söylemez
Bernd Eckenfels <ec...@lina.inka.de> wrote:
> >> Nennt sich webdav :)
> >
> > Ich glaube nicht, dass das die Probleme löst, die ich angeführt
> > habe. =)
>
> Welche?
Z.B. dass ich gerne ein schlüsselbasiertes Authentifizierungssystem
hätte; wobei mir das mit WebDAV wesentlich einfacher machbar erscheint
als mit FTP.
Ertugrul Söylemez
Bernd Eckenfels <ec...@lina.inka.de> wrote:
> > Um Sicherheit zu gewinnen und schlüsselbasierte Authentifizierung zu
> > verwenden, muss ich mir eine CA aufziehen. Ich muss nach
> > Implementierungen sehen, die Client-Zertifikate akzeptiert, prüft
> > und schließlich mit einem bestimmten User assoziiert.
>
> Das gilt aber sowohl für HTTP/S (WebDav) als auch SSH sowie FTP oder
> auch AS1/2/3. Ich sehe da keine Besonderheit bei FTP.
OpenSSH assoziiert per ~/.ssh/authorized_keys System-User mit bestimmten
Schlüsseln -- und das sogar in der Default-Konfiguration.
> > Weder habe ich eine derartige Konfiguration schon einmal in der
> > Wildnis gesehen, noch könnte ich ohne zu zögern eine solche
> > Server-Implementierung nennen.
>
> Server-Seitig können das doch die meisten FTP Server?
>
> http://www.xlightftpd.com/tutorial/SSLTransferMode.html
> http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-TLS.html
>
> IIS kann das sogar mit AD Integration.
Das ist aber bei allen mit einem nicht unwesentlichen Verwaltungsaufwand
verbunden. SSL/TLS-Zertifikate muss -- zumindest in den von dir
genannten Implementierungen -- erst eine CA unterschreiben. Ich
benötige womöglich für jeden Dienst ein eigenes Zertifikat mit privatem
Schlüssel, muss eventuell Tage lang auf die Unterschrift warten, etc.
Deswegen bietet für FTP auch kaum ein Anbieter so etwas an.
Bei SSH läuft das so ab: Ich bekomme (wie bei den meisten Anbietern
üblich) einen Benutzernamen und ein Passwort. Ich logge mich ein,
speichere meinen öffentlichen SSH-Schlüssel in meiner authorized_keys.
Von nun an kann ich mich mit meinem Schlüssel einloggen. Ich ändere
mein Passwort. Fertig.
Und das mache ich nicht in den von mir aufgesetzten Netzwerken, sondern
überall dort, wo ich mich per SSH in ein fremdes System einlogge. Kaum
ein Anbieter sperrt PubkeyAuthentication. Es ist per defaults an, und
es gibt keinen sinnvollen Grund, es abzuschalten.
In eigenen Netzwerken gehe ich noch einen Schritt weiter, erlaube nur
PubkeyAuthentication, gebe allen Benutzern den Host-Key vom SSH-Server
und verlange von allen Benutzern öffentliche Schlüssel. Für zusätzliche
Sicherheit kann ich z.B. eine GnuPG-Unterschrift für die Schlüssel
verlangen, falls sich der Benutzer nicht in greifbarer Nähe befindet.
Damit nutze ich vorhandene Infrastrukturen, wo vielleicht schon
Vertrauen aufgebaut ist. Es läuft einfach alles viel zwangloser und
schneller, und deswegen nicht weniger sicher als mit SSL/TLS.
> > Wenn du das kannst, wäre ich dir sehr dankbar. Dann wäre ich auch
> > wieder von FTP überzeugt.
>
> Ich glaub es will dich keiner von FTP ueebrzeugen, aber deine
> schlechte Meinung basiert auf den falschen Annahmen.
Aber eine Menge Leute wollen anscheinend davon überzeugen, dass FTP mit
SSL/TLS völlig unproblematisch ist. Da bin ich anderer Meinung.
Bernd Eckenfels
> Z.B. dass ich gerne ein schlüsselbasiertes Authentifizierungssystem
> hätte; wobei mir das mit WebDAV wesentlich einfacher machbar erscheint
> als mit FTP.
Ja, einfach die SSL Client Zertifikate nutzen.
Gruss
Bernd
Richard W. Könning
>On Mon, 3 Mar 2008 21:12:49 +0000 (UTC)
>Bernd Eckenfels <ec...@lina.inka.de> wrote:
>
>> > Um Sicherheit zu gewinnen und schlüsselbasierte Authentifizierung zu
>> > verwenden, muss ich mir eine CA aufziehen. Ich muss nach
>> > Implementierungen sehen, die Client-Zertifikate akzeptiert, prüft
>> > und schließlich mit einem bestimmten User assoziiert.
>>
>> Das gilt aber sowohl für HTTP/S (WebDav) als auch SSH sowie FTP oder
>> auch AS1/2/3. Ich sehe da keine Besonderheit bei FTP.
>
>OpenSSH assoziiert per ~/.ssh/authorized_keys System-User mit bestimmten
>Schlüsseln -- und das sogar in der Default-Konfiguration.
So etwas läßt sich auch in einen FTP-Server einbauen, wenn man es denn
haben will. Wenn es so etwas noch nicht gibt, dann war die Nachfrage
wohl zu schwach.
>> > Wenn du das kannst, wäre ich dir sehr dankbar. Dann wäre ich auch
>> > wieder von FTP überzeugt.
>>
>> Ich glaub es will dich keiner von FTP ueebrzeugen, aber deine
>> schlechte Meinung basiert auf den falschen Annahmen.
>
>Aber eine Menge Leute wollen anscheinend davon überzeugen, dass FTP mit
>SSL/TLS völlig unproblematisch ist. Da bin ich anderer Meinung.
Ich sehe nicht, wo FTP mit TLS problematischer ist. Das
Zertifikatshandling ist nicht mehr Bestandteil des FTP- oder des
TLS-Protokolls, sondern eine Frage der jeweiligen
Server-Implementation. Wenn die von Dir gewünschte Variante nicht
angeboten wird, dann liegt es mit großer Wahrscheinlichkeit an
mangelnder Nachfrage.
Ertugrul Söylemez
Richard W. Könning <Richard....@t-online.de> wrote:
> > OpenSSH assoziiert per ~/.ssh/authorized_keys System-User mit
> > bestimmten Schlüsseln -- und das sogar in der Default-Konfiguration.
>
> So etwas läßt sich auch in einen FTP-Server einbauen, wenn man es denn
> haben will. Wenn es so etwas noch nicht gibt, dann war die Nachfrage
> wohl zu schwach.
>
> > Aber eine Menge Leute wollen anscheinend davon überzeugen, dass FTP
> > mit SSL/TLS völlig unproblematisch ist. Da bin ich anderer Meinung.
>
> Ich sehe nicht, wo FTP mit TLS problematischer ist. Das
> Zertifikatshandling ist nicht mehr Bestandteil des FTP- oder des
> TLS-Protokolls, sondern eine Frage der jeweiligen
> Server-Implementation. Wenn die von Dir gewünschte Variante nicht
> angeboten wird, dann liegt es mit großer Wahrscheinlichkeit an
> mangelnder Nachfrage.
Ich zumindest konnte keine solche finden. "Problematisch" ist
vielleicht der falsche Ausdruck dafür gewesen, aber zumindest "weniger
flexibel als SSH-FTP oder Rsync/SSH". Mir bringt eine
Authentifizierungsmethode nichts, die super und toll ist, die aber
niemand implementiert.