[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cannot get SSL working on 7.2



Thomas,

This is very strange, since you are clearly receiving data via SSL, it does not make any sense that SSL is not working. Maybe this HTTP server reacts differently when using TLS v1.2 instead of an older version? It should never be allowing the connection and sending back a "400 Bad Request" in that case, as "400 Bad Request" is an HTTP response, not an SSL one, and it is using the SSL connection to send it, which it should not do if it does not like your TLS options. But, who knows? Perhaps this was written by someone who doesn't understand that.

You could try disabling the newer SSL versions in version 1.32 by coding this before any HTTP requests:

https_init(*blanks: *off: *on: *on: *off: *off);

This enables SSLv3 and TLS v1.0, but disables SSLv2, TLSv1.1 and TLSv1.2. Those should be the same SSL options that were available in the older HTTPAPI.

There were two other things that changed in COMMSSLR4 between version 1.25 and 1.32.

1) We enabled Server Name Indication (SNI) in version 1.26 with the GSK_SSL_EXTN_SERVERNAME_REQUEST option.

2) We enabled timeouts with GSK_IBMI_READ_TIMEOUT in version 1.31

I do not know any reason that these would change any behavior, but if setting https_init() to turn off the new TLS versions does not solve the problem, you could try commenting out the code that sets those two options to determine if one of those is affecting the "400" error.

In any case, there is something very unusual happening because SSL/TLS is clearly working, the connection is received and you are receiving data over the encrypted connection. I can't understand why it can send/receive data over the connection if there is an SSL/TLS problem.


On 10/8/2016 3:35 AM, Thomas Raddatz wrote:
Hi Scott,

I do not understand, why the same program (my stripped down test program
and the original program in our production environment) work with
HTTPAPI 1.25 and do not work with 1.26+. It is only the version of
HTTPAPI that makes the difference.

For what I can see in the debug logs, the headers and the xml message
are the same (snippet from Example16B_Error_1.32.log):

do_oper(POST): entered
There are 0 cookies in the cache
POST /core33/services/FooXmlTransport HTTP/1.1
Host: e-sourcing.qa.foo-baa.com
User-Agent: http-api/1.xx
Content-Type: text/xml
SOAPAction:
Content-Length: 358


senddoc(): entered
<?xml version="1.0" encoding="UTF-8"?><SOAP:Envelope
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:impl="http://foo.ws.util.common";><SOAP:Body><impl:transportXml><impl:request><impl:clientExternalId>CL
6300
</impl:clientExternalId><impl:firma>1</impl:firma><impl:xml></impl:xml></impl:request></impl:transportXml></SOAP:Body></SOAP:Envelope>
recvresp(): entered

These lines (above) are identical with the related lines in
Example16B_OK_1.25.log.

But 1.32 ends with a 400 error and 1.25 runs just fine. So what am I
missing?

I just had another idea right now. I took the 1.32 library and renamed
GSKSSL_H to GSKSSL_32, updated COMMSSLR4 and renamed it to COMMSSLR4N.
Then I copied GSKSSL_H and COMMSSLR4 from library 1.25 to the 1.32
library. I renamed GSKSSL_H to GSKSSL_25, updated COMMSSLR4 and renamed
it to COMMSSLR4A.

So I ended up with the following source members in library 1.32:

GSKSSL_32
COMMSSLR4N
GSKSSL_25
COMMSSLR4A

Now I was able to compile HTTPAPI with the COMMSSLR4 module of version
1.25 or version 1.32 in library 1.32 just by copying either COMMSSLR4N
or COMMSSLR4A to COMMSSLR4 before calling the INSTALL program. I started
the debugger before calling my test program to check the version of
module COMMSSLR4. It had to include either GSKSSL_32 or GSKSSL_25.

The result was:

HTTAPAI 1.32 compiled with COMMSSLR4 1.32 ends with the 400 error.
HTTAPAI 1.32 compiled with COMMSSLR4 1.25 runs just fine.

So the problem is in module COMMSSLR4, which make be believe, that it
might be a configuration problem on our IBM i.

What do you think about that?

Thomas.

Am 08.10.2016 um 00:20 schrieb Scott Klement:
Thomas,

I don't understand what you are looking for, here.   SSL is clearly
working in all of these situations, if it were not, you could not get
back a "400 Bad Request" message, as that message is sent using SSL.
In all cases, it is connecting and sending data successfully over SSL.

The message "400 Bad Request" does not mean that SSL is not working, it
means that the server doesn't understand your request.  Possibly it is
expecting the XML data, or the URL, or one of the HTTP headers to be
different.  It does not say which one.

But it has nothing to do with SSL.

-SK


On 10/7/2016 4:14 AM, Thomas Raddatz wrote:
Hi folks,

Really no ideas?

I do not understand the problem. Here is what I fugured out so far:

a) HTTPAPI works fine up to and including version 1.25 (tested with
1.25beta2).
b) I always get a http 400 " Your browser sent a request that this
server could not understand." error starting with 1.26.
c) Debugging 1.25, 1.26 and 1.32 revealed that all versions use TLS
1.2. At least gsk_attribute_get_enum(GSK_PROTOCOL_USED) returns 596
for all tested versions of HTTPAPI.

I attached some more log files from stripped down test programs based
on Example16.

Regards,

Thomas.

-----Ursprüngliche Nachricht-----
Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Thomas
Raddatz
Gesendet: Dienstag, 4. Oktober 2016 09:18
An: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Betreff: Cannot get SSL working on 7.2

Hi,

I tried to update HTTPAPI from 1.24beta11 to 1.32, but I cannot get
SSL connections to work.

The problem is that the server returns a http 400 error (Your browser
sent a request that this server could not understand.) instead of a
soap message. I already tried to enable everything from SSL v2 to TLS
v1.2 as well as disabling the latest TLS versions 1.1 and 1.2. No
success so far. I am stuck.

I am almost sure, that the server uses TLS v1.2, because that is what
the certificate shows (Firefox SSL Info):

"Verbindung verschlüsselt (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
128-Bit-Schlüssel, TLS 1.2)."

On the other hand I wonder how HTTPAPI 1.24 could establish a TLS 1.2
connection. We are on 7.2 and the relevant system values are set to:

QSSLPCL:                *OPSYS
QSSLCSLCTL:        *OPSYS
QSSLCSL:                lists 29 cipher suites

I am sure I am missing something obvious.

Your help is greatly appreciated.

Regards,

Thomas.
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a
criminal offence. Please delete if obtained in error and email
confirmation to the sender.
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a
criminal offence. Please delete if obtained in error and email
confirmation to the sender.


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------