Mathwiz

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.

@jaclaz; True, it's not really an "attack;" it uses the same approach as an MITM attack, but it's not doing anything underhanded. And the source code is available; I edited my post above to provide a link to it. @Ninho; Turns out you don't need OpenSSL (or Python) after all; if you download the .exe version, everything is already built-in. (I wondered why the .exe was so big!) I edited my post above accordingly. Edit: Probably the biggest maintenance headache will be keeping the root certificates in the cacert.pem file updated. Edit 2: One way to deal with that would be to schedule a command like "curl --remote-name --time-cond cacert.pem --cacert cacert.pem https://curl.haxx.se/ca/cacert.pem" to run monthly (that site keeps a current extract of Mozilla's trusted certificate list at that URL).

Believe it or not, I think I found a solution to this vexing problem: how can we use older browsers with https-secured Web sites that use newer security features than the browser does? The solution I found is a proxy server that performs an intentional MITM (man-in-the-middle) attack on the browser. Obviously that's a security risk, but since everything is running on one machine, the risk is minimal as long as this software properly validates certificates. It's free and can be found here: http://www.proxfilter.net/proxhttpsproxy/. (There's a picture there that explains it better than I can.) I tested it today on my XP VM, and was able to access that aidanwoods.com site with Chrome 34! It was written so the popular Web-filtering proxy server Proxomitron (used to remove ads, etc., from Web pages) could be used with secure sites, but with a simple configuration change, I confirmed it will run without Proxomitron or any other filtering proxy. You'll need a recent version of OpenSSL too. I tested 1.0.2j and it worked, so Ninho should be all set for now. As newer cipher suites become popular on the Web, you'll need to update OpenSSL to keep up, but that shouldn't be a problem. Edit: Turns out you only need OpenSSL for the Python version (as well as Python, naturally); everything is already built into the .exe version at the link above. (If you want the Python version or just want to look at the code, the link is at http://prxbx.com/forums/attachment.php?aid=998.) I think this will work even as far back as Windows 98, but it may be this weekend before I can test it on my Win 98 non-SSE2 system. Once I've done that, I'll post more detailed instructions here and in the Win 98 forum.

Looks like 1.0.2j (1.0.2.10) is the latest version of 1.0.2. (OpenSSL maintains multiple versions at once.) So you're up-to-date. You can get installers for the latest OpenSSL versions for Windows at https://slproweb.com/products/Win32OpenSSL.html. (Despite the name, they also have 64-bit versions available.)

Finally tried it. Its About page reports Chromium, Version 34.0.1847.0. Yet, I don't believe it uses XP's schannel.dll, at least not entirely: It supports TLS 1.2, while IE8 (using the "stock" schannel.dll) doesn't It is susceptible to the "Logjam" attack, while IE 8 isn't It supports several ECC cipher suites, although not any of the cipher suites used by aidanwoods.com, unfortunately Thus, I don't believe Chrome 34's security can be upgraded by replacing schannel.dll Edit: BTW, although Chrome 34 doesn't use schannel.dll, it does use crypt32.dll; but I tried the ReactOS crypt32.dll (plus advapi32_vista.dll from ReactOS) and Chrome chrashed with a missing export in crypt32.dll. So apparently the ReactOS crypt32.dll doesn't implement all the functions Chrome needs. So still no joy. Looks like the OP needs a different approach. Are there any Chromium-based browsers built without SSE2 instructions? Are any open-source so they could be recompiled without SSE2?

Thanks! Is that a portable version? I noticed there's no .msi, setup.exe, etc.; but there is a Chrome.exe.... BTW, I made the mistake of actually reading the thread containing your original post. The last post on page 1 contains a link that appears to take you to a malware site! Be careful....

Evil Dad, I don't trust that site! Clicking the download button leads a page that looks like an ordinary file sharing site at first, but every time I click "download" I get a page trying to trick me into downloading something fishy. The first time, a page came up claiming my Flash player was out of date, which is BS - then it tried to auto-download the Flash "update" without me even clicking anything! (I canceled the download, needless to say.) The download links on that page didn't lead to adobe.com either. I don't think Chrome 34 is at that site at all - looks like just a malware site to me.

Opera 12.02 works on Win98 with KernelEx. But somewhere between 12.02 and 12.17 it quit working You're right; Opera 12 has some problems with modern Web pages. Its Javascript is also rather slow. But I still like it better than the modern, Chromium-based versions. Anyway, back to the topic: where can I get a Chrome 34 (or 35 or 36) offline installer? It seems to be much harder to find old versions of Chrome than other browsers ???

Error 40 would mean a cipher suite mismatch, which I'm pretty sure is the main problem (no ECDHE support). But what heinoganda was pointing out is that he'll also have an issue with the certificate (XP doesn't understand the ECDSA algorithm for verifying the certificate's signature, so it can't consider the cert. valid), so I wanted to see if Chrome was complaining about that first. Up to now I'd been thinking the cipher suite issue is the important one to address, because the certificate issue could probably be bypassed (it works with FF, so Ninho doesn't appear to be using an AV program that's blocking access entirely). But I just rechecked www.aidanwoods.com, and they're even setting HSTS 8-), which may turn the certificate issue into a show-stopper too. If so, that's a lot harder to fix; so much so it's probably best to give up on Chrome 34 and try another browser. So I wanted to check whether Chrome was complaining about the cert. too. (No worries; if Ninho doesn't reply back; I'll check it myself soon enough.) Ninho would need a browser that has ECC built in, that also runs on older non-SSE2 processors. FF 3.5 works, but it's very old and doesn't properly render a lot of modern Web sites. I think that's why he's been trying to get Chrome 34 to work. I haven't tried Opera 12.18 on my oldest PC because 12.18 doesn't run on Win98, even with KernelEx, so I don't know whether it'll run on a non-SSE2 processor. Edit: Just saw Ninho's reply. Looks like Chrome is complaining about the cipher suite, not the cert. (I know it isn't the SSL version, as TLS 1.0 is supported on both ends), so we may still be in business.

OK, but in post #1, Ninho said the site would open in FF (which supports ECC and has its own trusted root certificate store). So either he isn't using a virus scanner with an "Active Certificate Check" feature, or that feature is turned off. I should've asked Ninho what error he gets in Chrome 34! (IE 8 is no help; it just says "Cannot connect to the site." Duh.) But Chrome's error might give us a clue.

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?