Information on how to use the ssl/tls feature for secure ftp
Moderators: white, Hacker, petermad, Stefan2
- ghisler(Author)
- Site Admin
- Posts: 48104
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Unfortunately the OpenSSL dlls from OpenSSL.Org now require the MS VC++ 2008 runtime, which cannot be installed on an USB stick.
Solution: Use the dlls from the libcurl package:
http://curl.haxx.se/download.html
Please scroll down to the section named "Win32 - Generic"
and download the following package (or a newer one):
Win32 2000/XP 7.18.2 libcurl SSL enabled Günter Knauf 1.54 MB
Solution: Use the dlls from the libcurl package:
http://curl.haxx.se/download.html
Please scroll down to the section named "Win32 - Generic"
and download the following package (or a newer one):
Win32 2000/XP 7.18.2 libcurl SSL enabled Günter Knauf 1.54 MB
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
- ghisler(Author)
- Site Admin
- Posts: 48104
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
FYI: up-to-date openssl libs (libeay32.dll + ssleay32.dll + zlib1.dll) with mozilla's certificate list (cert.pem) built for windows xp or newer for both x86 and x64 can be found on the xchat-wdk site, google for openssl-wdk (i can't post links just yet). it just works, no need for the vc redist.
i think we could work on an openssl installer made specifically for total commander, i'd gladly participate and keep you updated, but some kind of hosting would be nice (i could host them on the xchat-wdk site but it's just not the way it should be done imho).
i think we could work on an openssl installer made specifically for total commander, i'd gladly participate and keep you updated, but some kind of hosting would be nice (i could host them on the xchat-wdk site but it's just not the way it should be done imho).
- ghisler(Author)
- Site Admin
- Posts: 48104
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
2gulikoza
Can you post a log of the failing ftp connection? CCC is supported by TC, it should send the command, and then immediately switch to clear. Unfortunately none of the servers I tried supports CCC (FileZilla, RaidenFTPd, Pure-FTPd), so I cannot test it right now. TC expects that the reply to CCC is still encrypted, but after that the connection is clear.
Btw, why do you need CCC?
Can you post a log of the failing ftp connection? CCC is supported by TC, it should send the command, and then immediately switch to clear. Unfortunately none of the servers I tried supports CCC (FileZilla, RaidenFTPd, Pure-FTPd), so I cannot test it right now. TC expects that the reply to CCC is still encrypted, but after that the connection is clear.
Btw, why do you need CCC?
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Passive mode still needs to inspect control channel on the server to open proper ports (unless static ports are assigned to ftpd server). CCC seems like a good compromise between security and usability...
If I put CCC in send commands then ftp is not completely opened (the ftp toolbar does not appear) so I cannot post the log. Similarly, if I type CCC after the connection and then do a directory refresh, it will not be completed. I'll give you the login details to my ftp server on the PM (no PM...e-mail then
)
If I put CCC in send commands then ftp is not completely opened (the ftp toolbar does not appear) so I cannot post the log. Similarly, if I type CCC after the connection and then do a directory refresh, it will not be completed. I'll give you the login details to my ftp server on the PM (no PM...e-mail then
![Very Happy :D](./images/smilies/icon_biggrin.gif)
I did few tests. CCC in Send commands:
1) works fine with IIS FTP 7.5 (available for free in Windows Vista/2008 and newer)
2) does not work with Gene6 FTP Server (shareware, www.g6ftpserver.com), but it seems to be server fault.
From user perspective there's FTP connection window and everything is fine up to the point when CCC is sent to server. Code 200 reply can be clearly seen for brief moment and then connection window simply disappears. All subsequent attempts to connect to any FTP server end with TC unable to resolve address.
On network level (packet sniffer is our friend) there's usual encrypted connection first, then the encryption is switched off and TC's plain-text PWD is visible. But the reply packet from server is "binary garbage", so probably still encrypted. The PWD command does not appear in server log either.
1) works fine with IIS FTP 7.5 (available for free in Windows Vista/2008 and newer)
2) does not work with Gene6 FTP Server (shareware, www.g6ftpserver.com), but it seems to be server fault.
From user perspective there's FTP connection window and everything is fine up to the point when CCC is sent to server. Code 200 reply can be clearly seen for brief moment and then connection window simply disappears. All subsequent attempts to connect to any FTP server end with TC unable to resolve address.
On network level (packet sniffer is our friend) there's usual encrypted connection first, then the encryption is switched off and TC's plain-text PWD is visible. But the reply packet from server is "binary garbage", so probably still encrypted. The PWD command does not appear in server log either.
I see something similar with proftpd. With packet sniffer after CCC, PWD is visible, then some garbage then another pwd but the reply from the server is clear text this time, but TC seems to be already out of sync...
edit: bah, it must have been some previous connection. This time I'm only seeing a single PWD and encrypted response. I'll see what I can find out in the proftpd sources...
edit: bah, it must have been some previous connection. This time I'm only seeing a single PWD and encrypted response. I'll see what I can find out in the proftpd sources...
Does TC correctly support bidirectional SSL shutdown on CCC?
Here's a bug report for proftpd that mentions this kind or error (and hanging client) can occur if TLS is not properly closed on the client as well:
http://bugs.proftpd.org/show_bug.cgi?id=2994
Here's a bug report for proftpd that mentions this kind or error (and hanging client) can occur if TLS is not properly closed on the client as well:
http://bugs.proftpd.org/show_bug.cgi?id=2994