Jump to content

My Browser Builds (Part 4)


Recommended Posts

50 minutes ago, mixit said:

This actually doesn't look like a JS thing but rather a cipher incompatibility, as at least some Mega download servers seem to be for some reason using TLS_RSA_WITH_AES_128_GCM_SHA256 exclusively :blink: and Firefox only enabled it (and TLS_RSA_WITH_AES_256_GCM_SHA384) with bug 1638369  in version 78. Seems trivial for @roytam1 to implement, so probably not a problem for long :) (if this is all there is to it).

The cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 was already implemented in ProxHTTPSProxy 1.5.220717. I tried to connect to Mega using Serpent 55 via ProxHTTPSProxy 1.5.220717, and the download of files didn't work, either. Same issue as without using the proxy. Therefore, I think the problem is presumably not only a cipher incompatibility.

Link to comment
Share on other sites


1 minute ago, AstroSkipper said:

The cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 was already implemented in ProxHTTPSProxy 1.5.220717. I tried to connect to Mega using Serpent 55 via ProxHTTPSProxy 1.5.220717, and the download of files didn't work, either. Same issue as without using the proxy. Therefore, I think the problem is presumably not only a cipher incompatibility.

Ah, that's unfortunate then... I just saw cipher mismatch failures with this (IMHO pretty unusual) single-cipher host and assumed that was the likely main culprit.

Well, even if there's a proxying workaround, I think it'd still be a good idea to enable these ciphers in Serpent itself for compatibility reasons, especially considering how trivial the patch looks.

Link to comment
Share on other sites

33 minutes ago, VistaLover said:

Happy New Year @Jody Thornton :)

This has come up before, not sure if it was just you, but:

Serpent 52.9.0 builds are more up-to-date compared to the official Basilisk build (under a new maintainer now, Basilisk-Dev); last release of Basilisk was on Nov 4th, I sense a new release is imminent...

New Moon 28 builds are more-up-to-date compared to the last official Pale Moon release (v31.4.2), though a new PM release should be imminent (v32.0.0?) ...

appVersion has nothing to do in these cases (and I've explained that in the past, too), it's the actual source code used to build the releases that matters...

 

Great - that helps a lot.  I don't know if I've asked before.  If I did it was years ago.  And reading through so much of this thread is a lot to do when one has other things going on, so I really appreciate the synopsis.

I'm surprise Roytam's build of Serpent 52 beats out Basilisk-Dev's November build in terms of being current - wow!  I know that Nightlizard seems to have stopped his experimental builds around late October, so this is good to know.  I'm using the x86 Serpent on my Dell notebook running Vista Home Basic, so that's a browser I can use alongside myPal 68.

Link to comment
Share on other sites

@AstroSkipper, you wouldn't by any chance have *.mega.co.nz in your [SSL Pass-Thru] section in config.ini, would you? :)

I just downloaded ProxHTTPSProxy 1.5.220717 and it was there in the default .ini file. After removing it, I was able to download from Mega without problems.

Edit: Correction, on another try there were "temporary errors", but they really were temporary this time and the download still completed fine.

Edited by mixit
Link to comment
Share on other sites

1 hour ago, mixit said:

using TLS_RSA_WITH_AES_128_GCM_SHA256 exclusively :blink: and Firefox only enabled it (and TLS_RSA_WITH_AES_256_GCM_SHA384) with bug 1638369  in version 78.

FWIW, both cypher suites are considered "WEAK" by SSL Labs, because they lack "Forward Secrecy":

thToSHI.png

Edited by VistaLover
Link to comment
Share on other sites

6 minutes ago, VistaLover said:

FWIW, both cypher suites are considered "WEAK" by SSL Labs, because they lack "Forward Secrecy":

Well, in cases when there's weak secrecy vs "complete secrecy" in the form of "no connection possible", the former might be handier. :) As with other ciphers, these could be disabled in about:config settings when not needed, couldn't they?

Edited by mixit
Link to comment
Share on other sites

10 minutes ago, mixit said:

@AstroSkipper, you wouldn't by any chance have *.mega.co.nz in your [SSL Pass-Thru] section in config.ini, would you? :)

I just downloaded ProxHTTPSProxy 1.5.220717 and it was there in the default .ini file. After removing it, I was able to download from Mega without problems.

You are absolutely right. This entry was pre-configured, and I forgot to remove it. I thought my config file was clean. I do have a lot of these config files. Anyway! Good find! After removing it works indeed. So, the problem is really cipher related.

Link to comment
Share on other sites

1 hour ago, AstroSkipper said:

The cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 was already implemented in ProxHTTPSProxy 1.5.220717.

Actually, that suite (0x9c) is natively supported by Serpent 52.9.0 and it's controlled by pref:

security.ssl3.rsa_aes_128_gcm_sha256

This is set to "false" by default, because, as posted, the suite is "WEAK"; enabling it and restarting the browser:

tlsGmcT.png

made MEGA downloads initialise and complete successfully! :cheerleader:

vFEQeig.png

Many thanks @mixit :worship:

Edited by VistaLover
The culprit cypher suite is disabled by default
Link to comment
Share on other sites

1 minute ago, VistaLover said:

Actually, that suite (0x9c) is natively supported by Serpent 52.9.0 and it's controlled by pref:

security.ssl3.rsa_aes_128_gcm_sha256

I had it set to "false", because, as posted, that suite is "WEAK"; enabling it and restarting the browser:

made MEGA downloads initialise and complete successfully! :cheerleader:

Many thanks @mixit :worship:

Glad to be of service. :)  I should have checked if this was already included before tagging @roytam1 ... In my feeble defense, I don't actually use Serpent - I'm still on self-built pre-drama Centaury (in combination with 360 and occasional VM browsing with the officially "in" browsers) but it turns out it actually has it too, disabled by default. :whistle::lol:

