The trouble is that when an FTP Client connects to an FTP Server, the Client
gets a "Control Channel". That's all fine and easy - he is still a client
and can do "normal" client stuff like accept the Server's certificate, etc.
However, when a Client does something like, say, request a file from the FTP
Server, the CLIENT creates a SERVER socket and sends its address over the
control channel to the Server. The FTP Server then connects back to the
Client using a CLIENT SOCKET. This means that the FTP Client would have to
so all the things that an SSL Server does, like sign Client Certificates,
etc. It's still quite possible, but that's the problem. If, however, you
aren't validating the Client and requesting Certificates from him, it's
probably not too bad.
Disclaimer: I am an SSL moron! I can barely get certificates generated for
my Server and Client software, and I can't get an SSL Handshake to complete
because the two ends can't agree on a Cipher suite. [I have no idea why, and
the code in 's3_lib.c(ssl3_choose_cipher) is fairly cryptic to the
uninitiated. I have no idea what the problem is except that a mask doesn't
compare favorably with the mask for any of the available ciphers. Any
help?] Keep that in mind when you're reading the above statements. I DO
know exactly how FTP works, as I've written both Client and Server code
before, so the parts above about how FTP works are indeed correct, but the
interaction with SSL may be in question. I think it's right, though.
I hope this helps a little, and if anyone can help me figure out what's up
with my SSL handshake trouble, I would appreciate it.
Bill Rebey
-----Original Message-----
From: Arun Venkataraman [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 16, 2000 1:37 PM
To: [EMAIL PROTECTED]
Subject: Re: FTP & SSL
-----Original Message-----
From: Michael Sierchio <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, June 16, 2000 10:14 AM
Subject: Re: FTP & SSL
>Arun Venkataraman wrote:
>>
>> This is an old gripe :( Ppl don't seem to have attempted seriously to use
>> SSL over something else other than http.
>
>Huh-wah? You have it backwards (HTTP over SSL). And there are
Oops! you are right.
>plenty of examples of LDAP, POP, SMTP and other protocols over
>SSL. FTP is inherently problematic (except if restricted to
>passive mode) because of the way connections are made -- SSL, itself
>running atop TCP, isn't really suitable for this.
>
>IPSec, SKIP, and other attempts to secure information at the
>packet level, are probably much better.
I wasn't aware of these technical difficulties. When I went over to
ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps it seemed like people had
successfully patched wu-ftpd, an ftp client and a telnet client to work with
SSL. However, all the patches etc. seemed out of date and meant for SSL-eay.
This made me wonder if it was simply a problem of updating those patches for
openssl.
Arun.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
