Mathwiz

Thanks. That's what usually works if you've gone a few months without updates. Unfortunately it didn't work for me this time. After downloading, installing, rebooting, and re-enabling Windows Update, it went back to svchost.exe using 99% again And "review your update history" didn't even show 4012204 as being installed So I guess I'll just have to wait it out....

As of today I still see no updates for either Win 7 or POSReady 09. So just for the heck of it, I went to Windows Update with IE 8 and checked for new updates - and now I'm stuck waiting on the svchost.exe using 99% CPU bug! And it probably won't find anything anyway. Exasperating.

Besaglio gave us the link a few posts ago (this is for the regular version though): Like yours, my FF 45 ESR claimed to be up-to-date. I had to download & install the upgrade manually

If using Firefox, search for the CanvasBlocker add-on. It will block or defeat canvas fingerprinting. Edit: Looks like Sampei.Nihira already has CanvasBlocker Edit 2: Well, that was a bust. Cert. Updater is failing for me with this: Open SrcStore failed => 0x80092003 A search turns up: 0x80092003 = CRYPT_E_FILE_ERROR = An error occurred while reading or writing to the file. Something must have had the cert. stores in use. I closed Excel and Windows Live Mail and tried again, and it worked. But I only got an updated ROOTS.SST

Make sure you don't have any of these keys either: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WindowsEmbedded (you said you removed this one already) HKEY_LOCAL_MACHINE\SYSTEM\WPA\WEPOS HKEY_LOCAL_MACHINE\SYSTEM\WPA\WES And make sure you've installed version 4.5 of the Windows Installer.

I thought this thread was dead, but today, 2/14, I saw our old friend KB2952664 reappear in my update list. I guess it's been reissued? I hid it again, but it makes me wonder if M$ is going to make another push to get Win 7/8.1 users to upgrade to Win 10.

I don't see any Win 7 updates today either, so it might be for all - or at least for more than just the POSReady systems.

While you're there, scroll down a little further and make sure you have TLS 1.0 enabled (and preferably, SSL 2.0 and 3.0 disabled).

That error dialog does not look like a root certificate issue to me. If it were, I'd expect the warning flag on the first line, not the third. To me it looks like a problem with the server configuration. That said, it could be that XP isn't handling new certificate extensions, so it thinks the certificate is invalid for the site even though it actually isn't. Have you downloaded the latest IE 6 updates? (You may need the POSReady '09 hack for this.) BTW, if at some point you want to upgrade from OE 6, I'd recommend Windows Live Mail. It's much more like OE 6 than the Outlook from MS Office, and it will import all your OE 6 mail and contacts. The 2009 version runs on XP, but you'll need the offline installer.

Cryptography 1.7.2 is new. A check with my hex editor shows that it has been updated to OpenSSL 1.0.2k. So it looks like your package is up-to-date after all!

OpenSSL version 1.0.2k has been released, which means there should be a new version of the Python cryptography package soon. The issues fixed in 1.0.2k are listed here. Luckily, nothing looks too serious to me, so folks using Heinoganda's packages (which include OpenSSL version 1.0.2j) probably don't need to worry about upgrading immediately.

I'm all for blocking known bad Web sites, and you can find a simple tool for doing so here: http://accs-net.com/hosts/DNSKong.html But bad sites aren't the only risk to your security online. These days, you could be compromised quite easily by a MITM attack from someone at your ISP. Blocking bad sites will do nothing to prevent that. And no one is trusting that "all" vulnerabilities have been found, by M$, OpenSSL, or anyone else. But "known" vulnerabilities should still be taken care of, especially when it can be done quickly and easily. If you're still using IE 8, I'd put installing the POSReady '09 fixes for it, followed by disabling known-to-be-weak cryptography via the registry, in that category. These are not mutually exclusive ideas. Of course you shouldn't tempt fate by driving through bad neighborhoods, but if your key-less entry system has a known weakness, you shouldn't use your superior discretion in route choice as an excuse to ignore the manufacturer's recall notice. Criminals have been known to work in "nice" neighborhoods too.

The main security weaknesses of (unpatched) IE8 and earlier on XP come from its use of older algorithms that now have known weaknesses. If you wish to use IE8 on XP, I strongly recommend installing POSReady '09 updates, then disabling the older, weaker encryption and hash algorithms: You should also disable SSL 2.0 and SSL 3.0 in Internet Options / Advanced / Security. Enable only TLS 1.0. To use the newer, more secure TLS 1.1 or 1.2 protocols with IE 8, you'll need to install a TLS proxy like ProxHTTPSProxy.

Make sure IE isn't set to use the Proxomitron (localhost / 8080) for http connections. It has to get through on http in order to receive the redirect to https. Also, try Heinoganda's ProxHTTPSProxy version (with the updated Python cryptography package); otherwise you'll probably get a 417 error when Google.pl redirects you to https (unless you have google.pl in your SSL Pass-Thru section).

Well, I tried to deinstall the previous version, but naturally, that didn't work either. I got some error message about the installer patch package being invalid! I've had that sort of thing happen before, so I resorted to the "Windows Install Clean Up" tool and did a rogue deinstall. Then installing the current version worked! I hate "installer hell," but at least it seems to be correctly installed now.

That version of Silverlight fails to install on mine:

