REST API connection issue

[davidlynch]

Good afternoon.

I'm attempting to call an API (using http_url_post) for a new trading partner but can't seem to get past this connection issue. I already use HTTPAPI for many other API connections successfully so the issue seems to be related to this specific host.

In the http_debug log I would normally see 'Dump of server-side certificate information' after the 'SNI hostname...' line for a successful connection but all i get is the following...

Code: Select all

Dump of local-side certificate information:                                                    
-------------------------------------------------------------------------------------          
Nagle's algorithm (TCP_NODELAY) disabled.                                                      
SNI hostname set to: uat.identity.fastway.org                                                  
(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.       
SetError() #30: SSL Handshake: (GSKit) I/O: A connection with a remote socket was reset by that

Before posting I've upgraded to v1.48 of HTTPAPI.

I can connect successfully using cURL and also using SoapUI.

Thank you.

[Scott Klement]

It is attempting to perform a TLS ("SSL") handshake and is getting an error saying the connection was reset.

How is it supposed to print the server side certificate if it can't complete a handshake without the connection being reset?

Think of it this way: Imagine you call to order a pizza, and typically someone answers, you give the order, and then they give you a total. Now imagine you call, they answer, and then you get disconnected and hear a dial tone. Your response would NOT be "why didn't they give me a total?!" Because you'd know you got disconnected.

Likewise, you're getting a "connection reset" error. It's not a huge surprise that it's not printing the certificate info.

When you say that it's working from cURL or SoapUI... are you running those on the same IBMi server? Running them on your PC isn't a helpful since this seems to be related to the version of TLS ("SSL") that's running on your IBM i. I would make sure that you are on at least V7R3 and have all the latest cume and group PTFs that relate to TLS.

[davidlynch]

Thanks for your response. We're at 7.4 with latest cume and group PTFs applied in August 23.

Is there anything I can try prior to installing further PTFs? Our hardware is managed by our corporate business and its a long formal process to get them to do this across our multiple servers.

If it helps, additional info from SK QAUDJRN...

Code: Select all

00951      '          TLSV1.3   GSK_ERROR_IO                  ' 
01001      '                                                  '
01051      '                    An error occurred in SSL proce' 
01101      'ssing, errno value = 3426.                        ' 
01151      '                    '                                

[Scott Klement]

Is there anything I can try prior to installing further PTFs? Our hardware is managed by our corporate business and its a long formal process to get them to do this across our multiple servers.

Connection Reset normally means something has violated a protocol. When one side detects that the other is violating a protocol, it sets the RST ("Reset") flag in the IP packet, which causes the connection reset error. Since we know it is occurring during a TLS handshake ("handshake" is the negotiation portion where it is determining the TLS version, cipher suites, crypto keys, certificate, etc) it seems to be a violation of the TLS protocol somehow.

Most likely it's some sort of compatabiity issue between the IBM TLS support and the one the server is using.

If it helps, additional info from SK QAUDJRN...

Code: Select all

00951      '          TLSV1.3   GSK_ERROR_IO                  ' 
01001      '                                                  '
01051      '                    An error occurred in SSL proce' 
01101      'ssing, errno value = 3426.                        ' 
01151      '                    '                                

That says the same thing that the HTTPAPI log said. GSK_ERROR_IO is the same as the "I/O" in the HTTPAPI log. And 3426 is the code for "connection reset" (or as IBM phrases it "A connection with a remote socket was reset by that socket", which imho is clumsy wording, lol)

I don't know what you can try... I'm not a cryptography expert, and I haven't run into this exact problem before. You could contact IBM support and get them to help... it is IBM's code, after all, that is encountering the error. (It's inside IBM's Global Secure Toolkit -- aka GSKit -- HTTPAPI calls GSKit to perform the TLS.)

[davidlynch]

Thanks again for your help Scott.

From further investigation I'm wondering whether it might be an issue with TLS 1.3. I've looked at the certificate provider (Sectigo) and their website mentions this "TLS 1.3 eliminated support of several insecure algorithms, most notably RSA" and their certificate algorithm states "PKCS #1 SHA-384 With RSA Encryption" so it might be possible that I need to somehow prevent the use of TLS 1.3. This is all new to me so I might go down the IBM support route and see what they suggest.

Cheers

[davidlynch]

Just further to this - as i can't find enough information elsewhere.

The certificate provider (Sectigo) discusses ciphers on their website and as an example refers to cipher TLS_AES_256_GCM_SHA384. On our IBMi server the default ciphers in TLSCONFIG include AES_256_GCM_SHA384.

Is there any difference between TLS_AES_256_GCM_SHA384 and AES_256_GCM_SHA384?

Currently I've exhausted all my options and pushed back to the trading partner to see if they can assist. If that fails I'll see if IBM can assist.

[Scott Klement]

Is there any difference between TLS_AES_256_GCM_SHA384 and AES_256_GCM_SHA384?

No difference. They are the same thing. There is no standard naming for cipher suites, so different vendors make the names slightly different -- in this case, one has "TLS_" at the start and the other does not... but you already knew you were using TLS in both cases, so it doesn't really matter

They are the same cipher suites... AES-256 GCM is the symmetric encryption cipher, they both allow for any key exchange or any authentication, and both use SHA-384 (AEAD) for the MAC.