Total Commander

TC supports encrypted FTP connections, which is great, because using FTP with clear-text login is very bad idea. Unfortunately, TC does not support encryption out of the box. Users need to download OpenSSL dlls and judging from both questions in this forum and personal experience, it's just too complicated for many of them. And even if they do manage to install these, I seriously doubt that many of them watch for security announcements and do updates. I dare to guess that most users simply use some horribly outdated OpenSSL dlls installed long time ago, because they still work. So much for security.

I understand that original reason for not including encryption were some "funny" Swiss laws against exporting cryptography. I don't know if they still apply (hard to believe in 2016, but everything is possible). But if TC can call OpenSSL API, it can also call Windows cryptography API, I don't see any difference in that. I don't have any programming experience with that myself, which would be worth mentioning. But it seems that full set of features (including TLS 1.2) should be available at least since Windows 7. So even if it was not available for older versions (I can't say for sure), I think it would be worth to support it (XP is already out of support and Vista will soon be too). Older systems can still use OpenSSL.

Benefits are obvious, encryption available for everyone and always up to date (depends on users updating their systems, but most do, because it happens automatically).

Even libssh2 (used by SFTP plugin) looks like it can work without OpenSSL and use Windows API instead. I'm going to test that, when I have time.

The biggest problem of openssl dlls is the frequent updates - they often have security holes. I would have to constantly offer updates for TC since every update takes at least a month to prepare with beta test, there wouldn't be any time left for adding new features...

And that's one of reasons why I suggest to basically get rid of OpenSSL. And instead use Windows native functions. I know they exist, few years ago I tried to play with something called Schannel, but unfortunately not for too long, so I can't offer much insight. Now it seems that since Vista it's somewhere in Cryptography API: Next Generation.

You can't just get rid of OpenSSL as long as TC supports older versions of Windows, where the required functions might not exist. The usage of the Windows Crypto API may be added, but I don't think its a good idea to drop OpenSSL, at least not yet.

[OT]
I'm really glad that Wget doesn't use Windows Crypto API but its own, so it can still download from HTTPS sources where native functions fail (due to IE8 not supporting TLS on XP).
[/OT]

Regards
Dalai

See my first post, I did not say to get rid of it completely and unconditionally. It's still the only way how to get good encryption with older systems. And if it's there and works, it can still be an option even for newer Windows versions, if someone wants to use it.

But if TC was able to use what Windows provide, it would make encryption available by default and that would be huge advantage. Ok, only for users with newer Windows. But with newer being Windows 7 and up, it's at least 80% of current Windows users and that number will only go up over time.

I'm already using CryptoAPI for things like faster MD5/SHA1/SHA2 calculations. But reimplementing the entire FTPS framework myself via CryptoAPI is completely beyond my capabilities. There are far too many different servers out there which have their problems, which need to be addressed in such a library.

history.txt wrote:13.09.16 Added: HTTPS connection without the need for OpenSSL, using the sChannel functions from Secur32.dll (32/64)
11.09.16 Added: FTPS connection without the need for OpenSSL, using the sChannel functions from Secur32.dll (32/64)

Looks like your capabilities improved in last few months.

First impression is good, it works. Except (sorry ):

1) Ftp log no longer shows info about used protocol ("Method: TLSv1.2" line).

2) I came across one https site where all downloads get stuck at the end and TC retries again and again. When I close the transfer (it doesn't want to give up), resulting file is ok, correct size and content. Tested with clean ini on two different computers and networks. It works ok with OpenSSL. File to test is https://live.sysinternals.com/tcpview.exe. There are also some logs from TC: http://web.hisoftware.cz/sob/tc/https-error1.7z

Looks like your capabilities improved in last few months.

Nope, I found a good example code (in C) where it was used. Yes, it's quite complex, but thanks to the sample I could finally understand how the functions work.

1) You are right - and TLS 1.1 and 1.2 were not even enabled! I will change that.

2) I can reproduce it and will check it in the debugger.

Both problems are solved and I didn't find any new ones so far.

One more suggestion: In addition to used protocol, it might be interesting to show also info about used algorithms, if there's an easy access to it. OpenSSL provides the info using SSL_get_current_cipher(), for SChannel I don't know.

I have indeed considered this. The same function which provides info about the SSL/TLS protocol version also seems to provide cipher info:
pSSPI->QueryContextAttributes( phContext,SECPKG_ATTR_CONNECTION_INFO,pConnectionInfo);

It returns SecPkgContext_ConnectionInfo structure.

However, it returns dozens of algorithms, see this list. I don't really have the time to create huge switch() statements for all these ciphers...

The current version (10.x) supports SSL out of the box.

Thanks.