Classic ASP / IIS6 / Win2003 Server can't communicate with TLS server

Question

Sage Pay today ended their exemption for sites to use SSL3 when communicating with their payment / authorisation servers. TLSv1 is now required.

We have a Windows Server 2003 box running IIS6, and two sites written (sadly) in Classic ASP. The box has been patched / registry keys updated to mitigate against POODLE, and various online checkers back this up. The server should be using TLS ONLY.

However, when trying to authorise a Sage Pay transaction using WinHttp.WinHttpRequest.5.1 and a POST, the attempt fails immediately. The only error fed back by WinHttpRequest is "-2147483638 - WinHttp.WinHttpRequest - The data necessary to complete this operation is not yet available."

Internet Explorer on the same server is also unable to access the Sage Pay adminstration interfaces hosted on the same URLs. This, despite SSLv2 and SSLv3 being turned off in Internet Options. Again, TLSv1 should be the only option available to ANYTHING on the box.

It doesn't matter what timeouts or options I put on the WinHttp object - it fails so quickly it's almost like it hasn't even tried.

I have verified that the server in question CAN communicate with Sage Pay's servers by using curl. curl works either without a protocol specified (it uses TLS) or by manually specifying - and won't when SSL2 or 3 is specified - as expected.

If that works, why won't anything else - when every bit of server configuration says it should?

Here is a small sample of code which returns the above quoted WinHttpRequest error:

<%
VSPServer = "https://test.sagepay.com/showpost/showpost.asp"

Set objHTTP = Server.CreateObject("WinHttp.WinHttprequest.5.1")
On Error Resume Next
objHTTP.Open "POST",CStr(VSPServer),False
objHTTP.Send "Hello"

If Err.Number <> 0 Then
    Response.Write "Status: " & objHTTP.Status & "<p>"
    Response.Write Err.Number & " - " & Err.Source & " - " & Err.Description
End If

On Error Goto 0
Set objHTTP = Nothing
%>

If False is changed to True (to run this async) in the objHTTP.Open line, the script returns nothing. This script worked prior to Sage Pay turning things off this afternoon.

Answer 1

It doesn't matter what timeouts or options I put on the WinHttp object - it fails so quickly it's almost like it hasn't even tried.

The only error fed back by WinHttpRequest is "-2147483638 - WinHttp.WinHttpRequest - The data necessary to complete this operation is not yet available."

Sounds like you've made an asynchronous request but did not wait for response.

First, you need to figure it out by calling WaitForResponse.
And Second, have to set which secure protocol(s) can be used for the connection.

Try the following code and let me know if the problem still persists.

Option Explicit

Const   WinHttpRequestOption_SecureProtocols = 9
Const   SecureProtocol_SSL2 = 8, SecureProtocol_SSL3 = 32, _
        SecureProtocol_TLS1 = 128, SecureProtocol_TLS1_1 = 512, _
        SecureProtocol_TLS1_2 = 2048

Dim objHTTP
Set objHTTP = Server.CreateObject("WinHttp.WinHttprequest.5.1")
    objHTTP.Open "GET", "https://test.sagepay.com/showpost/showpost.asp", True
    objHTTP.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1
    objHTTP.Send
    If objHTTP.WaitForResponse(30) Then 'wait up to 30 seconds
        'response is ready
        Response.Write "Status : " & objHTTP.Status & "<br />"
        Response.Write "Response Length : " & LenB(objHTTP.ResponseBody)
    Else
        'Request timed out
        Response.Write "Request timed out"
    End If
Set objHTTP = Nothing

Answer 2

I have now managed to resolve this. After changing the nature of my search for the problem I discovered that Win2003 uses a different encryption algorithm to connect to servers, even via TLS. It uses 3DES whereas SagePay expects AES. (Source: SagePay Protocol Violation Error)

This led me to install the hotfix linked from Richard Day's answer (http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe - this is the fix for 32 bit English - the hotfix page is here: https://support.microsoft.com/kb/948963) - and, after a reboot, everything fell into place.

Thank you to everyone who made suggestions. It looks like, in the end, it was a problem at the server level. If that requires that this post be moved (as it's no longer programming related), then please do so.