Mathwiz

I assume you mean @roytam1's New Moon, or maybe you're testing on Win 7 - anyhow, in compatibility mode, New/Pale Moon both spoof FF 60.9. Have you tried setting general.useragent.override to "Mozilla/5.0 (Windows NT 6.1; rv:60.9) Gecko/20100101 Firefox/60.9"?

Almost. (I assume that unlike me, you have a full version that will not expire!) You also need Perl and NASM. I used Strawberry Perl, available from http://strawberryperl.com. NASM is available from https://www.nasm.us. Both are free. After installing them, make sure both are in your PATH. Edit: I forgot to mention; once you install Perl you need to install the "Text::Template" module. To do this, enter the command cpan Text::Template I created OpenSSL with all default options, except for forcing XP compatibility. VSE 2010 puts a "Visual Studio Command Prompt" on the Start menu. It runs a batch file that sets up the necessary environment variables. I selected that, then ran these commands: $ perl Configure VC-WIN32 -D_WIN32_WINNT=0x0501 $ nmake $ nmake test $ nmake install nmake is part of VS2010. The '$' above stands for the C:\> command prompt. The final build was placed in C:\Program Files\OpenSSL. Unix and OpenVMS support a "no-shared" config option. I didn't try that for this Windows build, but if it works, I assume everything would be built into the .lib files and no .dll files would be built, which I believe is how the Cryptography developers intended it.

That site has an expired certificate, so IE8 will give you a warning; you have to click "continue to this site (not recommended)" to load the page. Also, it seems to be misidentifying the supported cipher suites. In my case they should all be AES or 3DES; no idea where it's getting "MISTY1." But at least it proves TLS 1.2 is working: "This connection uses TLSv1.2 with AES256-SHA256 ...." It says IE8 doesn't send SNI (Server Name Indication). That may be why the other sites won't load.

@glnz: I think this thread has the best step-by-step instructions for enabling TLS 1.1/1.2: ... although as noted above, my IE8 seems to be broken at the moment

New one today: KB4462226. Seems OK (PowerPoint Viewer 2010 still works, at least).