At least it's nice to occasionally have a browser problem we can solve on our own without endlessly waiting for "upstream". :)  I have to say, I almost missed the SSL problem because we've been totally conditioned to always look at the JS console as of late :crazy:

I wonder what's up with Mega and this single-cipher thing, though...

Link to comment
Share on other sites

4 hours ago, mixit said:

This actually doesn't look like a JS thing but rather a cipher incompatibility, as at least some Mega download servers seem to be for some reason using TLS_RSA_WITH_AES_128_GCM_SHA256 exclusively :blink: and Firefox only enabled it (and TLS_RSA_WITH_AES_256_GCM_SHA384) with bug 1638369  in version 78. Seems trivial for @roytam1 to implement, so probably not a problem for long :) (if this is all there is to it).

Try setting pref security.ssl3.rsa_aes_128_gcm_sha256 to true. Ciphers are part of NSS, which @roytam1 keeps pretty up-to-date in his Serpent/NM builds, but this pref defaults to false for some reason. I'm not sure why; it doesn't use the less secure SHA1 hash; it doesn't use CBC, which proved problematic; and it doesn't use a weak cipher.

Edit: I think I know why it's considered "weak" by SSLLabs: it's not that it's inherently weak; it's that it doesn't provide "forward secrecy." If a determined attacker recorded all your encrypted conversations with mega.nz, and at some point in the future, mega.nz's private key were compromised, the attacker could retroactively decrypt everything you'd sent to or received from them. (Of course the other cipher suffers from the same "weakness," but it's pref defaults to true; go figure.)

I like SSLLabs, but I wish they were a bit clearer about what the problem is when they say a cipher is "weak." (Of course, there's only so much room on the results page, so I guess they can be excused for not being as verbose as I'd prefer.)

Ignore that the pref contains "ssl3;" I'm pretty sure this cipher suite is only used by TLS 1.2.

Edited by Mathwiz
Link to comment
Share on other sites

5 hours ago, XPerceniol said:

Thank you for the recommendation and I'm willing to learn ... sometimes willing but not always able.

