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

[paule12345]

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:

javax.net.ssl|DEBUG|E1|ajp-nio-127.0.0.1-8020-exec-4|2021-03-30 19:44:22.918 CDT|SSLCipher.java:1994|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
javax.net.ssl|DEBUG|E1|ajp-nio-127.0.0.1-8020-exec-4|2021-03-30 19:44:22.940 CDT|SSLSocketImpl.java:727|close inbound of SSLSocket
javax.net.ssl|DEBUG|E1|ajp-nio-127.0.0.1-8020-exec-4|2021-03-30 19:44:22.941 CDT|SSLSocketImpl.java:761|close outbound of SSLSocket
javax.net.ssl|DEBUG|E1|ajp-nio-127.0.0.1-8020-exec-4|2021-03-30 19:44:22.941 CDT|SSLSocketImpl.java:479|duplex close of SSLSocket
javax.net.ssl|DEBUG|E1|ajp-nio-127.0.0.1-8020-exec-4|2021-03-30 19:44:22.941 CDT|SSLSocketImpl.java:1587|close the SSL connection (passive)

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

[Charlie Arehart]

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. 

[paule12345]

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.

[James Moberg]

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.

[paule12345]

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]

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]

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.

[paule12345]

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

[BKBK]

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.

[paule12345]

BKBK, with both TLSv1.3 and TLSv1.2 in the flags as you suggest, the connection fails with the same error as before.

[BKBK]

Thanks for the information. Could you please share the content of your cfhttp tag, including all the attributes. Obfuscate private or sensitive data using xxx. For example, username="xxx". 

Alternatively, you may send me the data by private-message. I could then also test the code. 

[BKBK]

In the meantime, try the full JVM flag for TLS:

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

[BKBK]

Hi @paule12345 ,

Handy information: the site you're attempting to connect to - which you let me know via private message - uses TLS1.2 and TLS1.3. You can verify this on https://gf.dev/tls-test

[James Moberg]

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]

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

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

[BKBK]

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>

[paule12345]

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]

@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#">

[BKBK]

Note also that the SOAP response is generic. It says nothing about the particular domain or web service.

[BKBK]

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

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

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]

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

Some more findings from my tests that I'd like to share:

• Cfhttp requests to our web services work. The services run on Windows Server 2016 configured with TLS 1.2 and TLS 1.3.
• The web service runs on ColdFusion 2018 Update 11, with Java 11.0.10, on . The java.args property in the server's jvm.config file includes, amongst others, -Dcom.sun.net.ssl.enableECC=true -Djdk.attach.allowAttachSelf=true -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true -Djava.security.policy={application.home}/lib/coldfusion.policy -Djava.security.auth.policy={application.home}/lib/neo_jaas.policy.
• The client making the cfhttp request is on ColdFusion 2018 Update 11, with Java 11.0.10, on Windows 10. 
• There are no -Djdk.tls.client.protocols / -Dhttps.protocols flags in the jvm.config file of the client or server.
•  

[BKBK]

Yet another clue pointing to your vendor's server. The site ssllabs.com says that the following 3 sites use TLS 1.2 and TLS 1.3:

• adobe.com
• our web service's domain
• your vendor's domain (the domain name you shared by private message)

I therefore did a simple test. I sent a cfhttp get request to each in turn:

<!---<cfset wsurl = "https://adobe.com"> --->
<!---<cfset wsurl = "https://my.webservice.domain.nl">---> 
<cfset wsurl = "https://your.vendor.domain.net"> 

<cfhttp url="#wsurl#" method="get" result="response"> 
</cfhttp> 

<cfdump var="#response#"> 

The Adobe domain and our web service domain responded with Statucode: 200 OK. Whereas your vendor's domain responded with Statuscode: Connection Failure. Status code unavailable.

Again, no -Djdk.tls.client.protocols / -Dhttps.protocols flags were necessary in the jvm.config file of the client.

[BKBK]

Hi @paule12345 ,

Could you please update the forum.

This issue is a common one for ColdFusion developers.