Mathwiz

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.

No such luck for me - I have the PowerPoint Viewer installed, which is based on Office 2010. So I'm screwed for the duration

Wow, what is it with the updates this week? Regular Patch Tuesday updates, Firefox ESR 52.2, Office 2003, not one but two Flash updates, Shockwave for Director, Silverlight - I haven't had this many updates during a single week in years!

Yes, it downloads that relatively small file, which in turn is supposed to download the rest. That 2-stage download has always worked on XP before, but this month, it worked on my Win 7 system but not on my XP system. And I know I had plenty of space, because I had no problems downloading the offline (full) installers and running them. Don't know if anyone else had problems with the online Flash installers though. May have just been some kind of fluke on my system this month.

Bersaglio listed the updates just released yesterday. Most of the updates in Microsoft's tables have been available for some time. KB958644 & KB2347290 were made available back when XP was still supported. KB4012598 and KB4012583 were made available to POSReady '09 systems in March. KB4012598 was made available to "plain" XP after the WannaCry[pt] attack, and KB4012583 was just recently made available to plain XP users. KB4018466 & KB4019204 were made available to POSReady '09 in May. KB4022747, KB4025218, KB4024402 & KB4022343 were part of yesterday's updates. That leaves KB3197835, which is the only one I don't have. It's a new update this month, but I think it only applies if you're running Microsoft's IIS Web server.

I installed 11.00.20. It seems to work, but I've done no significant testing, "extensive" or otherwise.

I just wanted to remark that the "online" installers (that download if you go to https://get.adobe.com/flashplayer/) no longer seem to work on my XP system. I get bogus errors about my C: drive being full. The "offline" installers Bersaglio gives above work just fine, however.

To the best of my knowledge, all you need to do is: Install MSI 4.5 (KB942288) Add the registry key: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady] "Installed"=dword:00000001 And that's it! You should then get PosReady '09 updates. Be aware that if you have any M$ Office products installed, the update scan process will be extremely slow and will take up most of your CPU.