These "Cap" programs are "wrappers" used with programs that don't normally have a provision to use a proxy server. That was my situation; I had a program (OE Classic) that I needed to use a proxy server (just once, to activate the "Pro" license I'd bought) but OE Classic provided no way to do that. (Probably no one ever needed it before me.)

As for the "best" of these "Cap" programs, I'll take @AstroSkipper's recommendation of SocksCap64 to heart (despite the name, it does have a 32-bit version). FreeCap had one job: let me activate OE Classic. It did that job, but I'm not wedded to it!

Link to comment
Share on other sites

12 hours ago, VistaLover said:

Happy New Year @Jody Thornton :)

This has come up before, not sure if it was just you, but:

Latest Serpent 52.9.0 build is more up-to-date compared to the official Basilisk build (under a new maintainer now, Basilisk-Dev); last release of Basilisk was on Nov 4th 2022, I sense a new release is imminent...

Latest New Moon 28 build is more-up-to-date compared to the last official Pale Moon release (v31.4.2), though a new PM release should be imminent (v32.0.0?) ...

appVersion has nothing to do in these cases (and I've explained that in the past, too), it's the actual source code used to build the releases that matters...

Roytam1 cherry-picks all feature enhancements from the upstream platform (UXP by MCP) and upstream applications (PM by MCP and Basilisk by Basilisk-Dev) and merges them into his UXP fork - security patches come via the MCP and/or Mozilla repos...

A few upstream features/commits are not being adopted, because they are incompatible with the OSes roytam1 targets; others (like the JPEG-X decoder) are not compatible with the compiler (MS VS2015) currently employed to build his releases...

As for Serpent 55.0.0(/moebius), there's nothing "upstream" now to compare it to, is there? Roytam1 just tries to keep that "close" to his UXP offerings...

@XPerceniol : Please, just stop examining "file versions"; these mean nothing... A certain exe's/dll's "file version" only changes when a full re-compilation takes place from scratch (what's called "clobber"); this is time and energy consuming and it's to be avoided in weekly releases... Only those few files that get changed and rebuilt come with "newer" file versions...

The latest St55 (32-bit) build is "basilisk55-win32-git-20221231-7637d8917-xpmod.7z"; update to it, if you haven't already; its buildID should be 20221230020814 (Help -> Troubleshooting Information -> Build ID) ...

To ALL: Source code repos for Roytam1's browsers are public and accessible on GitHub (links in the "weekly releases" posts); it's all "transparent" there, if you take a minute or two to read committed code and compare it to the upstream repos... That's what I do...
Disclaimer: I'm not a coder myself... :P

thanks for your input, added to FAQ in page 1.

Link to comment
Share on other sites

13 hours ago, VistaLover said:

@XPerceniol : Please, just stop examining "file versions"; these mean nothing... A certain exe's/dll's "file version" only changes when a full re-compilation takes place from scratch (what's called "clobber"); this is time and energy consuming and it's to be avoided in weekly releases... Only those few files that get changed and rebuilt come with "newer" file versions...

The latest St55 (32-bit) build is "basilisk55-win32-git-20221231-7637d8917-xpmod.7z"; update to it, if you haven't already; its buildID should be 20221230020814 (Help -> Troubleshooting Information -> Build ID) ...

Understood ... appreciate the detailed reminder and explanation.

Be well.

Link to comment
Share on other sites

12 hours ago, VistaLover said:

Actually, that suite (0x9c) is natively supported by Serpent 52.9.0 and it's controlled by pref:

security.ssl3.rsa_aes_128_gcm_sha256

This is set to "false" by default, because, as posted, the suite is "WEAK"; enabling it and restarting the browser:

tlsGmcT.png

made MEGA downloads initialise and complete successfully! :cheerleader:

vFEQeig.png

Many thanks @mixit :worship:

Same in New Moon 28. After setting security.ssl3.rsa_aes_128_gcm_sha256 to true, MEGA downloads are working again. :thumbup

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...