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

Re: Cannot get SSL working on 7.2



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
-----------------------------------------------------------------------