View Single Post
Old 03-14-2014, 04:01 PM  
Yil
Too much time...
 
Join Date: May 2005
Posts: 1,194
Default

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.
Yil is offline   Reply With Quote