Mathwiz

Last few weeks, MsMpEng.exe has been using more and more CPU, to the point where it's really slowing down my VM: Is anyone else seeing anything like this? I tried RUAE followed by re-downloading the latest definitions, but it didn't make any difference.

Just updated. A screen opened warning that XP & Vista would no longer be supported beyond this release. Edit: For "unofficial" support beyond FF 52.9, Roytam's XP-compatible builds of Basilisk/Serpent 52 or New Moon 28 (soon to be in beta) would seem to be good bets.

Looks like MSFN is using a self-signed certificate for some of the content of their emails. I don't get their emails so I don't know. You can fix the first "!" by clicking "Install Cert" and installing the certificate as a trusted root certificate, but I don't think that will fix the last "!". As for OE8, there is none; the closest is probably Windows Live Mail (2009 version). You'll need the offline Windows Live 2009 installer. It's very similar to OE6, except with a more "Vista-esque" appearance. At least it will migrate your OE6 emails, unlike many other email clients.

You can disable the RC4 cipher with RegEdit. Navigate to the "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128" key and create a new DWORD value named "Enabled". Leave the value at 0. You can disable the 3DES cipher the same way. That will make howsmyssl.com happy, but when I tried it, I could no longer access MU; so I re-enabled 3DES. It isn't that insecure....

