• Content count

  • Joined

  • Last visited

  • Days Won


Mathwiz last won the day on January 10

Mathwiz had the most liked content!

Community Reputation

10 Good

About Mathwiz

  • Birthday

Profile Information

  • OS
  • Country
  1. 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 redirects you to https (unless you have in your SSL Pass-Thru section).
  2. 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.
  3. That version of Silverlight fails to install on mine:
  4. 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 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.)
  5. Heinoganda's certificate update tool downloads the latest root certificates into the Windows XP certificate store (used by IE and Chrome). It's a good idea to run it every month or so, since these don't get updated by the POSReady '09 hack. Other browsers such as FF have their own root certificate stores that won't be updated by his tool. Note that the XP certificate store doesn't support certificates signed by the ECDSA algorithm - one of the reasons we needed a workaround for web sites using these. ProxHTTPSProxy stores its root certificates in a file called cacerts.pem (for folks using it as a workaround for outdated security in their browsers).
  6. 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 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.
  7. 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)
  8. 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).
  9. 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):
  10. 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.
  11.  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.
  12. 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 and in the SSL Pass-Thru section of config.ini. (Oddly, does work with the proxy; it uses a different certificate whose root is in cacert.pem.) 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 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.
  13. 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.
  14. @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" to run monthly (that site keeps a current extract of Mozilla's trusted certificate list at that URL).
  15. 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: (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 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 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.