Closed Bug 1718520 Opened 3 years ago Closed 3 years ago

SSL_ERROR_PROTOCOL_VERSION_ALERT error

Categories

(Core :: Networking: HTTP, defect, P1)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox94 --- fixed

People

(Reporter: manuforcen, Assigned: dragana, NeedInfo)

References

Details

Attachments

(3 files)

Captura de pantalla de 2021-06-28 12-59-24.png
72.54 KB, image/png
Details
Disable early-data if a SSL_ERROR_PROTOCOL_VERSION_ALERT is received
48 bytes, text/x-phabricator-request
Details | Review
Retry a HttpTransaction if early data are used and a SSL_ERROR_PROTOCOL_VERSION_ALERT is received
48 bytes, text/x-phabricator-request
Details | Review

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

Steps to reproduce:

I was developing some webapp in localhost with SSL enabled. After some refreshes, some elements of webpages stop reloading.
After stop loading localhost, this behaviour extends to other webpages, like google or some CDNs.
Sometimes refreshing webpages makes this error appear in devtools.
This only happens in Ubuntu 20.04 with Firefox. In Windows or using other web browsers everything works perfectly.

Actual results:

Webpages or components don't load properly. DevTools show SSL_ERROR_PROTOCOL_VERSION_ALERT.

Expected results:

Network requests should work.

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.

Component: Untriaged → Security: PSM
Product: Firefox → Core

I use DuckDuckGo with shebangs. Now when I search in Google using !g command of duckduckgo, SSL_ERROR_PROTOCOL_VERSION_ALERT shows in devtools and I cannot load google anymore.

GDB raises an exception when the connection can not be made:

Thread 8 "Socket Thread" received signal SIGPIPE, Broken pipe.
[Cambiando a Thread 0x7fffe65da700 (LWP 1812049)]
__libc_send (flags=<optimized out>, len=24, buf=0x7fffa40e8000, fd=56) at ../sysdeps/unix/sysv/linux/send.c:28
28 ../sysdeps/unix/sysv/linux/send.c: No existe el archivo o el directorio.

I also attach the complete backtrace:
#0 __libc_send (flags=<optimized out>, len=24, buf=0x7fffa8cbb000, fd=127) at ../sysdeps/unix/sysv/linux/send.c:28
#1 __libc_send (fd=127, buf=0x7fffa8cbb000, len=24, flags=0) at ../sysdeps/unix/sysv/linux/send.c:23
#2 0x00007ffff6fec5fe in () at /usr/lib/firefox/libnspr4.so
#3 0x00007fffed5087ad in () at /usr/lib/firefox/libxul.so
#4 0x00007ffff6d55f78 in () at /usr/lib/firefox/libssl3.so
#5 0x00007ffff6d3f3d3 in () at /usr/lib/firefox/libssl3.so
#6 0x00007ffff6d3d560 in () at /usr/lib/firefox/libssl3.so
#7 0x00007ffff6d5acdc in () at /usr/lib/firefox/libssl3.so
#8 0x00007ffff0a1297b in () at /usr/lib/firefox/libxul.so
#9 0x00007fffed56313b in () at /usr/lib/firefox/libxul.so
#10 0x00007fffed566a66 in () at /usr/lib/firefox/libxul.so
#11 0x00007fffed56c50c in () at /usr/lib/firefox/libxul.so
#12 0x00007fffed56ee6b in () at /usr/lib/firefox/libxul.so
#13 0x00007fffed56e44d in () at /usr/lib/firefox/libxul.so
#14 0x00007fffed56f1ba in () at /usr/lib/firefox/libxul.so
#15 0x00007fffed45ff2e in () at /usr/lib/firefox/libxul.so
#16 0x00007fffed463526 in () at /usr/lib/firefox/libxul.so
#17 0x00007fffed9d7668 in () at /usr/lib/firefox/libxul.so
#18 0x00007fffed997388 in () at /usr/lib/firefox/libxul.so
#19 0x00007fffed45e1a9 in () at /usr/lib/firefox/libxul.so
#20 0x00007ffff6fedc89 in () at /usr/lib/firefox/libnspr4.so
#21 0x00007ffff7f87609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#22 0x00007ffff7b5c293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

