User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

Try to search via https://www.google.com OR just from the address bar in Firefox.

This bug happens many times per day. Sometimes restarting the browser and maybe passing of time helps.

Usually error is more often if user has logged in with Google account in this particular browser.

Error has occurred 3-4 months roughly. Subsequent Firefox updates have not given any relief for the issue.

Actual results:

Got error page:

Secure Connection Failed

An error occurred during a connection to www.google.com. SSL peer was not expecting a handshake message it received.

Error code: SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

Expected results:

Can access Google Search.

The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Please enter about:support into the address bar. On that page, click the Copy text to clipboard button. Then paste into Notepad and click the Attach New File button on this page to upload it.

For reference, this error is only generated for one condition: the server sends us an unexpected_message alert.

https://searchfox.org/nss/rev/32df2b5e1ee3119d7938cd3c5e769dec498cbd95/lib/ssl/ssl3con.c#3042-3043

The usual diagnosis we do here is ask people about network interception devices or anti-virus software. Anything that might be intercepting TLS connections. Checking the value of the security.enterprise_roots.enabled is a good place to start; if it is false, that indicates potential interception and helps us confirm that Google servers are not at fault (which is possible, but quite unlikely).

I have also encountered this same problem recently when trying to access Google services on Firefox 97.0, on a laptop running Ubuntu 20.04 LTS.

User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

The error message I received was the same as the one Joanna received, and I also get it when trying to access www.google.com or searching on the address bar (for which Google is set as the default search engine.) Additionally, I encounter the same error when trying to access ANY Google service (including Gmail, Drive, Docs and others.)

For me, the error only occurs when I am connected to my school wifi and has never happened when I am at home. I am aware that my school wifi uses Protected EAP and EAP-MSCHAV.

The error is intermittent and does not always happen. When it does happen, it persists for 15-30 minutes and then I am able to connect again. During this time, all non Google-related websites work fine on Firefox, and Google Chrome is able to access Google-related websites without issues.

I have Ublock Origin installed on both browsers, and all settings are the same across both browsers except for Firefox-exclusive features. I tried disabling Ublock Origin and Google services still did not load.

An image of the error message which I received.

This is the troubleshooting info I got from about:support on Firefox on Ubuntu 20.04 LTS. I wasn't asked for this but you asked Joanna for this and I figured I would add mine too since I have the same error.

Thanks for the information. As this seems to be limited to the one network, that's a pretty clear signal that there is a middlebox interfering with connections. We see similar things from anti-virus software sometimes as well, but different behaviour on different networks points to a middlebox. My guess is that there some "security" middlebox somewhere in your school network that can't handle something we're doing in TLS.

Your about:support info shows that security.enterprise_roots.enabled is false, which means that the middlebox isn't able to intercept connections, but it seems to be messing about regardless. If you do end up talking to a network administrator and they are willing to contact us with details of the product they are using, that would be very helpful. Usually we try to contact vendors of these devices. I'm not going to hold my breath though, it's rare that someone will want to talk about this sort of thing.

I'm going to hazard another guess that this is another case where early data is causing the middlebox to mess with something. We know that some middleboxes damage TLS connections they shouldn't. Given the timing of these errors and the pattern of failures, I'm guessing that this is related to our use of 0-RTT and setting security.tls.enable_0rtt_data to false will fix the problem.

What we might do to work around this problem is enable an automatic retry if a connection fails with this error code. Adding SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT to the list of intolerance reasons and disabling 0-RTT on retry might smooth over the worst of these problems.

Dennis, as you are looking at fallback logic for other reasons, is this something you can look into? (The fixes would then live in PSM, not NSS.)

This patch adds a retry reason for SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT, similar to Bug 1718520 and Bug 1732424. I've tried to clean up the logic and align the telemetry as well.

We don't have a good way to test the handling of these errors in CI (See Bug 1754746) so I've verified that the fallback works against a tweaked version of NSS selfserv running locally.

The severity field is not set for this bug.
:beurdouche, could you have a look please?

For more information, please visit auto_nag documentation.

Maybe this is relevant?

https://bugzilla.mozilla.org/show_bug.cgi?id=1717644
"...Firefox 89 won't load Google, won't search Google in the address bar, won't load any google related website or load google font into any website..."

Dennis, should we be moving forward with the patch in this bug?

The patch is written and manually tested. Dragana wants to wait on the automated tests from 1754746 though.

Is this bug in the right component? The patch changes files in mozilla-central not NSS. Maybe Core: Networking would be better.

Bug 1768250 might also help with this.

Coming from bug 1718520, I still have the issue in 102.4.0(ESR) failing on some sites after some time with SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT and SSL_ERROR_RX_RECORD_TOO_LONG. Sometimes google.de is affected, sometimes also google.com or https://powerline.readthedocs.io . A restart solves it for a while, then the issue returns. I have disabled all my addons. I can't reproduce with an empty profile.

I was able to solve all these issues now with security.tls.enable_0rtt_data false.
Other browsers don't have that issue and return valid certificates. There is no intercepting proxy.

Dennis - what's the status on this bug? I see there's a WIP patch dependent on it. Does this just need review? Was it mooted by any other work? Thanks

It looks like the testing Dragana mentioned is bug 1754746, which bounced landing 3 days ago. Once that lands, I'm guessing we can land this bug (with review)

There's a r+ patch which hasn't landed, is there still more work that's needed for the patch?