Good question. My IE8 displays "Internet Explorer cannot display the webpage" (unless I use ProxHTTPSProxyMII, in which case it's showing my ProxHTTPSProxyMII's capabilities, not IE8's). As I recall it used to work without it. Is that what yours is doing too? Edit: howsmyssl.com is doing the same thing.

I think this is even better than the original! With the original Cryptography, we had to wait for the Python developers to release a new Cryptography version, incorporating the latest OpenSSL. With your version, we only need to replace the .dll's in C:\Python34\Lib\site-packages\cryptography\hazmat\bindings. Unfortunately, the copy of MS Visual Studio Express 2010 I used to build OpenSSL is set to expire in 25 days, and M$ no longer provides free registration for VSE 2010 or 2012. For VSE 2008, there was a simple workaround involving deleting a registry key, but it doesn't seem to work for VSE 2010. So I'll probably have to install VSE 2015 (along with Perl and NASM) on the Win 7 side in order to build OpenSSL when 1.1.1c comes out.

Win 10 is a rolling disaster. Win 8 (and, I assume, 8.1) aren't bad as long as you install Classic Shell so you don't have to deal with the "Metro" UI. With Win 8, you can get WMC for the Pro version, and IIRC there's even a Web site where you can get Win 7's "gadgets" back. (Gadgets were removed in 8 for "security;" IOW, M$ didn't want to deal with patching any security holes that might crop up, so they just dropped gadgets in Win 8 entirely. Ironic since Win 7 & its gadgets are supposedly supported for another year.) I think Win 7 Pro is the last version with "XP Mode" (XP in a VM), though. If you have 7 Pro, grab XP mode while you can; it's still the best solution for folks needing XP for older programs and 7+ for newer ones!

Trying to build it now. Despite the fact that I'm building on WinXP, I still had to explicitly tell it to build for WinXP: perl Configure VC-WIN32 -D_WIN32_WINNT=0x0501 Without the -D just about every test failed; apparently the stupid Configure script just assumes Win 7+ rather than grabbing the version it's actually running on . That may explain why so many of the "compatible with XP" builds aren't actually compatible with XP. Edit: Final (apparently XP-compatible) build of OpenSSL v1.1.1b is about 3 MB when written to a .7z archive file. You can download it from my company's Web site.

Despite what they said, the issue isn't TLS 1.2. I suspect if it were, you wouldn't have been able to download the update to start with. (So ironically, you were screwed by being too up-to-date ) (BTW, this is all-too-typical of "support" desks. You mention XP and they just spout the canned response without even looking at anything else.) It's looking for a procedure in Kernel32.dll that doesn't exist in the XP version. It may exist in Dibya's Extended XP, but you'll probably need to use Jumper's Import Patcher to patch the program to point that procedure to Dibya's .dll instead of the system one. That's just off the top of my head; it may turn out to be more trouble to fix than it's worth.

Both of these appear to be free of bcrypt.dll dependencies, proving one can build OpenSSL 1.1.1 that works on Windows XP. The build from the Curl for Windows project also includes the /include and /lib subdirectories; I think these are required because the Cryptography module is a static build; i.e., instead of loading the OpenSSL .dll's when called, the OpenSSL code is included when Cryptography itself is built. (IOW, to build Cryptography we don't need the .dll's; we need the same code in lib format.) However, there is a difference in naming between the Curl for Windows /lib files and the Cryptography project's /lib files. The former have .a extensions while the latter have .lib extensions. I'm guessing this reflects a difference between the MinGW compiler (uses .a) and MSVC (uses .lib). Not sure if the different extensions imply a different format for the lib files. To be safe I suppose it would be best to rebuild OpenSSL 1.1.1b with MSVC. Looks like a complex build though; you'll need: I didn't see a 32-bit version of ActiveState Perl on their website, but there is a 32-bit version of Strawberry Perl and of NASM, so it should be possible to build OpenSSL on a 32-bit system with MSVC. The .LIB files mentioned above are included with VS 2010 (and presumably VS 2015 also). Good luck!

Excellent work! I just looked with Dependency Walker and it seems like your version of libcrypto-1_1.dll does not have a dependency on bcrypt.dll. So I think you're right and it compiled with the legacy code. So far the only thing I've found on building Python's Cryptography module is here: https://cryptography.io/en/latest/installation/#building-cryptography-on-windows. If I read it correctly, one would need your OpenSSL libraries and the OpenSSL include directory, which is part of the source on GitHub. I'm guessing the "2010" and "2015" on that page refer to MSVC versions, and that you used 2010 to compile, so now maybe we can build Cryptography-2.5 or later so it will run on WinXP, at least for Python 3.4.

OK that makes more sense to me now. Thanks for clarifying. BTW, I checked out some OpenSSL binaries on the Web, and every build of version 1.1.1b I found had a dependency on bcrypt.dll - even the ones billed as "XP compatible." So I suspect those are typically built on Win 7, 8.1, or 10, and the builders are unaware they need to override the definition of WIN32_WINNT to 0x0501 when compiling if they want to retain XP compatibility. Builds of 1.0.2 and 1.1.0 were generally OK. But those versions are only supported until later this year. We need to see if someone here (maybe @CoRoNe or @roytam1) can rebuild OpenSSL v1.1.1b correctly for XP.

Are you saying that, if you have Win 7 (and therefore bcrypt.dll), the latest Cryptography modules are compatible with Python 3.4? If so, then why are we even bothering with Python 3.7? Seems we're just making things harder for no benefit. If not, then I don't understand why you said that. Uh, that's source to a module of OpenSSL, not Cryptography. Have you tried to compile OpenSSL on Win XP with, say, MSVC? Seems to me you need to do that first; then rebuild Cryptography, linking to the OpenSSL .dll's you just built.

Well, the critical piece I needed was how to disable signing enforcement. ... which is the first thing I tried, but of course, that one isn't signed. So, I went to AMO, thus requiring the user-agent override to download the signed version.... ... then I ran into the minimum version issue, which I fixed as you described; after which the signature was of course no longer valid, but I thought maybe FF only checked that on download. No such luck; it rechecks add-on signatures on every browser restart, I guess in case malware tries to hijack a common add-on (like uBO). So, I ended up with a different procedure, but the end result is the same: All except step 2 are required in any case; step 2 is only needed to download a signed version from AMO vs. an unsigned version from Github, which may provide a bit more peace of mind for the paranoid (at least you'll know it had a valid signature when you downloaded it). (BTW, even though signatures are no longer enforced, they are still checked, so once the .xpi is modified a warning will appear on the about:addons page, as can be seen in @Sampei.Nihira's screen shot. But since we know why the signature is invalid, we can just ignore the warning.) Also, of course, when uBO 1.18.5 appears (being worked on now), FF will auto-update to it only if the user agent has been overridden, after which you must redo the last three steps above. If the user agent has not been overridden, you'll remain at 1.18.4 until you manually download the (unsigned) update from Github and redo the last three steps. At the end of the day, I guess the point I was passively-aggressively trying to make is: with FF or Serpent, you're stuck at uBO 1.17.4 unless you know how to jump through several non-obvious hoops (FF requiring more hoop-jumping than Serpent).

Remember that PM, and hence NM, were derived from FF, so they are likely to share many of the same bugs (another example being the 23-minute YouTube bug). Also, 32-bit browsers can run out of addressable RAM with many tabs open. If you can't run a 64-bit version, forcing e10s (multiprocess mode) can help with FF or Serpent, but that's not an option with PM or NM.

While I certainly have some differences of opinion with Tobin, MC, and the rest of the PM team, I do want to express my sincere gratitude for their work! In particular, it's nice to have browsers that work with modern Web sites, but that don't employ the "walled garden" strategy of Chrome and Mozilla, requiring every add-on and the like to get a digital signature from the "powers that be." I understand that Chrome & Mozilla are trying to guard against malware, but the potential for abuse of "walled gardens" is clear, especially when Google or Mozilla has different interests than the add-on developer (as we've seen with the recent flap about Chrome threatening to break uBO).

Turns out, it wasn't so much Mozilla as @Sampei.Nihira. I tried my own copy of FF 52.9.1 and, sure enough, I was stuck at 1.17.4. Once again, @VistaLover to the rescue: All of the above applies to FF 52.9.1 also, so one must: Toggle dom.requestIdle.Callback.enabled in about:config to "true" Set a general.useragent.override string to at least rv:55.0; otherwise addons.mozilla.org won't even let you download the latest version Once downloaded; FF 52.9.1 (unlike FF 52.0.2/0.3/9.0) will disable it due to the "strict_min_version" string mentioned above; unfortunately, changing extensions.lastAppVersion in about:config from 52.9.1 to 55.0.0 doesn't help; so to get around this, one must manually edit manifest.json in <profile folder>\Extensions\uBlock0@raymondhill.net.xpi as above However, unlike Basilisk/Serpent, FF also requires add-ons to be signed; doing #3 invalidates the signature, and FF 52.9.1 still won't run it! (That's not quite as ridiculous as Chrome, but it's starting to get pretty close.) There must be a way around that, as seen from @Sampei.Nihira's post showing uBO 1.18.4 running on FF 52.9.1; but no one seems to be talking. I'm starting to feel like I'm chasing the proverbial undomesticated fowl.... (Side note: as I've posted elsewhere, on FF/Serpent I actually prefer to run the legacy version of uBO, since it lets me stop WebRTC's IP address leak; and I don't use FF for day-to-day browsing anyway. So this is purely an intellectual exercise. Still, how ... ?)

I guess our posts crossed in the Ethernet Sorry to have derailed the thread; of course uBO isn't even needed to block Service Workers in FF et al. Even if you use a version (FF 51) where they're enabled by default, you can just toggle support off in about:config and be done with it.

That's interesting @Sampei.Nihira; I was never able to get a version later than 1.17.4 to run on Serpent 52, which is forked from (IIRC) FF 52.6. I never bothered trying on later FF versions; I just figured they'd stop at 1.17.4 too.... (uBO 1.18.4 runs on Serpent 55, but that was forked from an alpha version of FF 53....) So it seems Mozilla did more than mere "security fixes" between 52.6 and 52.9.1.

Thanks @VistaLover; I figured it out on my own eventually and edited my above post accordingly. Just really annoying that Google makes things so much harder.... They keep reminding my why I avoid their browser!

Well, @Sampei.Nihira, given all the trouble I had, I can't say I blame you. But just to be clear, the last working version of uBO on Chrome (1.16.18/1.16.20) is more recent than the last working version on FF 52 (1.16.4.9). Edit: Actually 1.17.4, which is more recent than 1.16.18/20, runs on Serpent 52, so I should've realized it'd run on FF 52 also . 1.16.4.9 is the latest uBO version for PM/NM/Basilisk, though, since those browsers either never supported or no longer support WE's.... You can run the latest version of uBO on Serpent 55 (although the WebRTC option is greyed out).

The state of play, I believe, is: We have ProxHTTPSProxyMII 1.5 working with Cryptography 2.4.2, which runs even under Python 3.4. For now, this works well. But TLS continues to evolve, so to avoid eventual obsolescence we'd like to get ProxHTTPSProxyMII working with newer Cryptography versions. This required a newer version of Python, so we've got Python 3.7.1 working on XP; but more is required as well (at least a user-written version of bcrypt.dll to substitute for the Win 7 module, but apparently even more than that). The problem is, once you move beyond Python 3.4, developers assume you're running on a newer Windows version, so all packages developed for newer Python versions may also use newer Windows functions. It may not be practical to go much further.

Well thanks to @VistaLover's post, I downloaded the signed version of uBO 1.16.18 he uploaded - but Advanced Chrome still won't install it! Says "Apps, extensions, and user scripts cannot be installed from this Web site." Referring, of course, to the file on my own PC. Found the "developer mode" checkbox and tried that; didn't help. Even tried unpacking the .crx file to a directory and loading it with "Load unpacked extension" - but that just got an error that the "_metadata" subdirectory was invalid because its name starts with a reserved "_" character! This is ridiculous. It won't install from anyplace other than the Google Store - but the Google Store only has an incompatible version! Edit: Well, I finally figured it out (sort of); I was able to install uBO 1.16.18 by dragging the .crx file onto the chrome://extensions page. (This works in FF/Serpent/etc. too, but usually in those browsers, I just click on the .xpi file; that doesn't work in Chrome! )

KB2589339: I would've thought M$ could have taken care of the new Japanese era with a single update, rather than dribbling out half a dozen or so