TenFourFox FPR21b1 available

TenFourFox Feature Parity Release 21 beta 1 is now available (downloads, hashes, release notes). I decided against adding the AltiVec GCM accelerator for this release, since it needs some extra TLC to convert from VSX to VMX, and I'd like to test the other major changes independently without introducing a bigger bug exposure surface than necessary. As promised, however, this release does have support for higher-speed 0RTT TLS 1.3 with HTTP/2 (particularly useful on Google properties) and has additional performance adjustments to improve parallelism of TLS connections to HTTP/1.x sites (mostly everybody else). I also updated Reader mode to the most current version used in Firefox 74, incorporating several important fixes; for a slow or complex site that you don't need all the frills for, try turning on Reader mode by clicking the "book" icon in the URL bar. You can do it even while the page is loading (reload after if not all of it comes up). FPR21 will go live with Firefox 68.7/75 on April 7.

TenFourFox FPR20 available

TenFourFox Feature Parity Release 20 final is now available for testing (downloads, hashes, release notes). This version is the same as the beta except for one more tweak to fix the preferences for those who prefer to suppress Reader mode. Assuming no issues, it will go live Monday evening Pacific as usual.

I have some ideas for FPR21, including further updates to Reader mode, AltiVec acceleration for GCM (improving TLS throughput) and backporting later improvements to 0RTT, but because of a higher than usual workload it is possible development may be stalled and the next release will simply be an SPR. More on that once I get a better idea of the timeframes necessary.

TenFourFox FPR20b1 available

TenFourFox Feature Parity Release 20 beta 1 is now available (downloads, hashes, release notes). Now here's an acid test: I watched the entire Democratic presidential debate live-streamed on the G5 with TenFourFox FPR20b1 and the MP4 Enabler, and my G5 did not burst into flames either from my code or their rhetoric. (*Note: Any politician of any party can set your G5 on fire. It's what they do.)

When using FPR20 you should notice ... absolutely nothing. Sites should just appear as they do; the only way you'd know anything changed in this version is if you pressed Command-I and looked at the Security tab to see that you're connected over TLS 1.3, the latest TLS security standard. In fact, the entirety of the debate was streamed over it, and to the best of my knowledge TenFourFox is the only browser that implements TLS 1.3 on Power Macs running Mac OS X. On regular Firefox your clue would be seeing occasional status messages about handshakes, but I've even disabled that for TenFourFox to avoid wholesale invalidating our langpacks which entirely lack those strings. Other than a couple trivial DOM updates I wrote up because they were easy, as before there are essentially no other changes other than the TLS enablement in this FPR to limit the regression range. If you find a site that does not work, verify first it does work in FPR19 or FPR18, because sites change more than we do, and see if setting security.tls.version.max to 3 (instead of 4) fixes it. You may need to restart the browser to make sure. If this does seem to reliably fix the problem, report it in the comments. A good test site is Google or Mozilla itself. The code we are using is largely the same as current Firefox's.

I have also chosen to enable Zero Round Trip Time (0-RTT) to get further speed. The idea with 0RTT is that the browser, having connected to a particular server before and knowing all the details, will not wait for a handshake and immediately starts sending encrypted data using a previous key modified in a predictable fashion. This saves a handshake and is faster to establish the connection. If many connections or requests are made, the potential savings could be considerable, such as to a site like Google where many connections may be made in a short period of time. 0RTT only happens if both the client and server allow it and there are a couple technical limitations in our implementation that restrict it further (I'm planning to address these assuming the base implementation sticks).

0RTT comes with a couple caveats which earlier made it controversial, and some browsers have chosen to unconditionally disable it in response. A minor one is a theoretical risk to forward secrecy, which would require a malicious server caching keys (but a malicious server could do other more useful things to compromise you) or an attack on TenFourFox to leak those keys. Currently neither is a realistic threat at present, but the potential exists. A slightly less minor concern is that users requiring anonymity may be identified by 0RTT pre-shared keys being reused, even if they change VPNs or exit nodes. However, the biggest is that, if handled improperly, it may facilitate a replay attack where encrypted data could be replayed to trigger a particular action on the server (such as sending Mallory a billion dollars twice). Firefox/TenFourFox avoid this problem by never using 0RTT when a non-idempotent action is taken (i.e., any HTTP method that semantically changes state on the server, as opposed to something that merely fetches data), even if the server allows it. Furthermore, if the server doesn't allow it, then 0RTT is not used (and if the server inappropriately allows it, consider that their lack of security awareness means they're probably leaking your data in other, more concerning ways too).

All that said, even considering these deficiencies, TLS 1.3 with 0-RTT is still more secure than TLS 1.2, and the performance benefits are advantageous. Thus, the default in current Firefox is to enable it, and I think this is the right call for TenFourFox as well. If you disagree, set security.tls.enable_0rtt_data to false.

FPR20 goes live on or about March 10.

TenFourFox FPR19 available

