Re: [Ftpapi] Using HTTPAPI getting the error below

This sounds similar to something we came across trying to use ssh/sftp to access a client’s site.

We getting a matching cipher not found error. We had to edit the SSH_CONFIG files and add them the old ones in for that particular host.

It had to do with OpenSSH 8.0p1 that was applied during an upgrade to the i. Here was IBM’s solution

OpenSSH has a list of 'default' algorithms that are used without any changes needing to be made to the server or client. OpenSSH also has a list of 'supported' algorithms that can be used. The algorithms that were removed because they are weak are not in the default used algorithms; however, they are still available in the list of supported algorithms.

You will need to either change the ssh_config file and add a statement similar to below, or you can continue to specify it on the ssh command as you did.

If you want to change the ssh_config file you can add either of the following:

Specify for this just one host:

Host somehost.example.org

Ciphers +aes128-cbc

To make it available for any host:

Ciphers +aes128-cbc

The +aes128-cbc leaves all the 'default' ones in place and adds aes128-cbc to the list.

The path to the config file is listed below. Before making any changes to the ssh_config file be sure to save a copy.

WRKLNK '/QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_config'

ssh is the client config file; sshd is the server config file

** This e‑mail message and all attachments transmitted may contain confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited.**
If you received this message in error please notify the sender immediately by telephone or by electronic mail and delete this message and all copies and backups thereof.

From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Michael Mayer-Oakes
Sent: Friday, June 19, 2020 3:42 PM
To: 'FTPAPI/HTTPAPI mailing list' <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Ftpapi] Using HTTPAPI getting the error below

All-

Found a way to get support from IBM on this. Instead of reporting that HTTPAPI was having an issue I used the SQL UDF SYSTOOLS.HTTPPOSTCLOB and reported its error.

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzajq/rzajqudfhttppostclob.htm

Note these are on our V7R1, but couldn’t find the info on that version’s manual.

Here is what IBM sent at first, good information on tracing:

https://www.ibm.com/support/pages/mustgather-ibm-i-db2-systools-http-functions-httpgetclob-etc

THIS I think confirms what I had been suspecting, that we are not up to date on cipher suites and so we can no longer make a secure connection.

[IBM]

You can call some HTTP functions using the JDBC client program.

From QSH

$ java -Djavax.net.debug=ssl:handshake:verbose -cp /QIBM/UserData/OS400/SQLLib/Function/jar/SYSTOOLS/DB2RESTUDF.jar:/qibm/proddata/os400/jt400/lib/jt400.jar com.ibm.as400.access.jdbcClient.Main jdbc:as400:localhost

>!callmethod com.ibm.db2.rest.DB2UDFWrapper.httpGetClob('https://prod1.IPCharge2.net',null)

.. Debugging information displayed. -- then search the web for matching information

[IBM]

NOTE: !callmethod… must be typed as it with the “!” to work, not a java guy so I missed that at first. J

I substituted our problem webservice for the URL in the httpGetClob, just the full URL not the XML data, and presto got a dump on the screen of all java debug info, here is the important bit I think:

[snipit]

Cipher Suites: [SSL_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_AE

S_256_CBC_SHA, SSL_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_FIPS_WITH_DE

S_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RENEGO_PROTECTION_REQUEST]

[/snipit]

This combined with the SSL analysis from this website: https://www.ssllabs.com/ssltest/

[snipit]

Cipher Suites
# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA) FS	256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK	256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA) FS	128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK	128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK	256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK	128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS	256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS WEAK	256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS	128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS WEAK	128

[/snipit]

Leads me to conclude that the webservice no longer has compatible cipher suites for TLS v1.2 with our machine and so no SSL connection is possible.

Waiting for IBM to confirm.

Anyway I hope all this helps someone, and maybe even myself in 5 or 10 years when I come across this again.

Have a great weekend everyone!

Michael

P.S. Thanks to Scott for all his Open Source work!!