Thomas S.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168] "Enabled"=dword:00000000 Save as "Disable ciphers RC4-128-128 3DES-168-168.reg", doubleclick and import. Thats all. You can toggle it to enabled if you set the dword value to 1 (each one or both).

@heinoganda I am not sure and sorry if I am wrong - but is it possible that your very helpfull tool has an old UPDROOTS.EXE ? Randomly I found a hint in the www, that there is a newer version 5.2.xxx available, but in your updater is version 5.1.xxx used. And I don't know if there is such a newer version running under XP, but can you check it please? May be that this is the reason for some certificate issues reported here, but it is only a guess of course.

Very good! Little modifications:

Hmmm ..., I tested now with the older update, and right, I can use TLS1.2 in IE8. But: no registry settings for the older update necessary! And strange is, that https://www.howsmyssl.com/ works (confirmed TLS1.2) but no connection possible is to https://www.ssllabs.com/ No idea With HTTPSProxy there is no problem to access both sites.

Do you have seen that urllib3 is updated to v 1.23 too? There is a importand fix: I think this was the reason why some intermediate certificates must be copied by hand in the cacert.pem

There is a new cumulative update for IE8 on PosReady kb4316682. "Adds the ability to use TLS 1.2 support in Internet Explorer (8)." But it seems that here must be some settings in registry to activate this. I look around, and in an russian forum is this given: And this information: Here in the forum we are advised (among other things) to delete the entry: https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?page=149&tab=comments#comment-1150757 There are some other entrys for an older update (kb4019276) to bring support for TLS 1.1 / 1.2 for XP and Server connections. At this point all this information is not clear (for me ). Is the older update necessary for the new one? In the kb base article there is no such a hint ("There are no special requirements to install this update."). So what is right here? And where came the information from about the registry settings for the new IE8 update? Any official MS site?

You are right! Just tried the same test site, it works with Java v161 in direct XP / IE8 https connection. Three days ago not... So all Java versions properly working on my machine, very good!

Can You give me the http site adress(es)? So I can look whats goig on there! I have looked at this site with http and it works (Java ist running), but then stopped because of my security setup (blocked also in FF 52 ESR). http://www-pw.physics.uiowa.edu/das2/javaPlatformTest.jbf.html#test And if I configure my security settings to run Java with an "unsave site" this is the result in IE8 (drawings with Java script):

Here (above) I show that IE8 is tested OK with running Java v161: Java v161 running in IE8 There is Java code running and confirm the actual status of IE8 online with Java.com. So what You can understad is that Java is supported in IE8. Difficult to understand is why You can't test this with Your configuration. And I can't say, what is on Your configuration missing / wrong set. You have to understand that XP is not really a up to date platform that support actual HTTPS connection to inet. This was it I installed and configured with an HTTPSProxy to get a working connection to Java.com. And this has nothing to do with the support of Java in IE8, because it was the configuration of the external connection to inet that solved the problem.

Java worked on IE8 all the time if it is enabled in browser (via Java control panel) and not disabled on any other way (thats the standard situation). This is also with the actual version v161. When You can't test it with the Java test site from Java.com it is NOT right to conclude "it is not working". You can only conclude that test via Java.com is not working in the standard environment, but You have to look exact why.

Wrong conclusion. You can see three posts above that Java v161 is tested as working on IE8. The (Java) test routine is automatically downloading from Java.com if You go to the Java test site on Java.com. To do so You need an working connection to Java.com But Win XP (and IE8) supports only older HTTPS (TLS 1.0), not newer protocols like TLS 1.1 / 1.2 ... It seems that Java.com has stopped old protocol support, so no connection by default with XP / IE8. To connect inet with XP / IE8 and new protocols You have to install special software - else You are lost. Easy description: The software (an HTTPS proxy) "convert" the old protocol to the new one and do basic certificate management. So You can get the connection and can download and test Java support in IE8. Other sites with Java code, connecting / running in "normal" IE8 will use the new v161 for sure... But this is a rather theoretical discussion, because IE8 does not support modern built sites anyway - and Java is even less used, so that is anyway rather useless. I have disabled Java in all browsers by default, never seen any problem with any sites content. I need Java only for one program that is written in Java script.

Don't be confused, first be sure you need Java. If you do not really know that you need it (for very special inet sites with Java content or for an special program that needs Java) YOU DO NOT NEED IT. To install and activate it by default is a fault (to much security problems). So lean back, stay calm and drink tea or coffee For downloading Java (every version) you need to accept the licence before you can download. And that will not work without cookie etc.

