Jump to content

Problems accessing certain sites (Https aka TLS)


Recommended Posts

I have XP SP3 updated under the guise of "faux POS" (not all updates applied though)

Lately I find some cases - more and more often - of HTTPS sites that :

- under XP, won't open in Chrome (nor IE), i.e. using Windows own crypto API - but that -

- will open under Firefox - which has its own crypto stuff - even a very old version (3.5) works !

- under Seven, for compare, same sites do open even in Chrome (or, God forbid! IE).

An example page there exhibiting the phenomenon : https://www.aidanwoods.com/blog/faulty-login-pages/

Is it expected with fully updated XP SP3 and/or "POS" windows ? Or have I missed a related update ? For reference I have : crypt32.dll version : 5.131.2600.6459 (xpsp_sp3_qfe.131005-0434) and rsaenh.dll : 5.1.2600.6924 (not that I'm half sure those particular dll's are the keys of the problem)... 

Edited by Ninho
Link to comment
Share on other sites


Try that page:

https://www.aidanwoods.com/blog/faulty-login-pages/
 

 on your system with QTWEB:

http://www.qtweb.net/

(should work fine).

If you try it with Opera 12.15 it should give you "error 40" :unsure:

BUT it should work with Opera 12.18.

You can use the portable versions to make the test:
http://www.opera-usb.com/download.htm

If this is the case, the issue shoud be "elliptic curve crytography":

http://www.opera.com/blogs/security/2016/02/opera-12-and-opera-mail-security-update/

jaclaz


 

Link to comment
Share on other sites

There don't appear to be any cipher suites in common between XP's schannel.dll and www.aidanwoods.com. The latter requires ECDSA for key exchange but schannel.dll only supports RSA.

Substituting the latest schannel.dll (and mbedtls.dll) from the latest ReactOS beta (0.4.3) may help, but I haven't tried it.
 

Link to comment
Share on other sites

2 hours ago, Mathwiz said:

There don't appear to be any cipher suites in common between XP's schannel.dll and www.aidanwoods.com. The latter requires ECDSA for key exchange but schannel.dll only supports RSA.

Substituting the latest schannel.dll (and mbedtls.dll) from the latest ReactOS beta (0.4.3) may help, but I haven't tried it.
 

Interesting find, thanks. Is there even a slight chance for such substitutions to work ? I know I've tried subsituting dll's from win 7 - not that I really expected that to work - and indeed, XP just died (blue-screened) during the boot sequence. 

OK, if you could post the dll's somewhere, I'll try substituting them (I'd rather not download the whole ReactOS - beta, which I don't use).

Link to comment
Share on other sites

There's some chance it'll work; probably a better chance than with the Win7 version (IIRC, that's been tried and didn't work).

The .dlls aren't very big, and ReactOS is free and open-source, so I think it's OK to post them here.

Just make sure you back up the schannel.dll that came with WinXP before you do anything with these!

You may need to shut down XP and copy them to your windows\system32 directory off-line. Also copy schannel.dll to the dllcache subdirectory if System File Checker is enabled; otherwise XP will just put the old schannel.dll back.

If you try it, let us know how it went, whether success or fail ;)

Edit: Link removed. It wasn't working (see below) but took up too much of my limited MSFN space.

Edited by Mathwiz
Link to comment
Share on other sites

I just installed the two files (version number of scannel.dll increased by one point and corrected checksum) into an updater and starts Windows XP but still ECC certificates are not processed (tested with Google Chrome, IE8 crashes with encrypted website).

@Mathwiz

Next time try your own virtual machine. :lol:
I almost forgot, you would not want to "test" this update? Nevertheless, now it is an enriching experience.

:)

Edited by heinoganda
Link to comment
Share on other sites

Sure, I could test your update on my VM - but your initial results have me wondering about something else: if ReactOS's schannel.dll crashes IE 8, but it works with Chrome, would it be better just to put both .dll's in Chrome's program directory? Would that let Chrome use the ReactOS version while IE 8 still uses Microsoft's version?

If you think that might work, I'll give it a try next week.
 

Link to comment
Share on other sites

On my XP SP3, running with the dll's from ReactOS : similar to Heinoganda's report, Chrome works fine, including with https sites, but the problem with sites s/a the example given upthread using newer incompatible encryption and/or key exchange only, is not solved by the replacement yet :=(

I am suspecting the schanell.dll is not the one (or not the only one) involved. 

Link to comment
Share on other sites

Well, using the site https://www.ssllabs.com/ssltest/viewMyClient.html I found the both Firefox and Chrome are supporting TLS 1.2 with the schannel.dll provided with the XP. So, I strongly doubt the Chrome is using schannel.dll. So, replacing the file to the React OS version should not affect both Chrome and Firefox.

On the other hand the ChromeSetup.exe does not work with the React OS schannel.dll. So, the Chrome setup does use the schannel.dll, after all.

Link to comment
Share on other sites

1 hour ago, Sfor said:

Well, using the site https://www.ssllabs.com/ssltest/viewMyClient.html I found the both Firefox and Chrome are supporting TLS 1.2 with the schannel.dll provided with the XP. So, I strongly doubt the Chrome is using schannel.dll. So, replacing the file to the React OS version should not affect both Chrome and Firefox.

I guess it depends on the version of the Google Chrome browser one is running. While researching this issue a little more in breadth (if not in depth) I read that Chrome has had its own crypto for TLS and so on, starting from Chrome v. 37. But in my case I have Chrome 34 and stuck with it (for it is the last Chrome version able to run on a processor without SSE2 like my AMD Athlon XP) - this explains why our respective findings may differ in this respect : my Chrome still relies on Windows for the TLS crypto stuff.

Link to comment
Share on other sites

It's good that Chrome 34 doesn't just crash with these .dll's like IE 8 apparently does. This Tuesday (given time) I will try the combo of Chrome 34 and ReactOS .dll's on my own VM and see if I can make it all work.

Looks like some registry keys may be needed in order to enable TLS 1.1 and TLS 1.2. The ReactOS SChannel.dll appears to look in keys like HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols\<Protocol ID>\Client for a DWord value of "Enabled." Looks like 1 means enabled and 0 means disabled.

XP's registry has keys with protocol IDs of SSL 2.0, SSL 3.0, and TLS 1.0, but not TLS 1.1 or TLS 1.2. I'm guessing if the keys aren't there, SChannel.dll defaults to protocol disabled. I'll try adding the missing keys and see if I can get TLS 1.2 working.

Not sure if TLS 1.2 will help with the missing cipher suites Ninho needs, even though I'm pretty sure MbedTLS.dll does support them, but I'll let you all know what happens.

Link to comment
Share on other sites

Well, I'm unable to install the Chrome 36, as it is always updating itself to 49. So, I can not test how it behaves with TLS.

I think the first thing to test is if Chrome is able to work without schannel.dll. There is a chance, the Chrome prior to 37 does have it's own TLS support (without TLS 1.2, however). Without knowing that there is a chance of wrong understanding of what is going on with the Chrome and schannel.dll.

Edited by Sfor
Link to comment
Share on other sites

The problem is not TLS 1.2, which is supported on Google Chrome, as well as ECC certificates. The actual problem is the Windows XP no ECC certificates can be administrated or not registered and these are recognized as invalid.

:)

Link to comment
Share on other sites

3 hours ago, heinoganda said:

The problem is not TLS 1.2, which is supported on Google Chrome, as well as ECC certificates. The actual problem is the Windows XP no ECC certificates can be administrated or not registered and these are recognized as invalid.

:)

:thumbup Which was what the OP was told initially, but decided to ignore ... :whistle:

jaclaz


 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...