OpenSSL 1.0+ for ioFTPD?

[urskog]

Hi!

Many sites are upgrading to OpenSSL 1.0+ 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! 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

[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, a bulk encryption algorithm, a message authentication code (MAC) algorithm, and a pseudorandom function (PRF). (RFC 5246, p. 40)

• The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake. (RFC 5246, 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 (cryptographic nonces). (RFC 5246, p. 17)
• The message authentication code (MAC) algorithm is used to create the message digest, a cryptographic hash of each block of the message stream. (RFC 5246, 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, p. 16-17, 26)

Examples of algorithms used
key exchange/agreement

RSA, Diffie-Hellman, ECDH, SRP, PSK

authentication

RSA, DSA, ECDSA

bulk ciphers

RC4, Triple DES, AES, IDEA, DES, or Camellia. In older versions of SSL, RC2 was also used.

message authentication

for TLS, a Hash-based Message Authentication Code using MD5 or one of the SHA hash functions is used. For SSL, SHA, MD5, MD4, and MD2 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). 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]

Originally Posted by 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

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