SSL Only with 168 Bit

Hello

I have connected to a Server with FLASHFXP. There it shows me a SSL COnnetion with 256 BIT.

Then i used SmartFTP and it shows me that the SSL Connection has only 168 Bit.

SETTING:
AUTH MODE: SSL
DATA CONNECTION MODE : Private Data Connection

Zertifikat from Server is installted


Please help, or is SmartFTP not able to crypt with 256 BIT?

Hello ..

The maximum length is 168bit (3DES) because the MS Schannel (the SSL Provider from MS) doesn't support anything higher.

Regards,

SSL Provider from Microsoft?
I connected to an Private Server.


And why Flash Fxp support 256 Bit?

mb is talking about the ssl encryption library he's using in smartftp. that one comes from microsoft and only supports up to 168 bits. obviously, flashfxp uses a different library.

OpenSSL supports AES-256. The Microsoft Schannel supports RC4 (up to 128bit) and 3DES (168bit). The AES cipher hopefully gets into Longhorn.

Regards,
-Mat

Thanks very much.

But i have installed OpenSSL.
And how can I use it? SmartFTP uses still 3DES....

you cannot use openssl with smartftp just because you have openssl installed ... smartftp needs to be programmed to use openssl. and this would be quite a lot of work, i guess, because the api is totally different.

Hello

I have connected to a Server with FLASHFXP. There it shows me a SSL COnnetion with 256 BIT.

Then i used SmartFTP and it shows me that the SSL Connection has only 168 Bit.

SETTING:
AUTH MODE: SSL
DATA CONNECTION MODE : Private Data Connection

Zertifikat from Server is installted


Please help, or is SmartFTP not able to crypt with 256 BIT?

Believe, you do not need more than 168 bit.
Increasing this value just makes transfers slow.

But i have more important question to smartftp developer:
Why this very nice ftp client does NOT supporting secure FXP transfers??
This make it almost useless for me
FlashFXP does support secure transfers and secure file listings for a long time.

SmartFTP was the first FTP client which supported SSCN. Actually we developed the SSCN command with raidenftpd together.

-Mat

Wow!
This is a very good news!
But let think about this:


SSL, like every authentication protocol based on public key exchange, relies on client-server trust relationship. Usually it's user it requires human intererence at client's end to verify validity of server certificate, sometimes server verifies client's key based on list of trusted keys (automated), and in certain implementations both client and server are verifying keys to ensure, that they both are who they claim they are.

In encrypted site to site transfers, neither of servers is doing the neccessary check to determinate that connection really is trusted. Lack of this check makes connection vulnerable to man-in-the-middle type attacks, and thus compromises security of transfered data - making it hardly a better choise, than not using encryption at all!

Does this make encryption useless? As currently implemented (SSCN, CPSV), yes. There is no way to verify that transfer has not been caught by third party. Luckily, there is rather simple fix for the problem. New command, that defines server what public key to expect. (each public key has unique certificate thumbprint)

C = Client
S1 = Server 1
S2 = Server 2


C - S1> TKEY
S1 - C> 200 Certificate thumbprint (sha1,t,h,u,m,b,p,r,i,n,t,1)
C - S2> TKEY
S2 - C> 200 Certificate thumbprint (sha1,t,h,u,m,b,p,r,i,n,t,2)
C - S1> TKEY t,h,u,m,b,p,r,i,n,t,2
S1 - C> 200 Client thumbprint set.
C - S2> TKEY t,h,u,m,b,p,r,i,n,t,1
S2 - C> 200 Client thumbprint set.
C - S2> CPSV
S1 - C> 227 Entering Passive Mode (192,168,1,10,2,191)
C - S2> PORT 192,168,1,10,2,191
S2 - C> 200 PORT command successful....


© ioftpd forum...

What you think about this?