1. I should point out it's rather easy to use ProxHTTPSProxy without the Proxomitron: just change the line ProxAddr = http://localhost:8080 to ProxAddr = http://localhost:8081 ... so its front server connects directly to its rear server without trying to go through the Proxomitron. 2. I finally figured out which OpenSSL version is included in the standalone (.exe) version of ProxHTTPSProxy. It's OpenSSL 1.02a. As luck would have it, the Logjam vulnerability was fixed in the very next release (1.02b), so the .exe version is indeed vulnerable to that attack (the message from ssllabs.com isn't a false alarm). 3. If you install Python along with all the packages needed to run the Python version of ProxHTTPSProxy, the "cryptography" package will come along for the ride at some point. Turns out it includes OpenSSL 1.02j, so you don't actually need to install OpenSSL for either the .exe or the Python version! The developers of the cryptography package have promised to update it whenever OpenSSL updates their product, so you should upgrade the cryptography package whenever that happens to stay on the most current OpenSSL version. I believe the command to do that is pip install -U cryptography from an XP command prompt. (This assumes Python is in your path.)

I've confirmed that the Logjam vulnerability can be fixed. Apparently the .exe version includes an old, vulnerable version of the OpenSSL libraries. So, I decided to try the Python version. I downloaded and installed the latest XP-compatible Python version, 3.4.4. (Technically, there's a 3.4.5 also, but it's source code only; no Windows installer exists. So if you want Python 3.4.5, you'll have to build it from source yourself.) Then I downloaded the Python version of ProxHTTPSProxy and tried to run it from a command window, but it started complaining about missing packages. So I had to learn how to install all the packages the author had used, using a Python tool called 'pip;' but eventually, it finally ran without complaining about any more missing packages. I then pulled up https://www.ssllabs.com/ssltest/viewMyClient.html in IE 8 and the news was good: "Your user agent is not vulnerable" to Logjam or any other attack tested for at that site! I got this good result with OpenSSL version 1.0.2j .DLLs. For most folks, I don't think it's worth the trouble to download and install Python along with all those missing packages; it's easier to just put banking sites in the SSL Pass-Thru section (so they use the browser's security instead of the proxy's security), or just use a different browser for those sites. I did this just to confirm that the Logjam vulnerability was present due to the OpenSSL version the original author used.

Hmm ... 2nd Tuesday of January and no updates? To be fair, I see no updates for Win 7 either (although Intel has a couple for my hardware)

I think the Logjam attack only applies to cipher suites with DHE (not ECDHE) key exchange, so if you have it, I'd try disabling the ones that start with DHE and leave the other cipher suites alone unless they have other issues (such as RC4).

Try one of the light installers here (I'm not sure which version The Proxomitron expects, though; start with the newest 1.1.0 and back up until one works):

The RC4 cipher isn't considered secure anymore. I don't think it's terrible, but if possible you should disable the suites listed above. If KM is based on FF, you can probably use about:config and search for "security" to find the Booleans to toggle off.

 Uh, Chrome 49? Also, Opera 12.18 works. I would imagine Opera 36 would work too since it uses Chromium. All three run on XP SP3. Edit: Opera 12.18's engine is too old to render some modern sites properly, so even though it works with the reCAPTCHA demo page, you may still want to avoid it.

Thanks for working on this! I'm handling Http:// (not secured) requests another way: I configured my browser to use ProxHTTPSProxyMII as its proxy only for https:, not for http:. Different technique but same result. I've run into some web sites that don't work. Microsoft/Windows Update doesn't work because Microsoft uses its own root certificate that isn't in the supplied cacert.pem or the downloaded one. Rather than appending Microsoft's root certificate every time I download a new cacert.pem, I just put update.microsoft.com and www.update.microsoft.com in the SSL Pass-Thru section of config.ini. (Oddly, catalog.update.microsoft.com does work with the proxy; it uses a different certificate whose root is in cacert.pem.) Adobe.com didn't work either, although I haven't yet figured out why. But generally, if a web site works without the proxy but doesn't work with it, SSL Pass-Thru is a quick and easy fix. Sites listed there are not decrypted and re-encrypted; instead, encrypted SSL data is passed through the proxy unchanged. For the most part, I don't think the proxy compromises security, and in some cases it may actually improve it! I wouldn't be too worried about using it even with on-line banking sites. But SSLlabs.com reports that it's vulnerable to the Logjam attack, so if you're worried about that you can list your bank's site in SSL Pass-Thru. I haven't been using this as an anti-malware filter, but the Blacklist section could certainly be used for that purpose if one wished.

Yes, I think that could be set up; but the way it works, there's still SSL/TLS encryption between the browser and the proxy, so you can't get rid of all the work on the browser's PC. I suppose the trick would be to limit the browser to some less-CPU-demanding ciphers. You wouldn't need super-strong encryption on the browser side since the data would only be flowing over your own network, not the Internet. Perhaps RC4 would be a good choice, even though it's not a good choice for the Internet side anymore. Edit: Well, I just learned something new. Turns out some of the newer Intel and AMD CPUs have AES-specific instructions, making AES faster than RC4! But, if you have one of those new CPUs, you have SSE2 also, so you can run newer browsers and probably don't even need this proxy. So for the browser side, RC4 is probably the best choice if you're reading this thread.