MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
I've got an XP POSReady system with all the correct registry keys, applied updates, and the IE TLS 1.2 checkbox set. I've got a simple test application that's returning my connection as TLS 1.2 in the IDE. When I compile the application to an executable, however, the program returns TLS 1.0 as my connection result when using ServerXMLHTTP60.
I'm having a tough time tracking down why. I've run registry and file monitors to make sure the IDE and the executable are referencing the same dlls and keys, and can't find a reason for this. I've tried with references and without (late binding) and both return the same results.
Incidentally, I tested Msxml2.XMLHTTP60, which works correctly in both the IDE and application. It's only MSXML.ServerXMLHTTP60 that doesn't work in the executable.
Code:
Private Sub Command1_Click()
' Create a reference to MSXML6 if you want to use the next line,
' and rem out the two lines that follow this
' Dim objhttp As New MSXML2.ServerXMLHTTP60
Dim objhttp As Object
Set objhttp = CreateObject("Msxml2.ServerXMLHTTP.6.0")
objhttp.open "GET", "https://howsmyssl.com/a/check", False
objhttp.setRequestHeader "User-Agent", "Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0"
objhttp.setRequestHeader "Content-type", "text/html"
objhttp.send
Debug.Print objhttp.getAllResponseHeaders
Debug.Print objhttp.responseText
Text1.Text = Text1.Text & vbCrLf & objhttp.getAllResponseHeaders & vbCrLf & objhttp.responseText
Set objhttp = Nothing
End Sub
I did check my path to make sure only MSXML6.dll, MSXML6r.dll, and WinHttp.dll in System32 are being utilized, and not some copies in some other directories in the path, so I'm not sure why this is happening.
Also, I prefer to use the XML library and not Winhttp.dll directly, as I'm dealing with XML data from the server that my actual program is connecting, and the application is already fully written. The service provider is just enforcing TLS 1.2 very shortly.
Here's the VB6 project if you want to download and test for yourself.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
We can't always get what we want.
I don't think the MSXML wrapper around the WinHttp exposes access to the necessary option to use TLS 1.2:
Code:
:
Set HTTPRequest = New WinHttp.WinHttpRequest
With HTTPRequest
.Open "GET", "http://www.google.com/", True
.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1_2
.Option(WinHttpRequestOption_EnableRedirects) = True
.Send
:
:
No idea why you are worried about fiddling with paths though. ActiveX libraries are located via their class registration, and the path stored there gets used.
Last edited by dilettante; Oct 3rd, 2019 at 08:35 PM.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by Montclair
I've got an XP POSReady system with all the correct registry keys, applied updates, and the IE TLS 1.2 checkbox set. I've got a simple test application that's returning my connection as TLS 1.2 in the IDE. When I compile the application to an executable, however, the program returns TLS 1.0 as my connection result when using ServerXMLHTTP60.
Are running your IDE on the same XP POSReady box or is this a separate machine?
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by dilettante
I don't think the MSXML wrapper around the WinHttp exposes access to the necessary option to use TLS 1.2:
If that's true, then it shouldn't work in the IDE, which it does.
Originally Posted by dilettante
No idea why you are worried about fiddling with paths though. ActiveX libraries are located via their class registration, and the path stored there gets used.
I'm not interested in fiddling with the path. I stated that I ensured the correct dlls were being accessed in the IDE and run-time by the OS, by checking the path for the dlls. I was simply eliminating a possibility as to what's causing this odd behavior.
Lastly, I'm not interested in calling winhttp directly as explained. I appreciate the code, but I'd prefer to not use that. The post is about why MSXML2.ServerHTTP connects via TLS 1.2 in the IDE, but not in the run-time.
Last edited by Montclair; Oct 4th, 2019 at 05:26 PM.
i do my best to test code works before i post it, but sometimes am unable to do so for some reason, and usually say so if this is the case. Note code snippets posted are just that and do not include error handling that is required in real world applications, but avoid On Error Resume Next
dim all variables as required as often i have done so elsewhere in my code but only posted the relevant part
come back and mark your original post as resolved if your problem is fixed
pete
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
w10 pro
i can test it on xp later
edit: on testing in xp, i also got the same results for both the ide and an exe, both returned TLS1.0
Last edited by westconn1; Oct 7th, 2019 at 04:30 AM.
i do my best to test code works before i post it, but sometimes am unable to do so for some reason, and usually say so if this is the case. Note code snippets posted are just that and do not include error handling that is required in real world applications, but avoid On Error Resume Next
dim all variables as required as often i have done so elsewhere in my code but only posted the relevant part
come back and mark your original post as resolved if your problem is fixed
pete
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by westconn1
w10 pro
i can test it on xp later
edit: on testing in xp, i also got the same results for both the ide and an exe, both returned TLS1.0
Right, which is what you should get on standard XP, and is also what I get on other machines running XP. I'm running the POSReady patches to enable TLS 1.2 on this machine before I deploy to the others.
Does anyone have the POSReady version running who can test this? It's very, very odd.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
are you running either the ide or the exe elevated? that could possible account for the difference in version
i do my best to test code works before i post it, but sometimes am unable to do so for some reason, and usually say so if this is the case. Note code snippets posted are just that and do not include error handling that is required in real world applications, but avoid On Error Resume Next
dim all variables as required as often i have done so elsewhere in my code but only posted the relevant part
come back and mark your original post as resolved if your problem is fixed
pete
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Well something weird just happened. The first time I ran it from the IDE, I got "TLS 1.0", the same as the executable. When I ran it again from the IDE, I got "TLS 1.2". I'm able to duplicate that every time by closing VB and re-opening it.
As a matter of fact, if I click the MSXML2.ServerXMLHTTP.6.0 button a second time after getting "TLS 1.0", it then returns "TLS 1.2".
So, if I unload VB and reopen, I get TLS 1.0 on the first call, and TLS 1.2 on every subsequent call. If I leave VB running, end the program, and start it again, I get TLS 1.2 on every call after the first one from the first time I ran the program.
What the heck?!
Last edited by Montclair; Oct 7th, 2019 at 04:07 PM.
This might not be the solution but in any case redirection might fail w/ access denied (for some reason) depending on Internet security zone settings.
cheers,
</wqw>
I tried with www and got the same results.
However, those results now confirm that both the executable and the IDE perform identically. Both calls with MSXML2.ServerXMLHTTP return TLS 1.0 on their first calls, and TLS 1.2 on all subsequent calls -- which is wrong. It should be TLS 1.2 on all calls.
I'm starting to think that maybe a registry key might be the issue. I will do more investigation and report my results.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Registry settings appear to be the issue, but I can't seem to get them working. I tried disabling all protocols in the registry except TLS 1.2, and the program fails immediately with error 80090331, stating "The client and server cannot communicate, because they do not possess a common algorithm." These keys are:
And the results are the same. If I don't leave TLS 1.0 enabled, the program can't communicate at all with this test URL. Additionally, I tested all of this with the actual server I need to connect with and the results are identical. TLS 1.0 connections are rejected by that server, but subsequent calls use TLS 1.2. If TLS 1.0 is disabled, I get the same error about no common algorithm.
I'm unclear on why TLS 1.0 needs to be enabled and attempted first and fail, then TLS 1.2 will be used on subsequent attempts, but I fear that this discussion may now be out of the scope of a VB forum, unless anyone out there has any insight.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
More info. I tried adding a call using WinHTTP and setting the protocols to only accept TLS 1.2, which immediately and properly connects using TLS 1.2. Subsequent to that, calls using MSXML2.ServerXMLHTTP also connect using TLS 1.2.
While definitely not ideal, this could be a workaround to get MSXML2.ServerXMLHTTP to connect using TLS 1.2.
In the end, I will likely re-code the connection to use WinHTTP entirely, which I was hoping to avoid, and MSXML to handle the actual XML data.
I'd still like to know why the OS or MSXML2.ServerXMLHTTP object calls fail to attempt TLS 1.2 first.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
It was, surprisingly, easy to convert my existing code in the actual application to use WinHTTP, which appears to work properly enforcing TLS 1.2 on all calls from XP POSReady and Windows 10 (the OS's where this application will be deployed).
While this isn't an answer as to why POSReady and XMLServerHTTP calls try to use TLS 1.0 on the first call (despite the registry stating that's not desirable), it is an acceptable workaround.
For others who may stumble upon this and are hesitant, converting my code was as simple as this:
Code:
Set XMLReceive = CreateObject("Msxml2.DOMDocument.6.0")
Set XMLServer = CreateObject("Msxml2.ServerXMLHTTP.6.0")
XMLServer.setTimeouts ResolveTimeoutMs, ConnectTimeoutMs, SendTimeoutMs, ReceiveTimeoutMs
XMLServer.setRequestHeader "User-Agent", "My XML App V1.0"
XMLServer.setRequestHeader "Content-type", "text/xml"
XMLServer.Open "POST", Server_Address, False
XMLServer.send (My_XML_Request_String_or_XML_Document)
Failure = (XMLServer.Status <> 200)
If Not Failure Then XMLReceive.loadXML (XMLServer.ResponseXML.XML)
to
Code:
Set XMLServer = CreateObject("WinHttp.WinHttpRequest.5.1")
Set XMLReceive = CreateObject("Msxml2.DOMDocument.6.0")
XMLServer.setTimeouts ResolveTimeoutMs, ConnectTimeoutMs, SendTimeoutMs, ReceiveTimeoutMs
'force TLS 1.2
XMLServer.Option(9) = 2048
XMLServer.Option(6) = True
XMLServer.Open "POST", Server_Address, False
XMLServer.setRequestHeader "User-Agent", "My XML App V1.0"
XMLServer.setRequestHeader "Content-type", "text/xml"
XMLServer.send (My_XML_Request_String_or_XML_Document)
Failure = (XMLServer.Status <> 200)
If Not Failure Then XMLReceive.loadXML (XMLServer.ResponseText)
It would, nonetheless, be interesting to understand why such odd behavior arises from the XMLServerHTTP object, but that may never be found, as I'm moving on with the project using the WinHTTP object.
Last edited by Montclair; Jul 31st, 2021 at 01:16 AM.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Glad you nailed it. I was fiddling with Option(9) on ServerXMLHTTP/XMLHTTP and it was always failing w/ "invalid option" or similar, doh :-))
Probably XMLServer.Option(9) = XMLServer.Option(9) Or 2048 would be safer, i.e. instead of "forcing" TLS 1.2 just "allowing" it (if available on server endpoint).
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by wqweto
Glad you nailed it. I was fiddling with Option(9) on ServerXMLHTTP/XMLHTTP and it was always failing w/ "invalid option" or similar, doh :-))
Probably XMLServer.Option(9) = XMLServer.Option(9) Or 2048 would be safer, i.e. instead of "forcing" TLS 1.2 just "allowing" it (if available on server endpoint).
cheers,
</wqw>
Ah, very clever comment on the option! I'll try that and see if it performs incorrectly and report back.
As for setting those options on the MSXML objects, they don't exist -- which is why you would get that error. There's no mechanism to specify what's allowed and what's not, other than the registry, when dealing with MSXML, AFAIK.
It's still all very curious. If I tell the OS to use TLS 1.2, then XMLServerHTTP calls fail on the first try, using the lowest available protocol but it refuses to use TLS 1.2 on that first try. XMLHTTP works every time connecting with TLS 1.2. Very weird.
Another interesting tidbit -- if I make the first call through WinHTTP, then XMLServerHTTP will correctly use TLS 1.2 on its first call! It just seems like these options have to be set on the WinHTTP object, as XMLServerHTTP defaults to the lower security protocols first and just won't use TLS 1.2 on it's first call regardless of registry settings. So strange!
It's probably a bug in the MSXML library for XP POSReady for the XMLServerHTTP object. None of this weird stuff happens on Windows 10.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by wqweto
Probably XMLServer.Option(9) = XMLServer.Option(9) Or 2048 would be safer, i.e. instead of "forcing" TLS 1.2 just "allowing" it (if available on server endpoint).
Results in error 5, "Invalid procedure call or argument". Apparently, you can't actually read the value set in HttpRequestOption (in VB6 on XP anyway). Even this fails:
Code:
Dim HTTPRequest As Object
Set HTTPRequest = CreateObject("WinHttp.WinHttpRequest.5.1")
With HTTPRequest
.Option(9) = 2048
Debug.Print .Option(9)
.Option(6) = True
.Open "GET", "https://www.howsmyssl.com/a/check", True
.Send
.WaitForResponse = 5
Text1.Text = Text1.Text & .ResponseText
End With
The bold line results in error 5. Weird.
You do bring up a valid point though. When TLS 1.2 is invalidated some time in the future, this program will fail. Not sure how I would even code for some unknown future value anyway, other than how you suggested.
Last edited by Montclair; Oct 9th, 2019 at 02:59 PM.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by wqweto
Debug.Print .Option(2) works so apparently 9 is write-only option.
You can self-document the code by using the actual constant names (w/o winhttp typelib reference) like this:
thinBasic Code:
' consts copy/pasted from `Microsoft WinHTTP Services, version 5.1` typelib
Const WinHttpRequestOption_SecureProtocols = 9
Const SecureProtocol_TLS1 = 128
Const SecureProtocol_TLS1_1 = 512
Const SecureProtocol_TLS1_2 = 2048
With HTTPRequest
.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1_2 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1
. . .
End With
cheers,
</wqw>
Interesting that 9 is write-only despite the documentation. I know about the constants, and my actual code was already updated to use them. Still, no way to future proof this, though, which is expected I suppose. I'll deal with that hurdle when it actually becomes one.
Thanks for the conversation. I enjoyed it!
Last edited by Montclair; Oct 10th, 2019 at 06:44 PM.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
For the sake of completeness, attached is the final, cleaned up version of this TLS tester. It will tell you whether your system successfully negotiates a TLS 1.2 connection with the test server at https://www.howsmyssl.com/a/check using the various connection methods of WinHttp51, XMLServerHTTP60, and XMLHTTP60.
Feel free to modify and use for whatever you want.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by Montclair
For the sake of completeness, attached is the final, cleaned up version of this TLS tester. It will tell you whether your system successfully negotiates a TLS 1.2 connection with the test server at https://www.howsmyssl.com/a/check using the various connection methods of WinHttp51, XMLServerHTTP60, and XMLHTTP60.
Feel free to modify and use for whatever you want.
Thank you Montclair... This is exactly what i've been looking for. I was using the MSXML2.ServerXMLHTTP.6.0 and been having issues with certain HTTPS sites, and knew it was because of ciphers etc not up to date.
I will now be able to implement this to update my program to start supporting those sites again i couldn't connect with.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by vb6locked
Thank you Montclair... This is exactly what i've been looking for. I was using the MSXML2.ServerXMLHTTP.6.0 and been having issues with certain HTTPS sites, and knew it was because of ciphers etc not up to date.
I will now be able to implement this to update my program to start supporting those sites again i couldn't connect with.
You're very welcome! I'm glad I could help out. Us old VB guys gotta stick together.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
I have SO many libraries and controls i have written, its hard for me to give up Vb6 because i can write some very complex GUI programs in days, rather than months. I have written in other languages, but i always try and tie it to Vb6. For example, i wrote a Cuda C program to do some heavy lifting for my VPU. I then used older versions of visual studio to be able to call those Cuda C functions through my vb6 program.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
You can use winhttp, 99% of the usage is the same. When I develop some crawlers or post submission, generally commonly used xmlhttp, serverxmlhttp, winhttp, all can be set and selected in the same module.
chinese:你可以使用winhttp,99%的用法都是相同的,我开发一些爬虫或者post提交的时候,一般常用xmlhttp,serverxmlhttp,winhttp,都在同一个模块里面可以任意设 置选择。
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
In China, we use the simplified version of the win7 installation package 200 MB, after installation, there is only 800 MB to a g. The volume is very small and can completely replace XP. Now the system I use is windows8.1, which has the appearance of win10, and has the mini speed of win7.
I installed the entire system in a 10g-size memory disk. Ramos is very easy to use. The hard disk read speed is 8000 megabits per second.
chinese:在中国,我们使用精简版本win7安装包200兆,装好之后也只有800兆到一个g。体积非常迷你,完全可以替代xp,现在我使用的系统是windows8.1,拥有win10的外观,又有win 7的迷你快速。
我把整个系统安装在10g大小的内存盘里面,ramos,非常好用,硬盘读取速度8000兆每秒。
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Okay, i updated a couple of my programs and i have TLS 1.2 working now. Thanks again Montclair.. let's hope they don't start blocking TLS 1.2 any time soon.
Ps.
On my Win 10 machine, i get tls 1.2 on all buttons.
On my Win 7 machine, i only can get 1.2 on the 3'rd button - MSXML2.XMLHTTP.6.0 - TLS Max Version : 1.2
Is this the same for everyone, or am i missing something?
Extra Info : I added all the registry entries...
Last edited by vb6locked; Feb 11th, 2020 at 11:36 AM.
Reason: Extra Info
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Got IT!
Here is the offender :
Code:
.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2
Even thou all the patches and registry entries have been added, apparently, on Windows7 the option to set the secureprotocols fails on any value beyond TLS1.0 (128). If i completely remove the option, i then get full TLS 1.2 support.
I have also updated the code to show the max TLS supported line, and removed the .option(WinHttpRequestOption_SecureProtocols) line
WinHttp.WinHTTPRequest.5.1 - TLS Max Version : 1.2
MSXML2.ServerXMLHTTP.6.0 - TLS Max Version : 1.2
MSXML2.XMLHTTP.6.0 - TLS Max Version : 1.2
Works every-time in both IDE and EXE
Last edited by vb6locked; Feb 11th, 2020 at 12:58 PM.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by vb6locked
Got IT!
Here is the offender :
Code:
.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2
Even thou all the patches and registry entries have been added, apparently, on Windows7 the option to set the secureprotocols fails on any value beyond TLS1.0 (128). If i completely remove the option, i then get full TLS 1.2 support.
I have also updated the code to show the max TLS supported line, and removed the .option(WinHttpRequestOption_SecureProtocols) line
WinHttp.WinHTTPRequest.5.1 - TLS Max Version : 1.2
MSXML2.ServerXMLHTTP.6.0 - TLS Max Version : 1.2
MSXML2.XMLHTTP.6.0 - TLS Max Version : 1.2
Works every-time in both IDE and EXE
That's good news!
The point of the lines you rem'd out, however, was to test TLS 1.2, then 1.1, then 1.0 to see what your system supports. It's odd that fails on Windows 7 as your registry settings appear to be correct, based on the .reg file you added to the zip, although you left out the TLS 1.x\Server keys (maybe they're not necessary - not sure -- see post #17).
I verified that my original version works in Windows 10, so it's very strange that it doesn't in 7.
I'd probably leave the code in there that you rem'd out because in XP POS Ready with your version, WinHTTP fails on the first click, going immediately back to TLS 1.0.
You could put an OS check using the code found here, then use the result to code around windows 7 implementing the checks or not. I bet it's some other registry setting, though, not set in your system's registry.
Bottom line, your version doesn't work in XP POS Ready which was the original point of the post, but it does appear to work in 7+ (works in Windows 10 verified).
Just for completeness, I'm re-attaching the original version just in case anyone else using XP POS Ready comes across this.
Last edited by Montclair; Feb 11th, 2020 at 02:46 PM.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Unfortunately, after several months, I need to revisit this topic, but this time for a Vista installation. Neither my original version of TLS nor vb6locked's is able to negotiate TLS 1.2 using WinHttp.WinHttpRequest.5.1 and MSXML2.ServerXMLHTTP.6.0. Only MSXML2.XMLHTTP.6.0 is able to make a TLS 1.2 connection.
In doing a lot of research, there is a patch for Windows Server 2008 that could be applied to Vista to allow TLS 1.2 connections, which I've applied. More about that here: https://johnhaller.com/useful-stuff/...-windows-vista
I have all the registry keys correct, and if I disable TLS 1.0 and lower protocols, I can't get VB to make a TLS 1.1 or TLS 1.2 connection via the two methods above. For whatever reason, only one method works, but I've already rewritten all of my various projects to use WinHTTP, as that works on XP POS Ready and Windows 10.
Specifically, setting this results in error 5, as vb6locked noted on his Windows 7 matchine:
Code:
Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2
The supposed solution to this is to not set the option at all, and instead let the registry keys define which protocol is the default option for WinHTTP, which is what vb6locked had to do to get WinHTTP to connect via TLS 1.2 on Windows 7.
However, no matter what I try, I just can't get Vista and VB6 to do this. I've combed through stackexchange, google, youtube, etc., and just can't find the answer. IE9 is installed and does make a TLS 1.2 connection to https://www.howsmyssl.com/, so I know it is supported and should be working, as it works with the MXSML2.HTTP request as well.
I tried turning on WinHTTP tracing, but honestly, I don't find the logs to be very useful in figuring out why VB6 calls to WinHTTP won't use the default protocol. In fact, if I disable all other protocols in the registry with only TLS 1.2 enabled, and do not set the Option(WinHttpRequestOption_SecureProtocols) to anything, VB refuses to connect at all. Otherwise, I always get connected via TLS 1.0
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by Montclair
Unfortunately, after several months, I need to revisit this topic, but this time for a Vista installation. Neither my original version of TLS nor vb6locked's is able to negotiate TLS 1.2 using WinHttp.WinHttpRequest.5.1 and MSXML2.ServerXMLHTTP.6.0. Only MSXML2.XMLHTTP.6.0 is able to make a TLS 1.2 connection.
I had this same behavior on Win7 here but I fixed this very easily. Here is my root cause analysis of the problem.
When you set .Option(WinHttpRequestOption_SecureProtocols) = protocol_selection it is the WinHttp.WinHttpRequest COM object that does some kind of "client-side" validation of the allowed bits being set in the protocol_selection value. For XP, Vista and Win7 you can't go to anything beyond SecureProtocol_TLS1 so testing for TLS 1.2 (and TLS 1.1) protocol availability with by error trapping the property assignment is not very accurate (at all).
For TLS 1.2 Microsoft directly slip-streamed updated SSPI (Schannel) DLLs on XP SP3 (POS Ready only), Vista (actually Server 2008) and Win7 but did not update the pre-installed WinHttp.WinHttpRequest COM object so now we have capabilities mismatch between WinHttp and the actual SSPI protocol implementation because of the "client-side" validation on the Option property.
Here comes DefaultSecureProtocols registry into play. For this to be used by SSPI the WinHttpRequest object has to leave grbitEnabledProtocols member of the SCHANNEL_CRED structure empty when calling AcquireCredentialsHandle API and this happens when you *manually* assign .Option(WinHttpRequestOption_SecureProtocols) = 0 in VB6 -- it is not enough to *not* set .Option(WinHttpRequestOption_SecureProtocols) to anything.
With this comes a strategy for TLS 1.2 best effort solution -- test for TLS 1.2 "client-side" availability as it's done at present in your code with .Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2 but if this fails just stop and assign .Option(WinHttpRequestOption_SecureProtocols) = 0.
You have to instruct/guide users out-of-band to set DefaultSecureProtocols to 0xA00 (which is exactly SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2) as *the* permanent solution to TLS 1.2 issues on their machines.
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by wqweto
Here comes DefaultSecureProtocols registry into play. For this to be used by SSPI the WinHttpRequest object has to leave grbitEnabledProtocols member of the SCHANNEL_CRED structure empty when calling AcquireCredentialsHandle API and this happens when you *manually* assign .Option(WinHttpRequestOption_SecureProtocols) = 0 in VB6 -- it is not enough to *not* set .Option(WinHttpRequestOption_SecureProtocols) to anything.
</wqw>
Wow. What a great post! This was thorough and very well written. I will try this out on the Vista machine and report my results. Thanks for the detailed explanation!
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Unfortunately, this doesn't work for me. Setting WinHttpRequestOption_SecureProtocols to 0 initially doesn't get me any connection results at all via WinHTTP. No matter how long I wait, testing .ResponseText gets me error -2147483638 The data necessary to complete this operation is not yet available.
If I try the others first, descending all the way down to SecureProtocol_TLS1, then set it to 0 as a last resort, I get error -2147012721 A security error occurred. I've verified that DefaultSecureProtocols is set to 0xA00, and that these are also set:
Re: MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady
Originally Posted by Montclair
So, while this may work on Windows 7, it seems to essentially do nothing on Vista.
True!
Unfortunately KB3140245 (Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows) is for Win7 only (and is included in Win7 SP1). This fixes the "client-side" validation bug in WinHttp.WinHttpRequest object I'm talking about.
In fact the Server 2008 hacked update you mentioned does slip-stream SSPI DLLs and TLS 1.2 is available from the base APIs and also updating IE to version 9 does bring TLS 1.2 to MSXML2.XMLHTTP. It's the WinHttp that cannot be updated short of randomly copy/pasting the DLL from Win7 and calling regsvr32. . .
I generally always prefer to use MSXML2.XMLHTTP instead of MSXML2.ServerXMLHTTP and WinHttp.WinHttpRequest for one simple reason -- it's a client component while the latter are server components. What this means in practical terms is that ServerXMLHTTP and WinHttpRequest pump messages in some of their syncronous calls while XMLHTTP never does. And this random pumping is *very* dangerous for a client application as it allows re-entrancy in most peculiar ways (the end user can click on the UI while fetching data from internet). While for server apps (think of ASP or any other IIS technology) it does not matter if there is a random DoEvents anywhere in client or system code -- it simply cannot re-enter on the same thread.