No (I think ). The Java control panel has the image (program) path pointing to (Java v131 on Win 7, tested with Process Explorer) "C:\Program Files (x86)\Java\jre1.8.0_131\bin\javaw.exe" with parameters like: -Xbootclasspath/a:"C:\Program Files (x86)\Java\jre1.8.0_131\bin\..\lib\deploy.jar" -Djava.locale.providers=HOST,JRE,SPI -Duser.home="C:\Users\xxxxxxxx" com.sun.deploy.panel.ControlPanel Nothing with the *.cpl, it may be that the *.cpl only is for starting this program (if it is adressed by the *.cpl, I don't test this).

@all At this point I will inform that it seems that it is not possible to test Java in IE8 because of the min TLS (and / or cipher) versions Java.com support. I will do some research tomorrow and come back... But think about that it is not really necessary to have Java in any browser on inet by default - no need to use and to much security trouble ... If you have no problems to see the information presented on an site (with Java disabled by default in all browsers) you DO NOT NEED JAVA. That's the very very most situation at this time! For the moment quick and dirty: it works in IE8 if you have proper installed HTTPSProxy to support higer TLS / cipher versions in XP.

For what? Java? Here we go: To fix the installing problem in Win XP you can try to "install" the "new" Java file versions by hand in the "old" Java program directory. If you have done the standard installation you have the Java files installed in the default folder "c:\programs\java\jre1.8.0_151" Workaround: Download the new Java files (v161) as packed archive "jre-8u161-windows-i586.tar.gz" Close all programms Via explorer MOVE all the entire files / folders from "c:\programs\java\jre1.8.0_151" to a backup folder (name dosn't matter). Open the archive "jre-8u161-windows-i586.tar.gz" with 7z. In the subfolder "jre1.8.0_161" you can see the same structure as before in the program folder. Copy all files / folders under "jre1.8.0_161" into the default folder "c:\programs\java\jre1.8.0_151" The name of the "old" program folder dosn't matter, it works. If you open the Java control panel you can see and administrate the new version. If you do not wish the old version number as directory name you can do a step before the workaround: Download the latest standalone version running under XP (this is v151, may be it is present on your PC in an temporary folder?) Uninstall the installed version Install the version v151 and change the folder for installation to (for example) "c:\programs\java\" (this is now the new default Java folder) Go on as described above... This works for me. It may be that something will not work, but I don't know any issue at this time. But remember: in the "installed programs listing" you see ever the old (last really installed) version string "v151". And don't be confused about other subfolders with lower version numbers in the Java program directory. If you don't need / use older Java versions (for excample 7) then you can uninstall them - and delete this old stuff.

I have recognised that actual the given lower RSA ciphers are marked as "weak" if you testing the connection with Qualys SSL Lab. So I tried to configure the connection parameters in the py script - but have no success (I don't programming Python...). In "ProxHTTPSProxy.py" line 58 is the expression "sslparams = dict(cert_reqs="REQUIRED", ca_certs=CA_CERTS)" This are parameters for the URLLIB3 "PoolManager", it can modifyed with parameters "ssl_version=" and "ciphers=") The "ssl_version" works for me. With "ssl_version=ssl.PROTOCOL_TLSv1" I will get a connection with the given TLS version (also with "ssl.PROTOCOL_TLSv1_1" / "ssl.PROTOCOL_TLSv1_2"). But with the "ciphers" I am fully lost. Something like this is what I find out, but cant get any connection for testing (only errors): 'ciphers=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+HIGH:RSA+3DES:ECDH+RC4:DH+RC4:RSA+RC4:!aNULL:!eNULL:!EXP:-MD5:RSA+RC4+MD5' I have tried some expressions, only one cipher string, no luck. So my question: any suggestion for help?

KB4019276 is not really helpfull. For my understanding it gives only IIS conections (server - client) the TLS 1.2 option. NOT for https (internet). If you wish to get TLS 1.2 with actual ciphers under Win XP see this thread: Problems accessing certain sites (Https aka TLS) It works great if configured correctly (but sometimes need a little "handwork" for full access to some sites with nested certifikates).

Or this with an workaround

It is true, but not really a problem (for me at this point). Workaround: Extract all files from "jre-8u161-windows-i586.tar.gz" and copy them in the folder where the previous version is installed (previous build "u151", you can delete all old files / folders before copying). All works, also the system control extension. Default folder is "c:\programs\java\jre1.8.0_151" I changed this to "c:\programs\java" in an earlier installation that runs, but dosn't matter, I think. Works for me without error (I use no java WEB-extension, only stand alone Java programs) Here ist an step by step workaround >CLICK<

The Intel message belongs to their CPU microcode updates which are delivered via BIOS updates for several machines / motherboard OEMs. Dont install them at this moment, wait for days (weeks / months - years?) for good working solutions...

Intel withdraws Updates Last update: 23.01.2018 09:54 am Intel has found bugs in the updates against the serious vulnerabilities in its computer processors. The industry giant warned against installing the latest versions. Intel German ARD Tagesschau Heise security

For some reasons long time ago (I dont remember) I uninstalled Windows Search 4 and disabled this update. My puppy search very well and find all what I search for. No problems with my two XP machines at this time...

I have the information that NTFS is the safer file system, especially if you have heavy file I/O and big files (system backup image for example). Else You are right

Hmmm... I use most NTFS formatted sticks because of big files. But I always format the sticks with gparted (have no XP tool). And I have no trouble with this sticks (heavy in use) on two XP SP3 PosReady machines with full patched new ntfs.sys (yes, I have controlled the version, it is actual).

I think if MU ist launched on an patchday it will interfer with MANY other users searching for updates. And it definitly interfer the mechanism for the "yellow shield". If I start MU, after a while (sometimes more than an hour) pop up the "yelow shield" doing "nothing". Downloaded "0 %" as long as MU runs. But if I stopped MU, it shows immediatly (only some minutes) "Updates ready for install". So as you say: waiting until the yellow shield is popping up is a good solution. Only if you need an update asap look at the MS update catalouge for examplen and install the standalone update...