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.
Is the Citi site once again problematic? Although I can login, TFF (FPR20b1 or FPR18) isn't displaying account info today. Worked last month around this time. Citi must have changed something on its end.
ReplyDeleteI get a weird server error. It seems to work fine from my Talos II, so I'm guessing it doesn't like something with TenFourFox (changing UA doesn't make any difference). I don't see an obvious error message, though, so I'm not sure why.
Deletemaybe M1243586 related
DeleteIt's probably a good idea to add, but why do you think it's the cause?
Deletenewer pale moon failed to login to citi because they disable it.
DeleteDo you have a link? I want to look at their analysis. I might add this for FPR21 anyway but I'd like to see why they did it.
Deletehttps://forum.palemoon.org/viewtopic.php?p=183557#p183557
Deleteand my analysis:
https://msfn.org/board/topic/180462-my-browser-builds-part-2/page/69/?tab=comments#comment-1178325
because default pref is false, so no related header is sent:
https://github.com/MoonchildProductions/UXP/compare/1d55939c7...f9e1e4639#diff-70a990c1d10c050c5fcc69b226c33c5e
Thanks. I'll review this for FPR21.
Delete