What are the values of security.tls.version.max and security.tls.version.min in about:config?

Flags: needinfo?(manuforcen)

Hello All
I have been directed towards this issue since i experience it as well

Having Major connectivity issues to all Google services
SSL_ERROR_PROTOCOL_VERSION_ALERT

its limited to the office network and it seems a fellow colleague has it on the stable version as well.
I've tried a new profile and the same issue happens

Once i restart the browser, I'm able to access all the services again but as I keep the tabs in background and come back to it later nothing works.
Google also wont load a search term.
It stays stuck on the new tab page after hitting enter

Very weird and hard to reproduce issue
NS_BINDING_ABORTED also comes in at times

Latest Nightly 91.0a1 (2021-07-06) (64-bit), ubuntu 18.04
All settings are default

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #5)

What are the values of security.tls.version.max and security.tls.version.min in about:config?

My configurations are kept in default values (3 for min, 4 for max), but I tried to modify the values without a success.

Flags: needinfo?(manuforcen)

Did you try setting security.tls.version.max to 3 and leaving everything else as default?

Does this happen if you make a new profile?

Are you behind some sort of proxy or are you directly connecting to google, etc.?

Flags: needinfo?(manuforcen)

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #8)

Tested on my :keeler

Did you try setting security.tls.version.max to 3 and leaving everything else as default?

Yes now the browser is able to load pages. Changed when the browser is running.

Does this happen if you make a new profile?

Yes it does

Are you behind some sort of proxy or are you directly connecting to google, etc.?

Behind Office internet. Chromium works fine under the same network.

Assignee: nobody → nobody
Component: Security: PSM → Libraries
Product: Core → NSS
Version: Firefox 89 → other

Could you please restore security.tls.version.max to 4, ensure that you still see this issue and see if setting security.tls.enable_0rtt_data to false changes anything. We have a suspicion that something might be related to Google recently enabling 0-rtt... Thanks!

Flags: needinfo?(bbeurdouche)
Severity: -- → S2
Flags: needinfo?(bbeurdouche)
Priority: -- → P2

If you can, having a wireshark capture of the traffic would be pretty useful... : ) Thank you!

