1

I have a strange problem. I'm using Indy to implement FTPES connectivity in my application and connecting to the same server from my application works on some computers but not on all, returning "SSL is not available on this server".

I'm using DLLs from http://indy.fulgan.com/SSL/ (openssl-1.0.1c-i386-win32.zip). The DLLs are in the application's directory. They get loaded (I can't delete them while application is running and WhichFailedToLoad() is empty).

Any ideas what could be causing this and what to try?

Leonardo Herrera
  • 8,388
  • 5
  • 36
  • 66
Kaitnieks
  • 922
  • 1
  • 8
  • 15
  • 1
    What kind of certificate are you using on the server? Self signed/Verisign/...? Some newer certificates won't work on older machines without root certificate updates (that should come via Windows Update) – Joachim Isaksson Dec 27 '12 at 14:22
  • Self-signed. One of the machines that fails to connect is Windows 8 - it should have pretty new certificates I suppose. But I'll check if they can be updated anyway, thanks! – Kaitnieks Dec 27 '12 at 14:25
  • Doesn't appear to be root certificate issue - I installed all root certificate related updates I could find, disabled all certificate verifications and still the same error. – Kaitnieks Dec 27 '12 at 15:02

1 Answers1

3

The error message means that the SSL/TLS handshake failed, which can happen for any number of reasons. Try using the IOHandler's OnStatusInfo/Ex events to get more information. Or use a packet sniffer, such as Wireshark, to analyze the actual handshake data.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • Apparently when connecting to FTPES server from some PCs, the server won't respond to my handshake immediately but only on connection timeout when QUIT command is sent. How can it be? – Kaitnieks Dec 27 '12 at 22:31
  • The only time `TIdFTP` sends a `QUIT` command is when its `Disconnect()` method is called. The only time `Disconnect()` is called during an `AUTH TLS` command is if you have the `AutoLogin` property set to True so `Login()` gets called by `Connect()`, and then the TLS handshake fails or times out, raising an exception. `Connect()` will catch the exception, call `Disconnect()`, and re-raise the exception into your code that is calling `Connect()`. You need to double-check the SSL/TLS handshake data, make sure it is 100% correct and complete. Wireshark can help you with that. – Remy Lebeau Dec 27 '12 at 22:46
  • It's the same length as on the PC that it works on, only the packet header and footer seems to differ - the data is identical. – Kaitnieks Dec 28 '12 at 00:13
  • Here's the packet diff if it helps: http://kaitnieks.com/images/handshakecompare.png – Kaitnieks Dec 28 '12 at 00:23
  • 1
    That is not helpful. I'm not going to waste time trying to decode that by hand. You should use Wireshark to analyze socket communications, let it decode and analyze the data an present it to you in a human-readible fashion. – Remy Lebeau Dec 28 '12 at 01:57
  • I am using Wireshark... The handshake (unlike normal FTP commands) is not presented in human-readible fashion, it's just a binary stream. Like I said, the handshake data is identical in both cases, but in one case server responds immediately and in the other - only after QUIT command. – Kaitnieks Dec 28 '12 at 09:41
  • Here I made a minimal(ish) sample: http://pastebin.com/iq2A1KXd - add the OpenSSL DLLs (from file mentioned in the question text), run it from a fresh Windows 8 (or possibly Windows 7 installation) and you'll see. I'm using Delphi 2010 but I don't think it matters. – Kaitnieks Dec 28 '12 at 10:24
  • And here's more complete Wireshark output: http://kaitnieks.com/images/wires.png with the handshake initialization packet selected. – Kaitnieks Dec 28 '12 at 10:56
  • Wireshark can decode SSL/TLS handkshakes and display the various parameters, ciphers, certificates, etc in human-readable format. If it is not decoding the handshake automatically, you can right-click on the first packet of the handshake, choose "Decode as", and select "SSL". – Remy Lebeau Dec 28 '12 at 18:54
  • Wireshark wasn't able to decode Client Hello if I used sslvSSLv23 so I changed it to sslvSSLv3. Here's the new output: http://kaitnieks.com/images/wires2.png - the general behaviour hasn't changed. – Kaitnieks Dec 28 '12 at 22:09
  • Some new information: this problem occurs on virtual machine if network connection is configured as NAT but not when it's configured as Bridged. It also occurs on a regular Windows 8 PC (not virtual machine) in at least one case. – Kaitnieks Dec 29 '12 at 18:51
  • Alright, apparently the real bug got confused with NAT/Firewall issues somehow. I don't know what's going on exactly, but on the VMs other FTPES clients timeout as well; on the laptop FileZilla works, but it seems more and more that it must be a firewall issue. For now this question is on hold, I will most likely delete it later on. – Kaitnieks Dec 29 '12 at 20:46