Due to a busy work schedule and $REALLIFE, TenFourFox Feature Parity Release 19 final is just now available for testing (downloads, hashes, release notes). This version is the same as the beta except for a couple URL bar tweaks I meant to land and the outstanding security updates. If all goes well, it will go live tomorrow Pacific time in the evening.

Since the new NSS is sticking nicely, FPR20 will probably be an attempt at enabling TLS 1.3, and just in time, too.

TenFourFox FPR19b1 available

TenFourFox Feature Parity Release 19 beta 1 is now available (downloads, hashes, release notes). I was originally going to do more iteration on Reader mode in FPR19, but in a possible recurrence of the issue that broke SourceForge downloads temporarily, a user reported on Tenderapp they had a site that was failing in the same way.

On the test system I was able to reproduce the problem and it was due to the selected cipher having insufficient cryptographic strength to pass HTTP/2 TLS profile validation. The selected cipher was one I added as a stopgap for FPR7 to fix another site which was still working (and did not use HTTP/2, hence it didn't exhibit the issue). Disabling that cipher restored the new failing site, but caused the site I put the workaround for in FPR7 to fail, so in no situation could I get both sites to be happy with the set available. Although I didn't really want to do this, the only real solution here was to upgrade NSS, the underlying cryptographic library, to add additional more modern ciphers to replace the older one that now needed to be reverted. With this in place and some other fixes, now both sites work, and this probably fixes others.

The reason I was reticent to update NSS (and the underlying NSPR library) was because of some custom changes and because I was worried changes in cipher coverage would break compatibility. However, there wasn't a lot of choice here, so I manually patched up our custom AltiVec-accelerated NSPR to a current release and spliced in a newer NSS overlaid with our build system changes. I tested this on a few sites I knew to be using old crypto libraries and they still seemed to connect fine, and as a nice side benefit some of the more modern ciphers are more efficient and therefore improve throughput a bit. It also makes the likelihood of successfully updating TenFourFox to support TLS 1.3 much higher; if this sticks, I may attempt this as soon as FPR20.

There are a couple sundry minor changes to be implemented at final release, mostly minor bug fixes, but I want to get this beta in testing as quickly as possible within the shrinking rapid release timeframe. I have otherwise intentionally limited the scope of FPR19 to mostly just the crypto upgrade so that we have a clear regression range. If you notice sites have stopped being accessible in FPR19, please verify they are working in FPR18 (people say "I remember it worked," but sites change more than TenFourFox does, so please check and save us some time here), and if it does indeed work in FPR18 report it in the comments so I can analyse the problem. I am very unlikely to revert this change given that it's necessary going forward and probably the best of the available options, but if I can add exceptions that don't compromise overall security I'm willing to do so in the name of supporting backwards compatibility with sites the browser used to be able to access. FPR19 goes final parallel with Firefox 73 and 68.5 somewhere around February 11.

TenFourFox not vulnerable to CVE-2019-17026

After doing some analysis late last night and today to determine if we need a chemspill build, I have concluded that TenFourFox is not vulnerable to CVE-2019-17026, or at least not to any of the PoCs or test cases available to me. This is the 0-day that was fixed in Firefox 72.0.1 and 68.4.1. Though a portion of the affected code exists in the TenFourFox code base, there doesn't seem to be a way to trigger the exploit due to various other missing optimizations and the oddities of our JIT. (Firefox 45-based browsers using our patches as upstream should bear in mind this may not be true for other architectures, however.) Absent evidence to the contrary it will be nevertheless patched as part of the standard security fixes in FPR19.

The new Overbite Android (works with Firefox Android too): Gopherspace on your mobile Android device

Since this blog is syndicated to Planet Mozilla and I periodically post Mozilla- and Firefox-relevant posts, here is another: if you still dwell in Gopherspace and use OverbiteWX and OverbiteNX on desktop Firefox, Overbite Android has been updated to full Android Q compatibility so you can use it with Android Firefox as well. Instead of an add-on, just sideload the .apk, and whenever you tap a Gopher URL in Firefox it will automatically load in Overbite Android so you can seamlessly jump back and forth. (Or Chrome, I guess, but who uses that?)

Naturally Overbite Android works just fine as a standalone application and responds to any gopher:// intent sent by any other activity, including Firefox. However, this latest version has been updated specially for Android Q support, including dark theme:

I also purged a lot of the old API usage, replacing it with a more Material Design-style UI, an actual address bar you can edit for a change, and a dynamic menu off a floating action button (as opposed to the old school Menu button menu, support for which was removed from Android Q). There are also fixes to scrolling and zooming, and you can still generate and drop shortcuts on your Android launcher as bookmarks.

Now that I've gotten off my butt and converted it to Android Studio, I suppose I should start working on download support again but everything else (including searches) functions just dandy.

Overbite Android is offered to you under the BSD license and supports 4.0 (Ice Cream Sandwich) through 10 (Q). You can get it, the Android Studio project and source code, and all the rest of the Overbite gopher client family from the Overbite website or directly from Gopherspace.