I checked my own system, and the mshtml.dll file from KB4230450 is installed there. (Fearing the typical long wait from MU, I had downloaded and installed KB4230450 directly from the Microsoft Update Catalog, and didn't rely on MU to find it.) Given its later date, it probably has some security fixes beyond KB4316682, since we know TLS 1.2 support is included in both updates. It seems KB4316682 is superseded by KB4230450. But if folks installed KB4316682 and relied on MU/WU/AU to find the latest updates, they would have missed KB4230450 due to the version number mix-up, so they should now download and install it manually from the catalog. It will probably all shake out next month anyway, when the next Cumulative IE8 Update or Security Update is released. The version numbers probably won't stay the same next time....

Another solution might be a bare drive along with this ezDISK HDD dock: https://www.amazon.com/ezDISK-EZ0330-docking-station-compatible/dp/B0755P3R4H It has a switch to select 512-byte or 4K-byte sector sizes with AF drives. For XP use, just set the switch to 4K, plug in a nice, big, bare drive, and partition and format it as desired. For some reason it claims a 10TB limit. Not sure what that's about (I'd think it would work up to 17TB, if you could find a bare drive that big).

My experience was that the latter update did not stop TLS 1.2 from working, but apparently it doesn't enable TLS 1.2 either; you still must install the former update. The latter update is apparently "cumulative" only for security fixes; the former is "cumulative" for enhancements too, and MS must consider TLS 1.2 support an "enhancement." IOW, MS's use of the word "cumulative" is a bit misleading. Edit: Never mind; I either missed or misread @Dave-H's post above, where he said KB4230450 was enough to enable TLS 1.2. I installed KB4316682, and that was also enough to enable TLS 1.2. Furthermore, @antiproton reported that KB4230450 wasn't offered after installing KB4316682, so apparently there's nothing new in KB4230450 that wasn't in KB4316682 from a few days before. So why two different updates then? I suppose it's still possible that KB4316682 included something that KB4230450 didn't; but if so, it wasn't TLS 1.2 since that was included in both. Sometimes MS just makes no sense at all....

So it appears you need both KB4019276 and KB4316682 for TLS 1.2 in IE8, and if you've installed those two, you probably don't need KB4230450. But you'll still need next month's cumulative security update, and you'll still need to install it manually to avoid the hours/days(/weeks?)-long wait for AU/MU/WU to offer it. I didn't want to wait to see if KB4230450 would be offered, so I went ahead and installed it manually last Tues. (I had already installed KB4316682 and confirmed that TLS 1.2 worked.) Apparently I didn't need to do that, but it didn't hurt anything (TLS 1.2 still works). I had installed KB4019276 back on 28 Nov. At least that's what Add/Remove Programs tells me.

It's weird that KB4230450 was released just a few days after KB4316682. Both are IE8 cumulative updates, so (in theory) KB4230450 should include everything that KB4316682 did; at least that's my understanding of the word "cumulative." But I never checked the contents so I don't know for sure. I just installed KB4316682, then found KB4230450 had been released and installed it too. Nor did I check whether either/both of those also include everything KB4019276 did, but since @Dave-H already had that one installed it shouldn't matter. Anyway, if he didn't install KB4316682, it's probably worth checking IE8 (bypassing ProxHTTPSProxy temporarily) to see if TLS 1.2 is working. Just visiting good ol' https://www.howsmyssl.com should do the trick. If it isn't, go ahead and install KB4316682 and check again. Inquiring minds want to know!

I've had RC4 disabled for some time and never had an issue. But disabling 3DES blocked access to Microsoft Update :(

If true, my concern is that M$ would do a "rush job" to get the necessary updates in before April 2019, and we'd wind up with a buggy update just as support ended. I would not consider TLS 1.2 unsafe. It's surely the best widely-supported protocol at present. TLS 1.3 is still mostly experimental. The ultra-paranoid can disable all cipher suites except AES 128 and AES 256. (Edit: I found I also had to leave 3DES enabled in order to get Microsoft Update to work!) Start regedit and go to HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers and you will find a subkey for each possible cipher. Create a DWORD value named "Enabled" under each one (except AES 128 and AES 256) and leave its value at 0. You can also disable the MD5 hash under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes the same way.

To summarize, KB4019276 adds TLS 1.2 support to Windows XP Embedded. That lets you use TLS 1.2 with, e.g., Chromium, but not IE8. The new update, KB4316682 adds TLS 1.2 support to IE8. KB4316682 isn't available via Auto Update, although as a cumulative IE8 update, it's probably just as well (WU would take forever). The registry changes (which I had already made) are needed in order to let you configure IE8 to use TLS 1.2. So you need all three. (Although I haven't looked inside KB4316682, so I suppose it's possible that it includes the updated files from the earlier KB4019276.)

The more I look at this, the more suspicious it sounds. I suppose it's possible, but I don't think PayPal would send an email asking its users to upgrade their browsers. I think it may have been a phishing email. I hope you didn't click on any links in the email. If you did, I'd recommend you go to paypal.com right away, change your password, and check for any unauthorized transactions.

That happens when you access msfn.org with https:. Msfn.org supports https:, but isn't quite smart enough to replace http: with https: in iframe links. So to protect you from the possibility of a hacker intercepting the unsecured iframe and replacing it with malicious content, you get that stupid padlock with the warning icon. You can click the padlock and disable protection, and the page will reload with the unsecured iframes. The padlock and the "https:" in the address bar will then be struck through to remind you that you aren't really secure. I wish Firefox would let us permanently disable protection on a per-website basis, instead of having to do this every time a page comes up with grey boxes like that. Edit: BTW, if you're using HTTPS: Everywhere, your connection to msfn.org probably is secure; it's just that Firefox doesn't know it!

Personally, I think Wikipedia is over-reacting a bit. Certainly, 3DES isn't as secure as AES, but AFAIK cracking it still requires guessing about 108 random bits. (A 3DES key is 168 bits, but around 60 of those bits can be figured out without having to guess them.) AES requires guessing at least 128 bits, so cracking it is at least a million times harder, but even with today's more powerful hardware, 108 bits is plenty of security. Edit: Come to think of it, the problem with 3DES may not be the key size, but rather the fact that it only encrypts 64 bits at a time. With enough data, this could allow an attacker to exploit the "birthday paradox" to find accidental collisions (different 64-bit blocks that happen to encrypt to the same value), and work backwards to reduce the number of key bits that need to be guessed. With AES, 128 bits are encrypted at once, so the odds of such a collision leaking info about the key are extremely remote. So maybe Wikipedia is being prudent after all. In any case, there's probably not much point in using IE8 anyway, unless you're browsing sites that use IE-specific tech like ActiveX (I still run into a few of those on occasion). But if you're determined to do so, you can use ProxHTTPSProxy with IE8 to provide modern, more secure ciphers. With ProxHTTPSProxy, Wikipedia comes up fine in IE8 with no security warning. (He can correct me if I'm wrong, but I believe @Heinoganda has updated ProxHTTPSProxy with a newer OpenSSL version that closes even more security holes.) Edit 2: BTW, from their warning about security flaws, I can see that Wikipedia doesn't know about the POSReady hack for Windows XP

