OpenSSL 1.0+ for ioFTPD?

[urskog]

Hi!

Many sites are upgrading to OpenSSL 1.0+ (http://www.openssl.org/news/) and I would like to do the same for my install of ioFTPD.
Is this possible?
And if so, how to best go about it?

Thanks :)

[Yil]

What version are you using now? ioFTPD v7.7.3 (latest released) uses 1.0.0d which should do everything you want. You can also grab any newer compiled OpenSSL library from elsewhere and drop it in and it should work if you want to try that.

[urskog]

Currently running 7.0.3, maybe I should spend the time to upgrade to 7.7.3 while at it, it just works so great that I'm afraid to touch it :)
Adding 1.0+ by "dropping it in", will that add 1.0+ and keep the old versions also, or will it switch all SSL to 1.0?
Preferrably I would like to keep the older versions also to be able to FXP with sites that haven't updated yet.

[Yil]

7.0.3 is very old. In fact I don't think ioFTPD switched to OpenSSL until like v7.4. 7.7.3 should be much more stable than 7.0.3 was under load.

More importantly the microsoft encryption libraries used in v7.0.3 can't be upgraded by using the OpenSSL libs so if you want to use the new features you'll have to upgrade.

Not sure if it's easier to follow the upgrade directions for the releases between yours and the latest, or just use a file difference tool to see what changed and merged the files. Either way just make a copy of your current ioFTPD dir when the server isn't running so you'll have a fallback if you goof something up :)

[urskog]

Ok, thanks for the help.
Guess I'll have to bite the bullet and upgrade everything :)

[slacker666]

I also am in need of this, we need a certificate for ECDSA, the old RSA is not secure. Simply putting new SSL files (OpenSSL v1.0.1 wont be sufficient). See glFTPd :: We make files transfer! (http://www.glftpd.eu) who supports ECDSA since the autumn of 2013.

Yil: I think there needs to be some coding done to get this right, can you help us?

[Yil]

What cypher do you get connecting to glFTPD these days? On ioFTPD you should get ECDHE-RSA-AES256-SHA in most cases. The leading EC is the new elliptic curve stuff which I think means the cipher is more secure now because it's using a unique one-time key per connection now or something. That does require separate support not found in old glftpd, but ioFTPD already does this. On the other hand, it's possible to sign certs with something stronger (2048 vs 1024, DHE, EC) but I don't know how compatible that is with older FTPs. See what the glFTPD cert signature uses if you're curious since it should say which methods it uses. In all honesty though I don't think that buys a lot since most servers just self-sign the cert which means the signature is pretty useless since it can't be verified, and the new ECDHE stuff ioFTPD already supports makes the negotiated key more secure.

If anyone really knows this stuff feel free to chime in :)

[slacker666]

