Mathwiz

I see; but in the absence of such AV products, doesn't the lack of a trusted root cert. normally cause the browser to only pop up a warning (the site's identity cannot be confirmed; you may be getting MITM'ed; proceed at your own risk, etc.), which can be ignored?

I'll try to explain, but it's going to be a long post. My understanding is that SP3 (plus post-SP3 POSReady '09 updates) added support for AES, not ECC. The AES cipher was an important addition, because all the other supported ciphers are now known to have weaknesses. But there are two parts to TLS encryption: the cipher itself, and the key exchange algorithm. (The combination is called the cipher suite. Actually there's a third part: the hash algorithm used for digital signatures, but I'll ignore that for now.) The cipher is used to encrypt and decrypt the data being transmitted, but the key exchange algorithm is needed so that a randomly-generated cipher key can be shared between the client and server secretly. The traditional key exchange algorithm used in SSL and TLS is based on the RSA public-key cryptography algorithm. But the Snowden revelations showed there was a weakness in RSA: an eavesdropper (whether the NSA or just some hacker group) could record all encrypted traffic with a given server, then, if they were later able to steal or extort the server's private key, they could go back and figure out all the different random keys that were used, and therefore could decrypt all the prerecorded traffic. As a result, sites have been switching to a different key exchange algorithm called "Diffie-Hellman Ephemeral." With this algorithm, even if an eavesdropper steals a server's private key, they can't go back and decrypt any prerecorded encrypted traffic. The best they can do is a man-in-the-middle attack to decrypt future encrypted traffic. The only problem with the DHE algorithm is that it takes a lot of server CPU, unless elliptic-curve cryptography is used. So sites have been switching to "ECDHE" for performance reasons. (Personally, I think most sites should still support RSA as a fall-back for those of us with older software; as long as we're aware of the risk. But that's just me.) AFAIK the latest schannel.dll added support for the AES cipher but didn't add any new ECC key exchange algorithms, so it only has half of what's needed to connect to www.aidanwoods.com. I was hoping the ReactOS schannel.dll would add the other half, as explained above. I really didn't mean to open such a huge can of worms, though! But I'll keep working on it, on my own; maybe I'll eventually come up with something, maybe not. Oh, man; sorry about all those italics! I was just trying to put a bracketed "I" in the quote, and the forum software thought I wanted everything in italics

It's true that the problem connecting to www.aidanwoods.com isn't TLS 1.2. Www.aidanwoods.com supports TLS 1.0, and according to ssllabs.com it will connect using TLS 1.0 to IE 7 (!) on Vista. Apparently that site does support one cipher suite which is compatible with TLS 1.0, so I no longer think TLS 1.2 will help connect to it. And ssllabs.com reports that even Chrome 49 won't connect to that site on XP. The only cipher suites supported by www.aidanwoods.com use elliptic curve cryptography for key exchange, and stock XP doesn't support ECC. (To see what www.aidanwoods.com will and won't connect to, you can go to https://www.ssllabs.com/ssltest/ and enter www.aidanwoods.com. Takes a few minutes to run all the tests.) MbedTLS.dll does support ECC, however, which is why I suggested the ReactOS schannel.dll: it was originally the Wine version of schannel.dll but was rewritten use MbedTLS.dll for its cryptography functions. So there was at least a chance it would work. But apparently additional .dll's are needed for full ECC support. Sorry it didn't work out; nevertheless, it would still be useful to get native TLS 1.2 support on XP. (Sfor, for example, has a need for TLS 1.2 support for some of his software.) So I still plan to investigate.

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.

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.

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.

If you install the PowerPoint 2010 viewer, then install all available updates (via, e.g., MS Update), then install all updates again (the first round installs SP2; then a bunch of post-SP2 updates appear), you'll get the latest usp10.dll version: v. 1.626.7601.23585, dated 11/15/2016. I'm sure you could do the same thing by just downloading the relevant update and extracting the usp10.dll file from it, but I'm too lazy to figure out which update had it!

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.

Latest Flash is 24.0.0.186, and seems to run fine on XP

I really don't understand why Chrome, FF, and Opera all jumped on this silly "major version number only" bandwagon. All it does is obscure the difference between minor bug-fix updates and major feature upgrades. What's wrong with the v.r.m-style version numbers every other software product uses?

Thank you. I went ahead and downloaded it to a USB (old-fashioned FAT32) thumb drive. Not that there's anything wrong with USP4 (except perhaps its size), but it is nice to have the individual components as standalone downloads. It's strange that Micro$oft removed that particular download, yet kept the others. You'd think if it was an EOS issue, they would have removed them all if they removed any.

I hate to quote a year-old post, but the Microsoft link above no longer works. I tried https://support.microsoft.com/en-us/kb/955704; it looks like the exFAT driver is only available for XP x64 and Windows Server 2003. I guess the only remaining place to get the exFAT driver for 32-bit XP is the unofficial SP4?

That's a good link for checking browser security. You'll be glad to know that a FF version as old as 31.8 ESR passes with flying colors - at least, it does once you go into about:config and turn off a few obsolete encryption protocols But the newer versions can do things like HTML5 video that 31.8 can't.

It's confusing. Basically FF 52.1 ESR comes out at the same time as FF 53, FF 52.2 ESR comes out at the same time as FF 54, etc. There are usually 8 releases, so the end of the line will probably be FF 52.8 ESR coming out with FF 60. Each ESR release runs about a year, and 52 will start in 2017, so it should end in 2018. Of course none of these FF versions will have a "time bomb" that will make them stop working after that point; you just won't be able to get any further updates on XP. Eventually, the Web will be using new standards that don't even exist yet, so over time you'll start seeing more and more Web pages that don't work properly on FF 52.8; but it'll probably be 2020 before that's a significant problem.

I remember reading your post, but I didn't realize that I didn't have it installed already! I'm running the Windows XP mode that you get free with Windows 7 Pro; I would've thought something that important would already have been included, just as it was with "real" POSReady '09. Besides, there seems to be no easy way to tell which MSI version is installed on a given system. MSI isn't listed in Add/Remove Programs (except as a "hotfix" when you install 4.5). Hopefully there's an easier way, but at least I've identified one way to tell: if after installing POSReady '09 updates, text disappears from any Microsoft Installer dialogs (such as the word "Cancel" on the Cancel button), then you don't have MSI 4.5 and need to install it. And you're right: harkaz really needs to add that info to post 1 of the POSReady '09 thread. It would save folks like me a lot of grief! Edit: After reading your other posts, it looks like what happens is that some of the POSReady '09 updates apply fixes to MSI, so if you don't have the right version to start with, you end up with a "mixed" set of MSI files (some 3.1 and some 4.5). That probably explains the garbled installer dialog boxes. Presumably, installing the MSI 4.5 hotfix sets everything right again, since it would replace the 3.1 files, but the 4.5 files installed by the updates would be recognized as newer, and not downgraded to the original, insecure versions.

Oh - MSI 4.5, not MSE 4.5! I wasn't able to tell if I had it installed already, so I just downloaded it and (re?)installed it. I don't understand how that would affect MSE's scanning process though. Edit: Looks like I did need it - installing it fixed some, um, "anomalies" that I started seeing after installing all the POSReady '09 fixes (such as the word "cancel" missing from the Cancel button when installing something). My Cancel buttons say "Cancel" again!

OK, I found, downloaded & installed MWB 1.75. The installer is very aggressive in trying to immediately update you to V2 though. You have to tell the installer not to update, then when you launch the program, you also have to tell it not to update, at least until you've gone in and unchecked the program update settings as you explained above. I'm not going to try to scan with it until I've made a complete backup though. I don't want a repeat of last week!

I thought 4.5 and up didn't work on XP anymore (except the 4.8 version you patched).

Don't worry, it wasn't your fault. And I was able to mount my hosed .vhd and copy everything I thought was important (mostly emails) to the new system. If I try Malwarebytes again, I'll try the 1.75 version recommended by others. BTW, it looks like I spoke too soon - MSE is freezing up on scans again I'm pretty sure there's no malware on my system this time. The only things I've updated since the scan that worked was Firefox (from a very old version - 3.5 - to a slightly less old version - 31.8 ESR), Opera (12.17 to 12.18), Adobe Reader (from 10.something to 11.0.16), Flash and Shockwave Player (to the current versions). And of course, a slew of POSReady '09 updates from Microsoft. Seems unlikely that any of those would cause MSE to freeze on a scan, but it must be one of them! Edit: Just remembered I also put NirSoft's Opera Password Viewer, and Elaborate Bytes' Virtual Clone Drive on the system. But that's it, I'm sure!

Yes I'm giving it 1 GB. I've been thinking of upping it to 2 GB though. I tried MalwareBytes' Anti-Malware, but it kinda hosed my system. The virtual machine just crashed, and when I rebooted, all my personal settings (wallpaper, screen layout, etc.) were gone! So I went back to an old backup and started from scratch. Put in the PosReady '09 registry hack, re-downloaded everything including MSE, and this time, the scan completed! So I guess it's fixed, but I'll probably never know what was wrong with it to start with.

Ran heinoganda's batch file, then re-downloaded and installed the current MSE definitions. This time it got up to 31983 entries. Stopped on Screen Saver.lnk shortcut again. That's the first time it's stopped on the same file twice, so I think I'll delete that shortcut and try again. This is running on Windows Virtual PC, so I'm pretty confident it's not a hardware problem

Well, it looks like the update that won't go away on your system (KB2756918) is specific to .Net 3.0 SP2. So you shouldn't need to uninstall and reinstall any .Net version other than that one. I only had to uninstall and reinstall .Net 4, but that was complicated by the fact that .Net 4 is split into two parts (Client Profile and Extended). I don't think that's true of .Net 3.0 or any other .Net version.

No errors on C:. Well, it was worth a shot. With sig file 2434.0 it got up to 31951 items before freezing. This time it froze on or around item c:\...\Desktop\Screen Saver.lnk. When I try to restart, it says Microsoft Security Essentials is not responding. I click "End Now," then it goes ahead and ends anything else that's running, then it gets to the "Logging off..." message and won't go any further. I have to turn it off and reboot. I suspect it's actually freezing on an item other than the last one it shows. I don't think it displays every item it scans, since the "Items scanned" often goes up by much more than one each time the screen updates. Makes it kind of hard to tell which item is actually causing it to freeze, though.

You should measure the resistance of the sensor with your thumb over it (so no light is reaching it) and use a potentiometer of similar or slightly larger resistance.

Disregarding whether or not Windows detects a light sensor, is there one physically present on your laptop? Probably looks like a small hole somewhere around the display.... I'm one of those old "hardware guys" who'd be tempted to fix this problem by opening up the display case and soldering a trimmer potentiometer across the bloody thing. Then adjust brightness to taste