Those are nice, but how about explaining what each one actually does? That way we could choose the ones we want, or re-tweak them to better fit our own systems.

Under normal circumstances, the user-agent string is more or less fixed: it only changes when your browser gets updated. So it doesn't leak a lot of info to the Web pages you visit; basically just your browser and OS. So, to stay "under the radar" as much as possible, I'd say you want to choose a common user-agent string rather than a rare one. You want to look just like millions of other folks browsing the Web. Also, for maximum compatibility, you probably shouldn't misidentify your browser too much. Web sites use the user-agent string to figure out what Javascript code, e.g., to send to your browser. So given the above, I'd probably lie about my OS (e.g., say it's Windows 10 or at least 7 instead of XP). The only place that would likely matter is microsoft.com. But I'd mostly tell the truth about my browser, unless it's a rare one. I might tell Opera to pretend it's Chrome or Seamonkey to pretend it's Firefox, for instance; and probably report the latest version of those browsers, since most users would be running the latest version. The only pitfall would be if a Web site sent code intended for the latest version, that doesn't run correctly on the actual browser version I'm running. But even if I reported my correct browser version, I suspect most of those Web sites wouldn't send compatible code anyway - they'd probably just tell me to upgrade my browser!

I guess the only problem with that string is that it'd stick out like a sore thumb to Web sites that "fingerprint" their visitors (the better to track them). But hopefully it'll be pretty compatible. Let us know if you run into any problems with specific Web sites using it. One of the things I liked about Opera (at least Opera 12; I haven't tried this with the newer Chromium-based versions) is that you could set your user agent string on a site-by-site basis to report as Opera, Firefox, or IE, so you could work around sites that insist on IE or Firefox because they never heard of Opera. Come to think, I wouldn't be surprised if there's a Firefox or Chrome add-in that does something similar (although I haven't looked).

Hi! Yes, I saw your post about spoofing the user-agent string. A useful technique! But even if I bypass the stupid sites that blindly block browsers they consider too old, I still run into other problems if my browser really is too old.

I think the Web is the primary driver of planned obsolescence in today's computers. Try surfing with an old Web browser; say, Opera 12. You'll run into all sorts of major sites (e.g., Facebook) that just don't quite work right, even if they worked fine a year or two ago. So if you surf the Web, you need to use a reasonably up-to-date browser. Doesn't have to be absolutely the latest, but it can't be too old. And so, you need an OS that will run reasonably up-to-date browsers. Right now, in the Windows line, XP is about as far back as one can easily surf the Web with. Maybe 2000, with some difficulty; but 98 or ME will be really tough slogs. There just isn't a new enough browser that will run on those OSes. P.S. I like the classic theme too.

I did see that it was a QFE, so I guess it's not ready for general distribution yet. I'm still surprised they didn't sign it, though. I can't see why MS would own up to releasing an update that makes your network vulnerable! Hopefully they only mean it hasn't been fully tested yet, so they can't yet say with reasonable confidence that it won't make your network vulnerable. I agree - no need to rush to install this one. Presumably, once it's fully tested, it'll be rolled into the next cumulative IE8 update anyway.

Apparently available only from the MS Update catalog; not (yet) via AU, WU, or MU. (But come hell or high water, we get those time zone updates!) Also the downloaded file appears to be unsigned? Very unusual for MS....

Hmm... don't know then. It looks like you're running a 64-bit OS, but if it's the 32-bit version of Opera 12.18 (build 1872), it should still work. The only other difference I see is that I let the Flash installer install the latest versions, so my Flash ended up at C:\WINDOWS\system32\Macromed\Flash\NPSWF32_26_0_0_131.dll (yours would end up at C:\Windows\SysWOW64\Macromed\Flash\NPSWF32_26_0_0_131.dll) instead of in C:\Program Files (x86)\Opera\program\plugins. The advantage is, it can be shared by Opera and Firefox. Can't imagine why installing it in the Opera folder might cause a crash though.

Isn't 26.0.0.133 beta? Try the released version, 26.0.0.131, and see if it works OK.

Yes, apparently the viewers use some of the same .dll's as the full Office 2010 install - I guess the same way the 2007 compatibility pack uses some of the same .dll's as the full Office 2007. So if they update any of those .dll's used by the viewer, I get the Office 2010 update through Micro$oft update - and it does make the scan go to 99% CPU. I have to let it run overnight.