ECDHE-ECDSA-AES256-SHA-256 is the latest/newest glFTPD cipher. The RSA is outdated and needs to be changed. RSA and ECDSA is not 100% compatible and therefore ioFTPD needs an update.
glFTPD v2.04 has an option to make older RSA certificates obsolete/incompatible with the ECDSA certificate, because RSA contains security bugs, ECDSA only is prefered in glFTPD (sending from RSA sources to ECDSA in glFTPD where ECDSA is the only certificate available will render 0byte files from RSA certs). Thus older glFTPDs are not compatible depending on the admin's settings in newer glFTPD since RSA is not wanted any more.
Read more about the bug here (http://scenenotice.org/details.php?id=2177)

[Yil]

They seem to agree with me. The key there is the ECDHE which ioFTPD already uses. Their suggestion to use ECDSA certs to force old sites to fail in negotiation is a good way to get people to upgrade but very annoying since it breaks compatibility... Is there a problem sending or receiving to new glftpd servers at the moment? I'm not aware of any issues there since I think ECDHE cipher (and not cert) support should be all that's needed for interoperability and that gets you the per-connection unique encryption which is the whole point of this.

I'll play around with a new OpenSSL library build just to see what happens. I already know from previous testing that we can get a speedup on newer processors avoiding the hand-coded assembly routines which my builds use. That doesn't seem right, but evidently they were hand coded for old processors and never updated LOL...

[slacker666]

Yes, as glFTPd admins are aware of security, they have abandoned the old DSA cipher and switched to ECDHE instead, making most FXPs incompatible.
Would very much like an upgrade to ECDHE ciphers, thank you in advance!

[MxxCon]

It looks like there's some confusion about what all these abbreviations actually mean.
Cipher suites follow the same naming convention. I'm quoting Wikipedia here:
Each named cipher suite defines a key exchange algorithm (https://en.wikipedia.org/wiki/Key_exchange_algorithm), a bulk encryption algorithm (https://en.wikipedia.org/wiki/Encryption_algorithm), a message authentication code (https://en.wikipedia.org/wiki/Message_authentication_code) (MAC) algorithm, and a pseudorandom function (https://en.wikipedia.org/wiki/Pseudorandom_function) (PRF). (RFC 5246 (https://tools.ietf.org/html/rfc5246), p. 40)


The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake. (RFC 5246 (https://tools.ietf.org/html/rfc5246), p. 47).
The bulk encryption algorithm is used to encrypt the message stream. It also includes the key size and the lengths of explicit and implicit initialization vectors (https://en.wikipedia.org/wiki/Initialization_vector) (cryptographic nonces (https://en.wikipedia.org/wiki/Cryptographic_nonce)). (RFC 5246 (https://tools.ietf.org/html/rfc5246), p. 17)
The message authentication code (MAC) algorithm is used to create the message digest (https://en.wikipedia.org/wiki/Message_digest), a cryptographic hash (https://en.wikipedia.org/wiki/Cryptographic_hash) of each block (https://en.wikipedia.org/wiki/Block_%28telecommunications%29) of the message stream. (RFC 5246 (https://tools.ietf.org/html/rfc5246), p. 17)
The pseudorandom function (PRF) is used to create the master secret, a 48-byte secret shared between the two peers in the connection. The master secret is used as a source of entropy when creating session keys, such as the one used to create the MAC. (RFC 5246 (https://tools.ietf.org/html/rfc5246), p. 16-17, 26)

Examples of algorithms used
key exchange/agreementRSA (https://en.wikipedia.org/wiki/RSA_%28algorithm%29), Diffie-Hellman (https://en.wikipedia.org/wiki/Diffie-Hellman), ECDH (https://en.wikipedia.org/wiki/Elliptic_Curve_Diffie-Hellman), SRP (https://en.wikipedia.org/wiki/Secure_remote_password_protocol), PSK (https://en.wikipedia.org/wiki/Pre-shared_key)
authenticationRSA (https://en.wikipedia.org/wiki/RSA_%28algorithm%29), DSA (https://en.wikipedia.org/wiki/Digital_Signature_Algorithm), ECDSA (https://en.wikipedia.org/wiki/Elliptic_Curve_DSA)
bulk ciphersRC4 (https://en.wikipedia.org/wiki/RC4_%28cipher%29), Triple DES (https://en.wikipedia.org/wiki/Triple_DES), AES (https://en.wikipedia.org/wiki/Advanced_Encryption_Standard), IDEA (https://en.wikipedia.org/wiki/International_Data_Encryption_Algorithm), DES (https://en.wikipedia.org/wiki/Data_Encryption_Standard), or Camellia (https://en.wikipedia.org/wiki/Camellia_%28cipher%29). In older versions of SSL, RC2 (https://en.wikipedia.org/wiki/RC2) was also used.
message authenticationfor TLS, a Hash-based Message Authentication Code (https://en.wikipedia.org/wiki/HMAC) using MD5 (https://en.wikipedia.org/wiki/MD5) or one of the SHA hash functions (https://en.wikipedia.org/wiki/Secure_Hash_Algorithm_%28disambiguation%29) is used. For SSL, SHA (https://en.wikipedia.org/wiki/Secure_Hash_Algorithm_%28disambiguation%29), MD5 (https://en.wikipedia.org/wiki/MD5), MD4 (https://en.wikipedia.org/wiki/MD4), and MD2 (https://en.wikipedia.org/wiki/MD2_%28cryptography%29) are used.This Mozilla page has a lit of recommended preferred Cipher suites. https://wiki.mozilla.org/Security/Server_Side_TLS

[slacker666]

Right, good clarification. So the authentication needs to be updated to ECDSA in order to get SSL working between newer glFTPd and ioFTPD.

[Yil]

Let's use what mxxcon's post shows against what I get using a v4 FlashFXP connecting to ioFTPD: ECDHE-RSA-AES256-SHA

Key exchange: ECDHE
authentication: RSA
bulk: AES256
message auth: sha

As I keep trying to point out the ECDHE is the important part. Check out the little blurb at Elliptic Curve Diffie–Hellman Exchange (ECDHE) (http://ecdhe.com/). The trick here is the exchange to get an AES256 key they both use (which is what the actual data is encrypted using) is done in such a way that it's unique, one time, and not based on the certificate itself anymore. I think they call that perfect forward secrecy. This makes everything much safer against replay and someone getting the server's .pem file. In order to support ECDHE BOTH sides need to support it and ioFTPD has from the start of the switch to OpenSSL back in v7.4.

There is no doubt that glftpd is using a better method to authenticate a server's certificate (ECDSA, note that isn't ECDHE!), but it's essentially meaningless if the certificate is self-signed which I bet all of them are. You can easily MITM (man-in-the-middle) a self-signed cert so I really don't see the point of trying to make that part more secure. glFTPD's trick to only issue EC signed certs has the effect of breaking old non-EC supporting OpenSSL libraries, but ioFTPD should accept that cert and use it just fine so far as I can tell because we do support EC! The only difference is ioFTPD doesn't authenticate/sign it's OWN certs via EC (we just use the default RSA) so it doesn't break compatibility... Does that make sense?

Slacker666: The real question is. Does ioFTPD have trouble sending or receiving connections from the latest glftpd? I assume you think it does, but I haven't heard of anybody else having issues.

[slacker666]

Right, I asked an admin of glFTPd, who claims ioFTPD's ECDHE-RSA-AES256-SHA should be compatible with glFTPd's new ECDSA auth. It depends on the correct pasv/active combination in order to get it to work.
So my bad, sorry about that.

[urskog]

7.0.3 is very old. In fact I don't think ioFTPD switched to OpenSSL until like v7.4. 7.7.3 should be much more stable than 7.0.3 was under load.

More importantly the microsoft encryption libraries used in v7.0.3 can't be upgraded by using the OpenSSL libs so if you want to use the new features you'll have to upgrade.

Not sure if it's easier to follow the upgrade directions for the releases between yours and the latest, or just use a file difference tool to see what changed and merged the files. Either way just make a copy of your current ioFTPD dir when the server isn't running so you'll have a fallback if you goof something up :)

How would I best do this, with the least possible amount of trouble?
1: Copy the whole installation to another directory
2: Install the 7.7.3 over the copied version
3: Check the differences between my old ioftpd.ini and the newly installed one and copy the missing parameters one by one
Does that seem right or am I missing something?
Did you do any breaking changes that could cause my sitebot or ioninja to stop working?

Thanks for any tips :)

[Yil]

Here's what I'd do. With the server offline make a backup of the ioFTPD dir into a zip/rar just in case you edit/delete the wrong file. Then rename the ioFTPD dir to ioFTPD-old. Then extract just the ioFTPD.ini file from the original zip file you downloaded for your 7.0.3 release and stick into into ioFTPD-old/system/ioFTPD.orig or something like that. Grab a free file differencing tool like WinMerge (http://winmerge.org/) and compare ioFTPD.ini to ioFTPD.orig. This will show you any modifications you made to your current server from the default configuration which you now easily review.

Now extract the new ioFTPD release and edit the ioFTPD.ini as you want. Do go through it since there are tons of new features. By using WinMerge or just looking at the old ioFTPD.ini file you can see what you chose previously and copy things like Sections, VFS, etc over where it makes sense.

Trying to use WinMerge on the new ioFTPD.ini to your old will probably generate too many differences so that's why I suggested comparing against the old unmodified one.

Now that you have a new ioFTPD.ini file, just copy the /etc, /users, /groups, and /scripts dirs from ioFTPD-old. If you use nxTools you might need nxHelper, etc from the /lib dir as well. And double check what the old ioNiNJA required (like twapi maybe?), but I'd suggest upgrading ioNiNJA to the latest so you can just follow it's install requirements... Enable helpfile support for them in the .ini file as well :)

If you use merged directories in the .vfs file you may need to re-order them as I think we use the first dir listed instead of the last now but not many people use that feature.

[Dahlia]

Back to the topic. So is there any way how to upgrade current ioFTPD Encryption algorithm from "TLSv1 ECDHE-RSA-AES256-SHA-256" to "TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384-256"? I started having troubles with some sites when i try fxp. I get this error:

:ftprush:
[glftpd] 426 Connection closed
Transfer Failed: 50MB
[ioftpd] 435 Failed TLS negotiation on data channel (SSL_connect(): (1) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol), disconnected



Thx for any response.

[Hans_]

Hi Dahlia,

replace the following 2 dll files in ioFTPD/system directory with the newly released ones:

libeay32.dll and ssleay32.dll

voila..5 Euros wired to my account please :)

[TeRRaNoVA]

Not work, if it was that simple, ioftpd have no TLSv1.2 support or am i mistaken. Cannot connect to ioftpd TLS1.2 and fxp to/from TLS1.2 glftpd site not work. Is there a solution coming please ?

First step:

Install OpenSSL 1.0.1j for windows on your machine.

Second step:

Copy the following files from C:\OpenSSL-Win32

libeay32.dll
libssl32.dll
ssleay32.dll

to ioFTPD\system and replace them!

Last stap:

Restart you iOFTPD



Greatz

/TeRRaNoVA

[Yil]

It appears that the glftpd v2.05 Changelog includes this change "Change: disabled SSLv3 support (SSLv2 was already disabled)". That means that glftpd won't accept a SSL v2 or v3 hello message and thus won't connect using either of those methods, but it should have tried TLS as well since the default is to try all 3. However it also includes line "New: added new config options ALLOWED_PROTOCOLS that allow you to decide which TLS protocols are allowed by the sever. You can specify one or more out of : TLSv1, TLSv1.1, TLSv1.2 (Default is to allow only TLSv1.2)"

The older SSL libs don't support TLS 1.2 so you'll have to upgrade them. See posts above for people who have already done this.

If that doesn't work try making this change in the ini file. Under [FTP_Service] change Encryption_Protocol to TLS. This affects all connections which means that users using SSL2/3 won't be able to login to your FTP until they change to TLS encryption in their site settings. However it may solve the glftpd compatibility problem you are seeing. You may need to restart ioFTPD after making this change as I don't remember if changing this settings triggers the service connection (from which data connections are spawned) to be recomputed.

If you're friendly with a glftpd admin for testing you can see what happens if they change that ALLOWED_PROTOCOLS settings to allow TLS v1 and/or v1.1 just to see if that change alone would fix things.

[Yil]

Track down some 0-byte files in the xferlog, see who the uploader was and/or track the source IP address by relaxing the hide-ip settings to show part of the ip address instead of hiding the whole thing (if you have that enabled) . You can then see if there is a pattern such that all the 0-byte files come from one sender or one site and then see if you can figure out what makes it special...

I seem to remember way way back the number one reason for some 0-byte files was the sender didn't have enough credits LOL.

[Hans_]

small question:

does any1 have a problem with the newest SSL Update (1.0.2g and 1.0.1s) in combination with ioftpd?

when starting ioftpd following message is presented:

"The ordinal 114could not be located in the dynamic link library SSLEAY32.dll"

[Sepp]

ioFTPD is referencing ordinal 114 in ssleay32.dll which is ssl2 method function which was dropped in 1.01s libs for security reasons.
just use cff explorer or a hexeditor to change it to 117 (75h).
RaidenFTPD has got the same problem.

[mr-b]

Here you go:

ioFTPD ssl tempfix (https://mega.nz/#!KUclDKaJ!kxYSMdVFLzOFitE98NXRdQNUdBJghxNtIykP8vh S5Ng)

Quick temp fix for OpenSSL 1.0.2g+ where SSLv2 has been removed.

I changed the following lines in ioFTPD/src/services.c:

if (! _tcsicmp(tszEncryptionProtocol, _TEXT("SSL2")) ||
! _tcsicmp(tszEncryptionProtocol, _TEXT("SSL")))
{
//Method = SSLv2_method();
//lpService->bTlsSupported = FALSE;
Putlog(LOG_ERROR, _T("ERROR SSLv2 NOT SUPPORTED"));
return;
}

[MaistroX]

Any working solution towards OpenSSL 1.0+ for 7.7.3 release of ioFTPD yet?

None of the above worked over here! :/


Regards

[Prodigy]

@MaistroX
What's the openssl things that didn't worked out for you?, compilation steps/process?

Worked fine over here with openssl 1.0.2h

[MaistroX]

Got it to work now with the OpenSSL-Win32 files, failed with the OpenSSL-Win64! :)

[Hans_]

hi every1,

did some1 test the latest release of openssl(v.1.1.0) with ioftpd?

im just wondering if some1 did and if its working right - otherwise there will be a problem if you upgrade to OpenSSL v.1.1.0..

just saw in the documentation:

"As of OpenSSL 1.1.0, these options are deprecated, use SSL_CTX_set_min_proto_version and SSL_CTX_set_max_proto_version instead."

so as i understand the situation, config entry in ioftpd.ini, will not work anymore:

OpenSSL_Options = NO_SSLv2|NO_SSLv3|NO_TLSv1

will not work anymore with OpenSSL v.1.1.0 due to change mentioned above...

any thoughts on this?

[spudgun]

This is going to be a problem for me from today as Flashfxp has updated

FlashFXP 5.4.0 Build 3947
⦁ OpenSSL 1.1.0b for Windows XP SP3 and up. Older versions of Windows OS that are not compatible with the new OpenSSL library will use OpenSSL 1.0.2j.

I now can't connect to my IOFTPD FTP in ssl3 mode as it fails the negotiation. I've tried copying across the newest ssl .lib files, but it still won't connect.

Has anyone been able to find out a way to get this to work?