(In reply to Benjamin Beurdouche [:beurdouche] from comment #10)

Could you please restore security.tls.version.max to 4, ensure that you still see this issue and see if setting security.tls.enable_0rtt_data to false changes anything. We have a suspicion that something might be related to Google recently enabling 0-rtt... Thanks!

Hello :beurdouche

Tried steps suggested
Set 'security.tls.version.max' to '4', restart browser and after 5 -10 mins of usage the issue reappeared. Google doesn't load
Set 'security.tls.enable_0rtt_data' to 'false' immediately after issue occurred and i was able to continue browsing normally without restarting the browser

WireShark traffic - do you know or have specific steps? I could maybe help. New User level.

See Also: → 1719312

If I may: I have the same issue and did a lot of digging on my own.

Randomly, I can't access any google website on firefox. when it's the case, the navigator console shows: SSL_ERROR_PROTOCOL_VERSION_ALERT
This also happens on thunderbird, which I think might help to find the culprit. Disabbling Ad-Block and ghosteries did not change anything and the bug still appeared.

While I can't access google on firefox, chrome worked fine. If I close firefox and re-open it right away, I can display google without problems.

When the problem occurs, I use an Ethernet cable, at work, but at home, using the same navigator and computer, I never have such a problem.

I use Ubuntu 20.04 and Firefox 90.0. The exact version is: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

I also think this bug is a duplicate of this one: https://bugzilla.mozilla.org/show_bug.cgi?id=1717644 but I couldn't find this information here, so my bad if this was already flagged somewhere.

FWIW, I've attached a Wireshark pcap for when this happens on the other bug page - https://bugzilla.mozilla.org/show_bug.cgi?id=1717644

autiwa, thanks for the extra info. The fact that you have a problem at work is good information. If your employer has some sort of network security device that intercepts TLS or attempts to do something with TLS, then that could be causing problems. In talking to our colleagues at Google, the only thing that is likely to cause this particular error is something that modifies the TLS record version. According to the pcap file (thanks blueblue), we can confirm that whatever Firefox is doing is OK. But Google's servers are receiving something else and objecting to that. We don't know why Chrome doesn't have this problem, but there are small differences in their TLS implementation and ours that an interception device might be using to do something different.

autiwa, do you know if your employer has some sort of TLS interception enabled? If so, knowing more about what device is used, who it was bought from, what version it runs and that sort of thing would be help. If there is something that is intercepting TLS, we'd love to talk to the people who made it. One way that might give you a clue is security.enterprise_roots.enabled in about:config. If it is set to "true", then interception might be involved.

Flags: needinfo?(autiwa)

Though I couldn't get any info about their security settings, I'll ask them. I'm not sure they are ready to disclose what they're doing with security but your message is interesting, because to me it make sense and I can believe they're doing just that, explaining why there's this bug. It would be good to have a confirmation for other people that have this bug. However, what's weird is that none of my colleagues have this issue on their computer, in the same network. But at least some of them are not using google for their researchs, and I suspect most of them are not using Ubuntu.

I'll see what I can do and get back to you if I get anything interesting.

Flags: needinfo?(autiwa)

It seems I can't edit my own post. Sorry about double messages. One addition:
security.enterprise_roots.enabled is set to True in about:config.

Thanks, even without the details, knowing that interception is likely a factor here is worth knowing. I can't know what is causing your configuration (Ubuntu, Firefox, etc...) to be singled out without more information about the interception practices - that people insist on keeping details of their interception practices secret is frustrating and probably doesn't improve security - but at least we have more information to support our basic theory.

Hello :mt

For what its worth my organization uses FortiGuard Web Filtering by Fortinet
This seems to affect the stable build as well.

OS is ubuntu. As usual chromium somehow works in the environment here.

Thanks bull500, we'll see if there is someone we can contact about that.

I'm also having the same issues as the others in this thread (issues only when using the company network, likely TLS interception, company uses Fortinet), and as the others said, changing the TLS settings in about:config (e.g., I tried lowering the tls min version to 1 or 2; my max version is already 4) re-enables Google websites to work for a few minutes (likely due to resetting the connection), but then they stop working again after some amount of time.

I'd just like to add a few pieces of information:

  • After letting a tab with Gmail open and the Network tab of Web Developer Tools option, I once got an error NS_ERROR_INTERCEPTION_FAILED, instead of the SSL_ERROR_PROTOCOL_VERSION_ALERT. But when trying to reproduce it, I sometimes get the protocol version error instead.

  • Changing the security.tls.enable_0rtt_data to false might have helped; I spent over 1 hour without connection issues. I'm resetting it to the default value for now, to make more tests.

  • A colleague mentioned having issues with dl.acm.org, a non-Google domain. I couldn't reproduce it yet, but I'm mentioning it in case it may provide a useful data point.

Can something be done about it, Its massively affecting normal stable build users.
There is no guide in the public domain until you come and hit this bugzilla report. I've been able to support the few people i know but its not a scalable solution
Most people will simply switch thinking Firefox isnt working reliably.

security.tls.enable_0rtt_data is the only setting that work to mitigate the issue

Is it possible to copy what chromium does handle this issue? It should probably help for what its worth

Priority: P2 → P1

If amount of origins that have early-data disabled exceeds certain amount, disable early-data for all origins

This is controlled by prefs.

I don't have a lot to add to the detailed reports others have shared here, but just in case it's useful in diagnosing the problem or formulating a solution I thought I'd share a workaround that has proven 100% reliable for me thus far. Whenever Google sites (or occasionally Facebook) stop working in this way for me, I open a private browsing window, do some random Google search from the search bar (which thus far has always succeeded), and close the private browsing window. After that my main window is able to access Google normally again. (It may require reloading tabs sometimes, but I think my Google Calendar tab has sometimes reconnected on its own.) My apologies if this is just duplicate information; I only vaguely understand the underlying issue.

I don't know what network security systems my work may have in place, and I've usually seen this from my work network, but I'm pretty sure it's happened from home at least once. I've wondered if it could be related to them forcing me to run Sophos Antivirus, or any of their other remote management stuff. [I'm running Firefox 96.0 on macOS 11.6.]

