Ninho Posted December 30, 2016 Posted December 30, 2016 (edited) 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 December 30, 2016 by Ninho
jaclaz Posted December 30, 2016 Posted December 30, 2016 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" 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
Mathwiz Posted December 30, 2016 Posted December 30, 2016 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.
Ninho Posted December 30, 2016 Author Posted December 30, 2016 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).
Mathwiz Posted December 30, 2016 Posted December 30, 2016 (edited) 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 November 21, 2019 by Mathwiz
heinoganda Posted December 30, 2016 Posted December 30, 2016 (edited) 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. I almost forgot, you would not want to "test" this update? Nevertheless, now it is an enriching experience. Edited December 30, 2016 by heinoganda
Mathwiz Posted December 31, 2016 Posted December 31, 2016 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.
Ninho Posted December 31, 2016 Author Posted December 31, 2016 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.
Sfor Posted December 31, 2016 Posted December 31, 2016 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.
Ninho Posted December 31, 2016 Author Posted December 31, 2016 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.
Mathwiz Posted December 31, 2016 Posted December 31, 2016 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.
Sfor Posted January 1, 2017 Posted January 1, 2017 (edited) 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 January 1, 2017 by Sfor
dencorso Posted January 1, 2017 Posted January 1, 2017 Install physically disconnected from the internet, then change the name of the updates folder, then connect to the net. It won't be able to update anymore, but should otherwise work OK.
heinoganda Posted January 1, 2017 Posted January 1, 2017 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.
jaclaz Posted January 1, 2017 Posted January 1, 2017 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. Which was what the OP was told initially, but decided to ignore ... jaclaz
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now