Archived Forum Post

Index of archived forum posts


FTP2 SSL/TLS and SSH ciphers, FREAK attack

Mar 17 '15 at 12:30


Yesterday there were news about FREAK attack, where SSL/TLS client announces support for unsecure ciphers in handshake.

More info about FREAK Attack

In this finding, the TLS_RSA_EXPORT_WITH_DES40_CBC_SHA cipher is vulnerable, and should never be used. NEVER!

Now I would like to know, what ciphers chilkat FTP2 announces/supports?

I think that chilkat should DEFINATELY add a new feature for FTP2 - SSL/TLS and SSH/SFTP where I can create a list of ciphers that I want to accept. This feature should allow me to create a list of ciphers, and also order them, so I could say, for example:

I only want to connect to succeed if AES-256 CBC is supported OR Twofish-256 CBC is supported.

As said, this is just an example.

There is already SFTP.ForceCipher where I can tell that only 1 of those ciphers should be accepted, but this is only a halfway solution. I want to be able to create a LIST and PRIORITIZE that list of the available ciphers that are accepted. This could be something like

SFTP.AcceptCiphers("aes256-cbc", "aes128-cbc", "twofish256-cbc", "twofish128-cbc");

so on connect, cipher is selected from that list, in that order. Currently SSH / SFTP has a list like this:

"aes256-cbc", "aes128-cbc", "twofish256-cbc", "twofish128-cbc", "blowfish-cbc", "3des-cbc", "arcfour128", "arcfour256"

and you should look at the "arcfour128", "arcfour256", COME ON, SERIOUSLY, RC4 was invented 1987, and its wikipedia page tells:

In March 2013, there were new attack scenarios proposed by Isobe, Ohigashi, Watanabe and Morii,[24] as well as AlFardan, Bernstein, Paterson, Poettering and Schuldt that use new statistical biases in RC4 key table[25] to recover plaintext with large number of TLS encryptions.[26][27]

The use of RC4 in TLS is prohibited by RFC 7465 published in February 2015.

The forementioned component.AcceptCiphers() of course applies to all chilkat components that uses SSL/TLS (like smtp component).

So what do you think? It is about time to take these security considerations seriously (not meaning just chilkat, but in general, all of us), its wild wild west called Internet we use to communicate. And its definately NOT a safe place.

And finally, what code you use for encryption, you have mentioned that you do NOT use openssl, then what it is? Crypto++?


In the next few days, Chilkat v9.5.0.48 will be released with a new property named SslAllowedCiphers. This is how the reference documentation will read:

Provides a means for setting a list of ciphers that are allowed for SSL/TLS connections. The default (empty string) indicates that all implemented ciphers are possible: aes256-cbc, aes128-cbc, 3des-cbc, and rc4. To restrict SSL/TLS connections to one or more specific ciphers, set this property to a comma-separated list of ciphers such as "aes256-cbc, aes128-cbc". The order should be in terms of preference, with the preferred algorithms listed first. The server however, chooses from among the algorithms listed.

This property will be added to Ftp2, MailMan, Imap, Socket, and Http. If you wish to test, please let me know your exact programming language, operating system, architecture, etc. so I can provide the needed build.

Also, the SSH/SFTP ForceCipher property will also be extended to allow for a comma-separated list of accepted ciphers (in order of preference). The Ssh/SFtp ForceCipher property will be extended after v9.5.0.48 is released -- which means it won't appear until v9.5.0.49.

Note: The supported ciphers in SSH are not the same as those in Chilkat's SSL/TLS implementation. For example, both include AES, but SSH allows for TwoFish and Blowfish whereas SSL/TLS does not.


Wow, its 2:48AM here in Finland, and I just came to check my computer for any possible answers to this my request. And didnt really think that there would be anything, but thought that I would check. And then this...BOOOMM... just after 10 hours, after I wrote my request/message, you got an reply. Insane.

Chilkat, this is beautiful :-) Stupid thing, that I cannot call you with your name(s), (like: Hi, I am Matt, nice to meet you), but I would really like to thank you for acting SUPER fast. You implementation is EXACTLY as it should.

One extra thing, how about a new SFTP.SSLAcceptedCipher property that would contain the cipher, as a result of the initial handshake after the connection, so I could show it to my user, or print it into a log file. What do you think?

And as a final note, chilkat, can I give you a call some day? I can clearly see that you are bright guy(s)/girl(s), and I would like to talk to you to exchange few ideas, and talk about a project I am working on. No need to comment on public what you think, just drop me an email to let me know. If that suits you, I not, not a biggie, no hard feelings.

I need to end this msg to similar words I did my previous request: chilkat you are doing a GREAT job!

