Inspiring

Answered

CFHTTP connection failure to site with TLS 1.3 and TLS 1.2 enabled

Forum|Forum|4 years ago
March 31, 2021
8 replies
7029 views

Recently a vendor we work with updated their server to support TLS 1.3 in addition to TLS 1.2 and our CFHTTP calls to their API are now failing with an Errordetail "I/O Exception: www.thevendor.net:443 failed to respond"

- Testing from our server to theirs using java (11.0.10) SSLPoke succeeds.

- Scanning their API endpoint with the SSLLabs testing tool shows no issues.

- Accessing their API endpoint with Chrome browser has no issues.

- If I modify our code to use the CFX_HTTP5 custom tag, the connection succeeds.

- If I add jvm.config flags to force TLS 1.2, the connection succeeds, specifically:

-Djdk.tls.client.protocols=TLSv1.2 -Dhttps.protocols=TLSv1.2

If I enable SSL handshake debugging with the jvm flag

-Djavax.net.debug=ssl,handshake,verbose

coldfusion-error.log doesn't show an exception but the last few lines show these lines that I don't see in a successful TLS 1.2 connection:

I see the behavior on CF 2016 / 2018 / 2021 with the latest patches, running Java 11.0.10 on Windows Server 2019.

Correct answer paule12345

We switched to using the cfx_http5 tag for that particular vendor's API. Forced TLS 1.2 with the ssl="5" parameter on the tag.

B

Benjamin Reid

Participating Frequently

I just thought I would add some useful info to the mix...

We use IISCrypto from Nartac Software (no affiliation) to lockdown the protocols, cyphers, etc supported on all our servers. One nice thing about the tool is that it quickly shows you what is supported and how it is currently configured just by running the tool, whether or not you apply.

BKBK

Community Expert

Hi @paule12345 ,

Could you please update the forum.

This issue is a common one for ColdFusion developers.

P

paule12345AuthorCorrect answer

Inspiring

We switched to using the cfx_http5 tag for that particular vendor's API. Forced TLS 1.2 with the ssl="5" parameter on the tag.

BKBK

Community Expert

Thanks, @paule12345 , for the update.

BKBK

Community Expert

@paule12345 : Recently a vendor we work with updated their server to support TLS 1.3 in addition to TLS 1.2...

https://www.theVendor.net/services/theVendorWebService/ServicenameLite.asmx

Hi @paule12345 ,

It appears that the vendor isn't yet using TLS 1.3.

Launch their URL* in the browser, and read the usage manuals. Apparently, they're still using just TLS 1.1 and TLS 1.2.

(* the one you sent me by private message)

P

paule12345Author

Inspiring

I don't see a reference to TLS versions in the API usage manuals, perhaps you are referring to their mention of *SOAP* 1.1 and *SOAP* 1.2 ?

The site is running TLS 1.2 and TLS 1.3 as verified by the testing tools mentioned in this thread (SSLLabs.com, Geekflare, etc)

I just gave CURL 7.76 a try with the -verbose option and the log shows that it connects to the site via TLS 1.3

* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256

BKBK

Community Expert

@paule12345 :

I don't see a reference to TLS versions in the API usage manuals, perhaps you are referring to their mention of *SOAP* 1.1 and *SOAP* 1.2 ?

The site is running TLS 1.2 and TLS 1.3 as verified by the testing tools mentioned in this thread (SSLLabs.com, Geekflare, etc)

True. My bad. I have looked again and can confirm they're indeed on TLS 1.2 and TLS 1.3.

Did you use CURL in combination with cfexecute?

BKBK

Community Expert

Hi @paule12345 ,

I am beginning to wonder whether there is a problem with the web service, rather than with the ColdFusion client. I have also tested using Curl.

I have used Curl, including a variety of headers and payload, to post to the URL you gave me (in a private message). All attempts have been unsuccessful. In every case, I get the following error message:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<soap:Body>
		<soap:Fault>
			<soap:Code>
				<soap:Value>soap:Receiver</soap:Value>
			</soap:Code>
			<soap:Reason>
				<soap:Text xml:lang="en">System.Web.Services.Protocols.SoapException: Server was unable to process request. ---&gt; System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace() at System.Xml.XmlTextReaderImpl.ParseDocumentContent() at System.Web.Services.Protocols.SoapServerProtocol.SoapEnvelopeReader.Read() at System.Xml.XmlReader.MoveToContent() at System.Web.Services.Protocols.SoapServerProtocolHelper.GetRequestElement() at System.Web.Services.Protocols.Soap12ServerProtocolHelper.RouteRequest() at System.Web.Services.Protocols.SoapServerProtocol.Initialize() at System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type, HttpContext context, HttpRequest request, HttpResponse response, Boolean&amp; abortProcessing) --- End of inner exception stack trace ---</soap:Text>
			</soap:Reason>
			<soap:Detail />
		</soap:Fault>
	</soap:Body>
</soap:Envelope>

P

paule12345Author

Inspiring

BKBK, the error you're getting with the CURL test is most likely because the SOAP packet you're submitting is empty, malformed or missing required parameters. The fact that you got a textual error response back from the webservice tells me that CURL is successfully doing a TLS handshake with their server. The problem I'm having here is that CF and/or the underlying JDK is not even able to make that initial TLS handshake unless we force the JDK to use TLSv1.2 only.

