Problem after changing ibm i release to V7R4M0

[RomanMoser]

Hello,
I am using HTTPAPI for years and it worked fine all the time. Last weekend we changed to IBM i-Release V7R4M0 and now it doesn't work any longer.

When I do
rc = http_url_post_stmf( URL
: HTTP_FILE
: HTTP_RESULT
: HTTP_TIMEOUT
: HTTP_USERAGENT
: HTTP_CONTT_819
: HTTP_SOAPACT);
I get these errors:
(GSKit) I/O: A connection with a remote socket was reset by that socket.
ssl_error(406): (GSKit) I/O: A connection with a remote socket was reset by that socket.

Do you know about this problem? How can I solve the problem?
Any information and help would be appreciated.

[Scott Klement]

I'm not aware of any problems like this.

What version of HTTPAPI is it?
Did you install the latest cume/group PTFs for the new OS version?
Can you provide a complete debug/trace file?

[RomanMoser]

Hi Scott,

thanks for your quick answer.The problem is solved!

I contacted my partner on the other side (the receiver of the data) and he told me the following:
"it should be a TLS-Problem. We actually support 1.0, 1.1 and 1.2 but the Cyphers are still older ones. So we will change to another Webserver with more setting options".

Sorry, that I couldn't explain it more in detail but I don't nothing about Cyphers and so on. But the good news is, it works now!

Regards, Roman

[Scott Klement]

In 7.4, IBM disabled some of the old TLS protocols and ciphers that are no longer considered secure. Most likely the http server only supported these old non-secure ones and therefore was resetting the connection.

This is the first time I've heard of a provider resetting the connection for this problem -- normally you get an error saying that it can't negotiate ciphers, or that the peer isn't recognized. But it seems that this http server resets the connection instead... just a guess.

[Leela_G]

I have the same error after upgrade to V7R4.
Not sure how to resolve it. I have used http_req() in my program.
Can this be fixed?

[Scott Klement]

Use some SSL diagnostic tools to connect to the HTTP server and see which TLS protocols and ciphers it supports.
Then, check your IBM i system values and make sure you're allowing at least some of the same TLS protocols and ciphers.

[jsanguin]

Thanks for your comments, I find your postings very useful. I would recommend when you state you have a problem just to state which version of Scott's library you are using. So I will right away validate if I might have the same problem by any chance or not because I might be in a more recent version. Thanks and regards.

[tigerax]

In 7.4, IBM disabled some of the old TLS protocols and ciphers that are no longer considered secure. Most likely the http server only supported these old non-secure ones and therefore was resetting the connection.

This is the first time I've heard of a provider resetting the connection for this problem -- normally you get an error saying that it can't negotiate ciphers, or that the peer isn't recognized. But it seems that this http server resets the connection instead... just a guess.

So it looks like on v7r3 we had ECDHE_RSA_AES_128_CBC_SHA256

we have upgraded to v7r5 and I can see ECDHE_RSA_AES_128_GCM_SHA256

The webservice provider we are calling confirmed they are using CBC, not GCM.

Do you know if older ciphers can be added back in or are they obsolete once IBM remove them?

[stefan@tageson.se]

You can add older ciphers if you want, just remember there's a reason they are not enabled by default. You have to enable them in STRSST ( search for ELIGIBLEDEFAULTCIPHERSUITES ) and also change the QSSL* system values to reflect your change.

[tigerax]

Just wanted to confirm that adding the old ciphers back in has resolved our issue for now.

added the cipher to the system value QSSLCSL. However despite being allowed to add it there, it was disabled at the LIC.

Then enabled them, as mentioned above. STRSST


"Licence Internal Code" the bit that sits under the operating system.

"System Service Tools" used to modify the settings in the LIC