Mathwiz

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.

@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.