Windows XP SP3 - Problem downloading data

Hi,

I am running Windows XP on VirtualBox. I am trying to download data from a website (eodhistoricaldata.com) that uses Let’s Encrypt for SSL. However when my program sends a request to their server it only returns a blank. The https request sent to the server is valid because I tested it on Chrome in Windows10 and it returns data properly.

According to the website help desk, I could apparently add new Root Certificates on my Windows XP SP3 machine. Has anyone tried this? If it worked, could someone provide me with instructions on how I could solve this problem on my WinXP? According to “eodhistoricaldata.com”, WindowsXP SP3 is supported on their website.

Thanks in advance for your help.

Are you using MSIE under WinXP or some other browser? If it’s IE, it has nothing to do with the certificate but with how that server is set up in terms of protocols and ciphers. If you check the diagnostics page at https://www.ssllabs.com/ssltest/analyze.html?d=eodhistoricaldata.com&hideResults=on, you may notice that in the section “Handshake Simulation” IE under WinXP will have errors listed. If IE + XP support is critical, you would have to reconfigure the server to enable some legacy (and not very secure) ciphers. See:

I must agree with @leader

XP, even with SP3, is severely outdated - no longer supported by Microsoft (since April 2014)
https://support.microsoft.com/en-us/help/14223/windows-xp-end-of-support
Forget using IE on XP securely (those days are long over)
Switch to Chrome on XP, that still has some life left in it:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Forward Secrecy 256
OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) Forward Secrecy 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128

Thank you for your quick reply. To answer your question, I use IE only to test the https request generated by a VB6 legacy program running on WinXP SP3. The VB6 app sends the request via Inet1.OpenURL(). When the https request is sent to the “EODHistoricalData” website it returns a blank; no data is returned.

The VB6 app worked perfectly well with Yahoo.Finance up to about a month ago. Yahoo.Finance now asks for a crumb and a cookie in the request which complicates and slows the downloading of data.

So, my question remains why the request sent by the app returns a blank (although I know for sure that the syntax of the URL is correct because it returns data in a browser on Windows10).

Again, thank you very much for having taken the time to look into my question.

It is not necessarily “blank” (in terms of even though there is no content rendered, there was some [attempt] to exchange some data between the client and the server). I suspect that “Internet Control” object in VB uses MSIE engine under the hood, with all the consequences of that under XP when connecting to a resource not supporting legacy ciphers. Technically you could capture the traffic and see what is really going on there - that can be done with something like Wireshark. Also VirtualBox itself has some packet capture options (see https://www.virtualbox.org/wiki/Network_tips). However, that requires some knowledge.

Thank you very much Leader for your insights.

I suspect as well that Inet1 in VB6 is using the MSIE engine and that’s the reason why I thought that updating the root certificates in IE would help. BTW, when the URL is entered in IE on WinXP, the “Cannot show this page” warning is shown.

I will check into catching the traffic when submitting a request as per your suggestion.

I am also considering installing the VB6 app in Windows10 directly to avoid this whole issue. But I would like to go through all options on WinXP. The app worked like a charm for many years.

Regards,

Robert

I think installing the VB6 app in Windows10 directly will be the better approach, and be easier and faster than trying to convince WinXP to connect securely to this website.

I’m curious; what is the downloading app you are using, and why is it preferable to use it on WinXP?

Btw, if using VirtualBox is a must for some reason, you can always try newer images (including VirtualBox image) from MS: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ (just remember that they are expiring, so you might want to take a snapshot).

The answer is probably found in the reduced number of ciphers and protocols the server is now supporting.
Possibly due to PCI compliance or such.
If you compare the ciphers/protcols supported by WinXP:
https://dev.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP&key=101
with the ciphers/protocols supported by Win10 (IE 11):
https://dev.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%2010&key=131
and with the ciphers/protocols supported by Win10 (EDGE 13):
https://dev.ssllabs.com/ssltest/viewClient.html?name=Edge&version=13&platform=Win%2010&key=130
And you still don’t see the glaring truth, then have a look at the ciphers supported by the server.
Presuming Windows server 2008R2 (or higher):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002:Functions
It should become evident that unless you turn on TLSv1.0 with 3DES on the server(NOT RECOMMENDED), XP will no longer be a viable client.
Can you move to Win7 client, Win8 client, Win10 Client, Linux flavored client,…

Thank you all for taking the time to answer my question.

I (partly) solved the problem by (succesfully) installing the Visual Studio 6 IDE and by setting up my VB6 program on Windows 10. I can download data again in my app’s database.

The conclusion is that the site from which I get the data does not support downloads from apps on WinXP SP3.

Although that is a true statement, is seems a poor/uninformed conclusion.

A broader/clearer conclusion would be: All WinXP SP3 system ciphers are completely outdated and will no longer be supported by any properly secured site.

(don't put the blame on the site for changing with the times - security is a constantly moving target)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.