I finally found out that I am not the only one out there with this problem. I experience the same blank page and the following message "SSL_ERROR_PROTOCOL_VERSION_ALERT" inside the developer tools after a few minutes trying to Search on Google with Firefox, Chrome works fine.

Also I can confirm that this only happens when being connected to my school network. At home everythings works just fine.

Do you need any other insights I could perform and share with you to gather as much information as possible about this problem?

Just so that there is the information in a single place:

Setting security.tls.enable_0rtt_data to false will fix this issue. No other changes are needed.

The vendor of the broken intermediary is aware of the issue and has acknowledged the fault. They should - in due course - fix the issue. After that, the fix will need to be deployed. We don't know how long that whole process will take. Until then, we're working on an automatic fallback.

Pushed by ddamjanovic@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1dab1bcd93ef
Disable early-data if a SSL_ERROR_PROTOCOL_VERSION_ALERT is received r=mt

https://hg.mozilla.org/mozilla-central/rev/1dab1bcd93ef

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
status-firefox94: --- → fixed
Resolution: --- → FIXED
Assignee: nobody → dd.mozilla
Pushed by ddamjanovic@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/01096cd29f4b
Retry a HttpTransaction if early data are used and a SSL_ERROR_PROTOCOL_VERSION_ALERT is received r=necko-reviewers,kershaw

Can you change the bug component to Core :: Networking: HTTP since the fix wasn't in NSS.

Flags: needinfo?(dd.mozilla)
Component: Libraries → Networking: HTTP
Flags: needinfo?(dd.mozilla)
Product: NSS → Core
Version: other → unspecified

Dragana, bug 1732424 suggests that we might need to include SSL_ERROR_BAD_MAC_ALERT as a reason to disable early data. What do you think?

Flags: needinfo?(dd.mozilla)

(In reply to Martin Thomson [:mt:] from comment #36)

Dragana, bug 1732424 suggests that we might need to include SSL_ERROR_BAD_MAC_ALERT as a reason to disable early data. What do you think?

I will add the error. It cannot hurt.

Flags: needinfo?(dd.mozilla)

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #8)

Did you try setting security.tls.version.max to 3 and leaving everything else as default?

Does this happen if you make a new profile?

Are you behind some sort of proxy or are you directly connecting to google, etc.?

Uh, sorry, I am a noob in this platform and I totally missed that.
Error started to appear with default settings, with direct connections. I tried lowering the security.tls.version.max but it didn't work.

Flags: needinfo?(manuforcen)

Are you still seeing this problem on the latest version of Firefox?

Flags: needinfo?(manuforcen)
See Also: → 1754746

(In reply to Sandor Molnar from comment #31)

https://hg.mozilla.org/mozilla-central/rev/1dab1bcd93ef

Hi, does that mean it was fixed in Firefox 94, I still have the issue in 102.4.0(ESR) failing on some sites with SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT and SSL_ERROR_RX_RECORD_TOO_LONG. I was able to solve all these issues now with security.tls.enable_0rtt_data false.

Please create a new bug for the current issue.

I guess it's bug 1753204.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: