Changes to Fix Central bulkFTP download method

Fix Central is modifying the "bulk FTP" download option to use secure FTP(FTPS).

As of February 2017 all downloads using "bulk FTP" will require a secure FTP client connection.
As of June 2017 SFTP (FTP over SSH) has been enabled along with FTPS for external customers only.

IBM and our customers prefer encrypted communication. We have been asked by customers, and see the benefit of, moving to an encrypted SSL(TLS) based FTP protocol.

In the Download options page, if the product download supports the "Download using bulk FTP" option, will now change to "FTPS". You will now also be given a temporary, order specific, user ID and password which will be needed to access the fixes through FTPS. For fixes that do not require entitlement checks, you can still use the anonymous ID. In both cases the browser based "FTP download location" button now will go away, as browsers do not support FTPS. And you will have to use an SSL(TLS) enabled FTP client to be able to download fixes from the FTP server location provided. Exception: For some unique individual AIX fixes, there are still some available links using regular FTP. These will go away at some point in the future.

No, any ftp client that supports SSL(TLS), passive will work.
Update June 2017: any clients supporting SFTP will now also work.

Check out the section How can I debug FTPS? to see tips for a couple of the most common clients.

Starting February 2017, you will notice the "bulk FTPS" results page will be referencing the need for you to use FTPS clients, and will provide you the temporary user ID and password.

Update: This was originally delayed from an initial plan of January 2017.

examples:

• "remote host did not respond within the timeout period."
• "Error: Connection timed out after 20 seconds of inactivity"
• "Error: Failed to retrieve directory listing"
• "Timeout detected. (data connection)"
• "Could not retrieve directory listing"
• "Error listing directory"
• "Listing directory / failed"
• "450 LIST: Connection timed out. Please contact your web hosting service provider for assistance."
• "Timeout (????? ms) occurred on receiving server response."
• "Error 0x80043103 - Connection timeout."
• "A remote host refused an attempted connect operation.
  can't find list of remote files, oops"
• "Unable to make a connection. Connection timeout."
  The above error messages may be received when using the "get", "mget", or "dir" commands in ftps.
  
  If the client tries to connect but the "data" connection is being blocked by firewall, then depending on the client, you will receive a message similar to one of the above. Please contact your firewall administrator and send them information found here:
  • What does my firewall team need to know?
• "Error with certificate at depth 1"
  There is a known OpenSSL bug seen by some users of the AIX ftp client. It was resolved with the latest OpenSSL filesets. You may see a slightly different error, but the error will be about a failed certificate verification. If you get this error please visit the following URL and upgrade to the latest version of OpenSSL.
  • https://www.ibm.com/resources/mrs/assets?source=aixbp&S_PKG=openssl
     

FTPS is an extension of FTP which uses SSL/TLS encryption and an alternative "data" port for downloads. But there are several flavors/modes that may be used.

FTPS is implemented on these fix download servers using "explicit" and "passive" mode. This means that the initial communication or "command" channel will be opened on port 21. After the initial "command" communication on port 21 the server will tell the client on which port to communicate for "data". In this implementation the port is random and between 65024-65535. Therefore client firewalls must allow outbound (TCP) traffic on that range of ports to enable FTPS download of fixes from IBM.

FTPS is sometimes confused with SFTP, but SFTP uses ssh rather then FTP.

The "explicit" mode refers to the fact that the client uses the regular FTP port 21 for the initial communication. If your client is trying to communicate using "implicit" mode FTPS, it may be trying to open the initial "command" port using 990. If you get an error about not being able to communicate using port 990, it means your client is trying to run "implicit" mode. Please try and change that, or on some clients just change the port to 21.

The initial "command" connection from your client is initiated outbound on port 21. This is the same direction and port used for regular FTP and therefore should not be causing you a problem if you have used FTP to communicate for fix downloads in the past. The only difference now is that IBM now expects encrypted data to be sent in. If you are not using FTPS, you will receive a message that talks about encryption being required. Some examples of clients showing this failure include:

550 SSL/TLS required on the control channel

If the initial "command" communication and login succeeds, then the next important factor is that the client and server start talking in passive mode. For most FTPS clients they will automatically negotiate with the download server and default to "passive" mode. For AIX client using "ftp -s" the user must manually enter the "passive" command immediately after logon.

After successful logon, and entering "passive" mode, if you enter a "dir" command you should see something like this:

227 Entering Passive Mode (129,35,224,115,254,213).
150 Opening ASCII mode data connection for file list
TLSv1/SSLv3 ( AES256-SHA ), 256 bits
lr--r--r-- 1 tNuMwOLT ftpapp 76 Mar 7 17:54 {Filename deleted for this example}

The above number string is useful information. It can be interpreted as telling the FTPS client to connect to ip: 129.35.224.115 on port (256 * 254 + 213)= 65237...
Your client will then attempt to open an outbound "data" connection to 129.35.224.115:65237.
In the example output above the data connection is successful and "dir" command returns the contents of your current directory. But if the connection is blocked by a firewall, you will get one of the errors listed in the above section: What error might I see?

If that is your error, please contact your network administrators and reference this information: What does my firewall team need to know?

The screen output below is listed here as an example of successful communication using the AIX "ftp -s" command:

--> ftp -s delivery04-mul.dhe.ibm.com
Connected to dispmy-115.mul.ie.ibm.com.
220 ProFTPD 1.3.5b Server (proftpd) [129.35.224.115]
234 AUTH TLS successful
TLS Auth Entered.
TLS handshake succeeded, though Server signed it's own cert!
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
30:ee:0e:4d:47:3f:76:4d:dc:bc:6a:07:4d:8e:a1:72
Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust SSL CA - G3
Validity
Not Before: Jan 5 00:00:00 2017 GMT
Not After : Mar 6 23:59:59 2018 GMT
Subject: C=US, ST=New York, L=Armonk, O=INTERNATIONAL BUSINESS MACHINES CORPORATION, CN=*.dhe.ibm.com
TLSv1/SSLv3 ( AES256-SHA ), 256 bits
Name (delivery04-mul.dhe.ibm.com:dennis): tNuMwOLT
331 Password required for tNuMwOLT
Password:
230 User tNuMwOLT logged in
200 PBSZ 0 successful
200 Protection set to Private
ftp> passive
Passive mode on.
ftp> dir
227 Entering Passive Mode (129,35,224,115,254,213).
150 Opening ASCII mode data connection for file list
TLSv1/SSLv3 ( AES256-SHA ), 256 bits
lr--r--r-- 1 tNuMwOLT ftpapp 76 Mar 7 17:54 {Filename deleted for this example}
aaaaaa