0

I'm able to get an unsecured FTP Client/Server system going, but when I try throwing in the SSL io handlers, setting up both apps to use sslvTLSv1, it shows Connected for the Client status then eventually times out (the only Server message I get is Socket Error # 10060).

user7475089
  • 21
  • 5
  • This has nothing to do with certificates. You are likely just not connecting to the server correctly, or maybe not activating SSL/TLS correctly. My guess is that you have the `UseTLS` property set wrong on one or both ends. A timeout error in `TIdFTP.Connect()` generally means `Connect()` is waiting for a server greeting that is never sent because the server is waiting for the client to initiate an SSL/TLS handshake first. The `TIdFTP.OnConnected` event is fired as soon as the socket is connected, before any protocol data is exchanged. – Remy Lebeau Mar 01 '17 at 22:17
  • Using SSL/TLS in FTP usually requires extra setup steps at the protocol layer. See [RFC 4217 "Securing FTP with TLS"](https://tools.ietf.org/html/rfc4217). Indy's FTP components support SSL/TLS, which implies that you are likely not configuring them correctly. Please show your actual property values and any `OnConnect` event handlers on both ends. – Remy Lebeau Mar 01 '17 at 22:17
  • 1
    I have it set to ufUseRequireTLS on both, SSLOptions.Method set to sslvTSv1 on both, server has SSLOptions.Mode set to sslmServer and client set to sslmClient – user7475089 Mar 01 '17 at 22:21
  • 1
    `utUseRequireTLS` is the wrong setting to use, you should use either `utUseImplicitTLS` or `utUseExplicitTLS` instead. – Remy Lebeau Mar 01 '17 at 22:24
  • OnConnect for the server I only do: AContext.Connection.IOHandler.DefStringEncoding := IndyTextEncoding_UTF8; AContext.Connection.IOHandler.DefAnsiEncoding := IndyTextEncoding_UTF8; For the client, I'm just using the default FTP Client demo with the OnWork's fixed for Indy 10.6 – user7475089 Mar 01 '17 at 22:24
  • Switched to usUseExplicitTLS but no change as yet. – user7475089 Mar 01 '17 at 22:28
  • `utUseImplicitTLS` initiates an SSL/TLS handshake immediately upon connect before any FTP data can then be exchanged. `utUseExplicitTLS` opens the connection initially unsecure and then the client can send an `AUTH` command to request SSL/TLS if it wants to use encryption. Is the client doing that? Have you tried using a packet sniffer to see what the client and server are actually sending back and forth? When SSL/TLS is not immediate, the server should be sending an unencrypted greeting. When SSL/TLS is immediate, the client should be sending a handshake. – Remy Lebeau Mar 01 '17 at 22:30
  • Just tried Implicit on both and the server is throwing this error: 1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher – user7475089 Mar 01 '17 at 22:39
  • That means the client and server are not using the same encryption ciphers. And that *IS* something that is usually related to certificates. If you don't use any certificates, the only ciphers you can use are ones that don't require authentication (like Anonymous Diffie-Hellman and EC Anonymous Diffie-Hellman). You will have to configure the `SSLOptions.CipherList` accordingly on both ends to allow such ciphers, such as by removing `!aNULL` from the default `CipherList`. – Remy Lebeau Mar 01 '17 at 22:50
  • I've seen other discussions similar to this topic before but nothing has been stated definitively as to whether a secure connection can be made without certificates, which is what it looks like this error is requiring. :/ – user7475089 Mar 01 '17 at 22:50
  • It *can* be done, but it *shouldn't* be done, unless you don't care about man-in the-middle attacks. – Remy Lebeau Mar 01 '17 at 22:51
  • My CipherList is empty. There should never be a man in the middle attack as only our dedicated devices will know how to connect to our server and our insane username password combo..he he he – user7475089 Mar 01 '17 at 22:52
  • If you use an empty `CipherList`, Indy won't configure OpenSSL's ciphers, so OpenSSL will use whatever default ciphers it was compiled with. That could lead to mismatches if both client and server are not using the exact same DLLs. You *should* specify something. Indy's default `CipherList` is `'AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH'`. You would just have to remove the `!aNULL` to enable the non-authentication ciphers. Refer to [OpenSSL's documentation](https://wiki.openssl.org/index.php/Manual:Ciphers(1)) for more details. – Remy Lebeau Mar 01 '17 at 23:00
  • Weird, tried that CipherList with/without the !aNULL, no change :/ I'm using the same ssl dll's in both program folders. Is the CipherList built into the dll's or is it a file that needs to be included? – user7475089 Mar 01 '17 at 23:09
  • The actual ciphers are built in to the DLL. The `CipherList` simply enables/disables them on a per-connection basis. I suggest you use a packet sniffer like Wireshark to view the actual TLS handshake and see what ciphers are being negotiated. There are tons of online discussions related to `no shared ciphers`, search around. Also, you might consider just [generating a self-signed certificate](http://stackoverflow.com/questions/10175812/) for the server, especially since your server is private. – Remy Lebeau Mar 01 '17 at 23:22

1 Answers1

0

After many trials and tribulations trying to resolve this issue, I've determined that there are serious problems with enabling a certificate-less security system; meaning that, if you want it secured (with the current Indy code), you need to use certificates. Perhaps there are some settings in the SSL component that need to be made, but there just isn't specific enough info (working examples of certificate-less SSL) to make this work. Hopefully this deadlock will be resolved in a future release of Indy ;)

user7475089
  • 21
  • 5