Mathwiz

Well, yes and no; according to this somewhat cumbersome JavaScript test page I found, both FF ESR 52 (select "Show obsolete platforms" to see) and Serpent 52 ("current browser") and probably NM 28 too, support the ECMAScript 2017 standard for JavaScript. But Serpent & NM have a couple of fixes that FF ESR 52 doesn't: a couple of changes in the ECMAScript 2017 standard work on Serpent but not FF ESR 52. The features that differ on that page are very minor and probably unrelated to the Instagram video problem. But given what else I found ... ... I suspect there's another Javascript bug in FF 52.9.1 that was fixed in Serpent 52/NM 28/MyPal, which causes FF 52's Instagram video bug. If so, it probably isn't fixable on FF 52.9.1 without rebuilding FF from source after applying the fixes. (OT, but this probably also explains FF 52.9.1's problems with Github.com mentioned on another thread.)

Should be; I don't know of an easy way to confirm that though. Anyway, I may have been wrong above: it could be a difference in how Javascript works after all. Some of the changes between the NM that doesn't work and the NM that does seem to be related to Javascript.

At present the only known fix for the Instagram issue is to switch to @roytam1's New Moon or Serpent browser. Note that of those, only Serpent supports Adobe's Primetime CDM plug-in.

Github doesn't work in Serpent 52 either unless I override the user-agent to: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.9) Gecko/20100101 Firefox/60.9 If I do that, Github works fine. Can someone try that in FF 52.9.1?

Also works in Serpent 52, so probably not Javascript either. I don't think the PM team made any changes to Javascript since they forked FF ESR 52. (Unfortunately Instagram's pages are just an indecipherable mass/mess of Javascript.) Video appears to just be an ordinary .mp4 file, so you'd think the Primetime module would work. Anyone know the MIME type of these Instagram videos? I suppose one way to debug the problem would be to go back to @roytam1's first build of NM 28. If it doesn't work there, do a sort of "binary search" until we figure out where it starts working again, then see what was changed in that build. Sounds really tedious though. Edit: I've narrowed it down; NM 28 from July 14 shows the same problem as FF ESR 52; NM 28 from July 21 onward works. (Both 7/14 and 7/21 were beta versions of NM 28.) Here's a link to the 7/21 version in @roytam1's blog: one of those changes must have fixed it. https://rtfreesoft.blogspot.com/2018/07/weekly-browser-binaries-20180721.html

Well, I installed VSE 2015 on my home PC last night. Didn't yet get a chance to do anything else, though, because the installation took the whole evening! Man, that is a huge piece of bloatware - even including a Windows 10 SDK (which didn't even install for some reason - just as well - but nevertheless wasted about an hour trying, and I think the install file is still wasting space on my HDD)! Also, with VSE 2015 M$ now makes you create a M$ account in order to get a permanent license key . I'll do that if I have to, but I may give VSE 2013 a try on my work PC, just to see if it's a bit more reasonably sized and/or licensed and still up to the task.

To me, the Win 8 "Metro" UI reminded me way too much of the old Windows 3.1 Program Mangler, except updated with animations. I also didn't care too much for its "tiled" appearance - that reminded me of Windows 2! M$ actually could have gone "back to the future" with an improved PM. Back in the day, Symantec did it with their Norton Desktop, giving Win 3.1 an almost Mac-like appearance. But in this day and age where everyone makes copyright and patent claims on the most trivial grounds imaginable* I suppose M$ didn't want the legal exposure. So they ended up with Metro. Yuck. *AIUI Apple actually sued a company selling a Windows-like UI for PCs called Gem Desktop, because it had a "Trash Can" just like the Mac! Which is why Windows has a "Recycle Bin" instead - or at least, so I've heard.

Well, the Sword of Damocles has been removed from my VSE 2010 installation - I found a valid registration key - but I do have Win 7, so I'll give VSE 2015 a try. If it works, I'll still target XP but the build should work with later Python versions. I'll also add the libcrypto-static and libssl-static .libs to the build archives, so you can build Cryptography either with or without the .dlls.

I wouldn't think an outage would affect one browser but not another on the same PC. Appears it's not the user agent either. @FranceBB, I assumed you tested with NM 28. Was that assumption correct?

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.