Hi Scott,
Congratulations and big thanks, because you nailed it!
It is the SNI host name header that causes the problem. When I add a
breakpoint to CommSSL_Resolve() and set "sslHost" to *BLANKS, the web
service works fine. It also works fine, when I set sslHost to the
host of the web service URL. By default sslHost is set to peHost,
which is wwHost. Actually wwHost has been set to the host of the URL:
*********************************************************
* Parse URL into it's components
*********************************************************
c if http_long_ParseURL(peURL: wwServ:
wwUser:
c wwPass: wwHost: wwPort:
wwPath) < 0
c return *NULL
c endif
But a few lines later, it is overridden with dsProxyHost:
*********************************************************
* Proxy address provided?
*********************************************************
c eval wwOrigHost = wwHost
c eval wwOrigPort = wwPort
c if dsProxyHost <> *blanks
c eval wwHost = dsProxyHost
c endif
Therefore SNI host name is set to the name of the proxy server
instead to the name of the server of the web service (bug?).
Overview of the data flow:
parseURL(URL --> wwHost) --> ifProxy(wwHost = dsProxyHost) -->
CommSSL_Resolve(sslHost = wwHost)
In that case SNI host is set to "proxy.foo.de".
The web service call works fine, when I use the debugger to:
a) set sslHost to: *BLANKS
b) set sslHost to: e-sourcing.qa.foo-baa.com (name of the web service
host)
I am truly not a http/ssl/tls specialist, but what I understood from
Wikipedia is:
The SNI extension of TLS enables a client to send the server name,
that it want to connect to, to the server, at the time TLS
negotiation takes place. That shall enable the server to send the
right certificate to the client, because the client verifies, that
the name of the server (it want to connect to) is listed in the
certificate.
Therfore I assume, that the SNI host name should (or must?) match the
host name of the tcp "Host" header. Correct?
Thomas.
-----Ursprüngliche Nachricht-----
Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Scott
Klement
Gesendet: Mittwoch, 12. Oktober 2016 00:06
An: HTTPAPI and FTPAPI Projects
Betreff: 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
-----------------------------------------------------------------------
--
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
-----------------------------------------------------------------------