And final, final, Im using Visual Studio 2013 C# .NET 4.51. So please get the dlls coming :-)

Cheers, Matt



Thanks! I'm very happy to help. My name is also Matt (all posts by Chilkat are from me)..

Prior to your post, I was likely to begin releasing v9.5.0.48 today. But instead I thought this was worth adding, and implementing it was trivial so the risk of introducing some new problem is minimal. I'm punting on the SSH ForceCipher enhancement because that is slightly non-trivial -- and it can be made available as a v9.5.0.49 pre-release once all the builds for .48 are out (which can take a few days).

Yes, the AcceptedCipher property is a good idea. I think it's good to make it explicitly known what algorithms (ciphers, hash, etc.) are in use for a given connection.

I'll post the download for the Visual Studio 2013 C# .NET 4.51 pre-release shortly..



Hi Matt,

Perfect! But stop, and take your time to implement this correctly. Think a while, dont rush, as we both well know, we do mistakes when in hurry. World will not end, it can wait few days.

And Matt, drop me a note to my email so we can talk out of these boards.

Yours, Matt


Here are the new builds:

32-bit Download:
64-bit Download:

Don't worry -- I already took my time on it and it wasn't a rush..



Matt, now that was fast :-) Its now 4:00AM here, so I better get to bed, but I'll test these tomorrow. Many thanks!

Did you see this on

Quite scary where they show how was shown with MITM attack. Not quite, really scary. And think how long it will take until all browsers (like all android phones in the world) have been fixed, and all servers. Damn, this is a BIG one.


I've been testing new build for a while, and could not really verify if its working properly or not, as ftp2.LastErrorText does not show what cipher was selected for connection.

            allowedTlsCiphers: aes256-cbc
                    modulus_bitlen: 2048
                    littleEndian: 1
                    padding: PKCS 1.5

So that logging should be added, along with fore mentioned ftp2.SSLAcceptedCipher. One extra question: The FREAK was all about initial handshake, where asymmetric RSA key exchange was negotiated down to 512-bits, from default 2048-bits (if I understood FREAK correctly). And ALSO that there is a bug in openssl, where 512-bit RSA was used even when client didnt even announce support fot it. So does this .SSLAllowedCiphers also now cover that, as it looks like its only dealing with symmetric cipher selection (like aes, twofish, blowfish, 3des) thats used AFTER top level asymmetric RSA key exchange completed?

The particular phrase what I try to understand in

A connection is vulnerable if the server accepts RSA_EXPORT cipher suites and the client either offers an RSA_EXPORT suite or is using a version of OpenSSL that is vulnerable to CVE-2015-0204

Note the word OR in that line. So does SSLAllowedCiphers now fix BOTH of these issues? As said, SSLAllowedCiphers does not seem to talk about RSA at all, only symmetric ciphers? Maybe I am missing something, or just dont get it...

Final note: the ftp2.RequireSslCertVerify default value of false is terrible. When 95% of coders using chilkat have no or little clue on what this means, they happily run ftp2 with default settings. And having that, there is no need to even play with FREAK stuff, all that is needed for successful MITM attack is to present some self-signed certificate and ftp2 and coder is happy. Not even realizing what is really happening. Not very secure. But surely this makes coders happy as TLS connections always succeed, even when connecting to totally wrong server, and coder not realizing that they are actually talking to man in the middle, not to server they intended. But I do understand that changing this ftp2.RequireSslCertVerify default value to true now, will break a lot of connections. But, well, its up to you how you wanna play this.


Here's another new build:

32-bit Download:

64-bit Download:

(Same URLs as before, but updated)

This has the following changes:

  1. With VerboseLogging, you'll see the chosen cipher in the LastErrorText. However, the LastErrorText will not contain this information for data connections because in synchronization method calls where potentially thousands of data connections could occur, the log would become much too large.
  2. By default, Chilkat will no longer allow any RSA keys for SSL/TLS (including both client-side and server-side RSA keys) that are less than 1024 bits.
  3. To allow for 512 bits or above, add "rsa512" to the list of algorithms in the SslAllowedCiphers list. To allow only 2048 bits or above, add "rsa2048" to the list of algorithms. (Adding "rsa1024" chooses the same as the default.)


Sounds like this would cover all bases, excellent, I will try these...


  1. To allow for 512 bits or above, add "rsa512" to the list of algorithms in the SslAllowedCiphers list. To allow only 2048 bits or above, add "rsa2048" to the list of algorithms. (Adding "rsa1024" chooses the same as the default.)

Adding "rsa512" or "rsa2048" doesn't work for iOS socket library. From documentation adding aes256-cbc, aes128-cbc, 3des-cbc, or rc4 worked, but how to set the key length say "aes256-cbc2048"