PDA

View Full Version : Encrypting directory listings but allowing fxp transfers


esmandil
10-05-2004, 05:43 AM
Hello,

I would like to make sure directory listings are sent only over encrypted data channel. On the other hand, I need my server to do FXP transfers, so requiring encrypted data connection all the time doesn't work.

It has occurred to me that what I really want is to allow LIST command over protected data channel only, while allowing STOR and RETR over unprotected data channel as well. This should work, right? Or is there anything more I need to worry about?

I don't think it can be done right now, though. I can use [FTP_Pre-Command_Events] to control access to LIST command, but there is (as far as I know) no way to check whether current connection is encrypted or not.

May I ask for a new cookie, maybe? Or a flag? One which would tell the state of control connection (no auth, ssl, tls etc) and state of data connection (clear or private)?

I am new to ioFTPD, so it is quite possible that there is an easier way of doing what I want to do... Does anybody have any idea?

Rusher
10-05-2004, 06:10 AM
in ioFTPD.ini
at the line
Require_Encrypted_Data = !-user !-user *

when there is no ssl/tls available its not requierd. and when there is it will use it.

so add the users there that you dont want to force ssl/tls on.

esmandil
10-05-2004, 09:39 AM
Thanks, but that's not what I need. I want to require ssl on LIST *for all users* and allow clear text on STOR / RETR *for all users* as well.

Rusher
10-05-2004, 10:30 AM
try

Require_Encrypted_Data = !*

or that might just disable list also. dont know =) good luck.

esmandil
10-06-2004, 05:29 AM
Yes, Require_Encrypted_Data = !* allows LIST over non-encrypted data connection as well.

Right now the best thing I have is to disallow LIST command completely, forcing people to use STAT -L to get directory listing over control connection.

Mouton
10-06-2004, 07:38 PM
Not only the best way to do it; also the only way to do it.

esmandil
10-07-2004, 06:09 AM
OK, thanks, good to know :-)