Short Read Exception

Question

Hello Support Team,

We are using EDT Java API to connect with SFTP server. We are getting exception while using wild card e.g. "abc*xyz". In all other cases there is no exception.
Same thing is running smoothly with local server, some of our production servers but one sepcific server is giving this this Exception
Here is the source I used for this, kindly guide:

public void newCodeTestReadingAPIDoc() {
   try {
      SSLFTPClient ftp = new SSLFTPClient();
      ftp.setRemoteHost(remoteHost);
      ftp.setRemotePort(remotePort);
      ftp.setConfigFlags(SSLFTPClient.ConfigFlags.DISABLE_WAIT_ON_CLOSE
            | SSLFTPClient.ConfigFlags.DISABLE_SSL_CLOSURE);
      ftp.setImplicitFTPS(true);
      System.out.println("Importing the server certificate...");
      ftp.getRootCertificateStore().importPEMFile(serverCertPath);
      System.out.println("Connecting to " + remoteHost);
      ftp.connect();
      System.out.println("Auth with PROT PRIVATE.");
      ftp.auth(SSLFTPClient.PROT_PRIVATE);
      System.out.println("Login to " + remoteHost);
      ftp.login(userId, userPw);
      if (ftp.pwd().equals(remotePath) == false) {
         System.out.println("Changing to directory " + remotePath);
         ftp.chdir(remotePath);
      }
      System.out.println("Getting directory listing of: " + remotePath);
      String[] files = ftp.dir(wildCard);
      System.out.println("Total Files Found: " + files.length);
      for (int i = 0; i < files.length; i++) {
         System.out.println("File Name: " + files[i]);
      }
      // close the connection
      ftp.quit();
   } catch (SSLFTPCertificateException e) {
      System.out.println("Failed to connect. Certificates are: ");
      e.printCertificates();
      e.printStackTrace();
   } catch (Exception e) {
      e.printStackTrace();
   }
}

Here is the Exception occured with ft.dir(wildCard) line:

com.enterprisedt.net.puretls.SSLHandshakeFailedException: com.enterprisedt.net.puretls.SSLPrematureCloseException: Short read
at com.enterprisedt.net.puretls.i.G(Unknown Source)
at com.enterprisedt.net.puretls.SSLSocket.handshake(Unknown Source)
at com.enterprisedt.net.ftp.ssl.C.A(Unknown Source)
at com.enterprisedt.net.ftp.ssl.C.getInputStream(Unknown Source)
at com.enterprisedt.net.ftp.FTPClient.dir(Unknown Source)
at com.enterprisedt.net.ftp.FTPClient.dir(Unknown Source)

Regards,
Faisal Maqsood

Answer 1

I have replied in the email. One finding is that the Short Read problem appear specially if we use such wild card for which there should not be any file.
For example if at remote site there is no file named abc*.xyz and we use dir method of the API then we will get Short Read issue.

Kindly verify on your side.

Thanks,
Faisal Maqsood

Answer 2

Hi Faisal

We have looked at the logs you sent us and it seems clear that instead of responding with an SSL server-hello to our client-hello, the server is simply closing the connection. This is incorrect according to the SSL protocol. The server is meant to go through the entire SSL handshake before closing properly, even if it has no data to send. Our software is therefore correct to throw an exception at this breach of protocol, which could potentially be a truncation attack (i.e. the scenario in which an attacker is interfering by selectively closing connections, hence making you think that there is no data when there in fact might be).

That's the bad news. The good news is that Glub seems to have fixed this problem.

You are using verison 2.5.7 of Glub's server. According to Glub's history page, in version 2.5.9, the following fix was made, "Fixed data connection handling if listing was done on empty directory". The bug was also reported on Glub's forums.

So I therefore recommend upgrading the server to the latest version, or at least version 2.5.9.

Please let us know if that fixes the problem.

- Hans (EnterpriseDT)

Answer 3

EDT Support Team,

We thank you for all this effort and to provide the solution with references. Once we apply this, we will update you.

Regards,
Faisal Maqsood

Answer 4

EDT Support Team,

We have applied it and it is working fine now.

Thanks,
Faisal Maqsood

Answer 5

That's great. Thanks for letting us know.

- Hans (EnterpriseDT)