BKBK

Community Expert

@paule12345 , the SOAP packet isn't empty. In fact, whatever data I send using CURL, I get the the same response as above.

The CURL request is in the following form (domain and service names changed for confidentiality):

<cfsavecontent variable="soapBody"><?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Body>
    <SoapActionName xmlns="http://domain.net/com/cds/domainwebservice/">
      <StartDate>04/11/2021</StartDate>
      <EndDate>04/11/2021</EndDate>
      <AuthKey>5e0ef2f2-a5e8-4aed-9b58-e3ec7a270f37</AuthKey>
    </SoapActionName>
  </soap:Body>
</soap:Envelope>
</cfsavecontent>

<cfset wsurl = "https://www.domain.net/services/domainwebService/ServicenameLite.asmx"> 

 <cfexecute name = "C:\bin\curl-7.76.0-win64\bin\curl.exe" arguments = " -X POST --data '#soapBody#' -H 'Host:www.domain.net' -H 'Content-Type:application/soap+xml;charset=utf-8' -H 'Content-Length:#len(soapBody)#' -H 'SOAPAction:http://domain.net/com/cds/domainwebservice/SoapActionName' #wsurl#" variable="httpResult" timeout="15">
 </cfexecute>

<cfdump var="#httpResult#">

James Moberg

Inspiring

I wrote a TestBox unit test to identify & compare CF2016, CF2021 & Lucee5.3 CFHTTP/SSL connections for migration purposes. The "passing" results are based on our initial test results using Adobe ColdFusion 2016,0,17,325979 and Windows Server 2016 with OpenJDK 11.0.10+8-LTS-162. I compared them with a 2CF021,0,01,325996 installation and the results were consistent.
https://gist.github.com/JamoCA/9ba99ca07e4e8e3fd17e08c0352e6fad

I'm curious to see if you receive the same test results.
(attempt #3; responding on these forums is really frustrating.)

James Moberg

Inspiring

TestBox is available for free by going to https://www.ortussolutions.com/products/testbox

(The forums denied this link in my earlier message.)

Charlie Arehart

Community Expert

Thanks for the clarifications, Paul. And cool ideas from James (Jamo). Hope you may get things sorted.

I'll press just one more time: I know you say the admin reports you're on 11.0.10. Again, I have seen people get misled (such as if they had multiple CF instances and were looking at the wrong one, or had a cluster of CF machines and were using the web server to view the Admin and ended up on an unexpected one.) And I realize you may say neither of those is true.

But just as a sanity check, you could add this code which will report the java version of the CF instance in which the code runs.

<cfdump var="#server.system.properties.java.version#">

Put that in the page that is failing (and do a cfabort after it, before you code runs and causes the error). Does that indeed report 11.0.10?

If so, then we can close that question. 🙂 As always, just trying to help.

/Charlie (troubleshooter, carehart. org)

P

paule12345Author

Inspiring

Charlie, I added your code to the page and it reports java version 11.0.10

BKBK

Community Expert

Did you try the following flags:

-Djdk.tls.client.protocols=TLSv1.3,TLSv1.2 
-Dhttps.protocols=TLSv1.3,TLSv1.2

It's unclear to me whether you did.

James Moberg

Inspiring

Could you post the URL (or hostname) to the API endpoint? (If it's accessible to the entire world, but requires authentication, it shouldn't be an issue.)

I've written some TestBox unit tests for CF2016, CF2021 and Lucee using TestBox and BadSSL.com. (BadSSL doesn't have a TLS 1.3 server available for testing.)
https://dev.to/gamesover/cfml-unit-tests-for-cfhttp-and-badssl-1lfa

NOTE: I recommend using CFX_HTTP5 too, but Lucee doesn't support C++ tags and I'm attempting to write cross-platform compatible CFML.

P

paule12345Author

Inspiring

Jamo, I'd rather not make the URL public. If there's a way to send it to you privately, let me know.

James Moberg

Inspiring

I believe that you can click on my name, view my forums profile and use the "Send Message?" button at the top to send a private message.

My contact information is also available on my blog profile. (Twitter, LinkedIn, link to more info, etc)
https://dev.to/gamesover

Charlie Arehart

Community Expert

I'm confused: you say if you use the jvm flags works, "the connection succeeds". Then you show the debug log. What is the success, and when is the failure?

Assuming you do have a failure, how are you confirming that cf shows using Java 11.0.10? I've seen people who thought their jvm was updated when it was not. And this sounds like a problem that an updated jvm could fix.

/Charlie (troubleshooter, carehart. org)

P

paule12345Author

Inspiring

The forum software wouldn't let me edit the original post to clarify, so... the debug log is from when the force TLS 1.2 option is *not* enabled and CFHTTP does not connect.

CF Admin shows the java version as 11.0.10

Even tried java 15.0.2 to see if that version had a fix, and got the same error.

I'll throw out another curious thing, the vendor's server API is an .aspx endpoint which implies Windows Server, which as far as I know does not support TLS 1.3 yet, so perhaps they have a proxy server in front of it.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded