Closed Bug 1463736 Opened 7 years ago Closed 7 years ago

Token with client certificate for client authentication freezes Firefox

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
60 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1461731

People

(Reporter: ivo, Unassigned)

Details

(Keywords: regression, regressionwindow-wanted)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180427210249 Steps to reproduce: OS: macOS 10.13.4 (High Sierra) with latest updates Used software: Firefox 60.0.1 (auto updated) Drivers: Safenet Authentication Client v9.1 (also tried v10) In Preferences - Security Devices we imported the Safenet drivers (/usr/local/lib/libeTPkcs11.dylib) Last step to reproduce is to open a page where we need a client certificate for authentication. Actual results: After opening a page where we need our client certificate for authentication, we get the password dialog. We enter the password and the page opens. We can do everything we want, until after a few minutes. It looks like the internet connection is gone. Opening a new tab and opening a random other website (eg. google.com) doesn't work as well, it keeps loading without showing anything. After a while Firefox completely freezes and we have to force quit to be able to close. Using other browsers at the same time does work, so it's not that the internet connection is lost on the complete system. Expected results: After downgrading to Firefox 59.0.3, everything works fine again. No endless loading and no freezes.
(In reply to Ivo from comment #0) > After downgrading to Firefox 59.0.3, everything works fine again. Please try to find the regression range if you can. https://mozilla.github.io/mozregression/quickstart.html
Has Regression Range: --- → no
Component: Untriaged → Security: PSM
Keywords: regression, regressionwindow-wanted
Product: Firefox → Core
(In reply to Gingerbread Man from comment #1) > (In reply to Ivo from comment #0) > > After downgrading to Firefox 59.0.3, everything works fine again. > > Please try to find the regression range if you can. > https://mozilla.github.io/mozregression/quickstart.html
Flags: needinfo?(ivo)
I've done test browsing sessions in 60.0b8, 60.0b4, and 60.0b3 with all those versions exhibiting the same failure pattern. I'm now testing the 60.01 ESR branches. Which nightly ranges are between 59.0.3 and 60.0b3 (as I see no 60.0b1 here https://ftp.mozilla.org/pub/firefox/releases/)
In order to use mozregression I'd need to know the nightly build that corresponds to 59.0.3 and the nightly that corresponds to 60.0b3 correct? I don't know any easy way to discern those.
Reading the documentation at https://mozilla.github.io/mozregression/documentation/usage.html it seems like you should be able to run something like `mozregression --good 59 --bad 60`. What happens if you try that?
(In reply to [:keeler] (use needinfo) from comment #6) > Reading the documentation at > https://mozilla.github.io/mozregression/documentation/usage.html it seems > like you should be able to run something like `mozregression --good 59 --bad > 60`. What happens if you try that?
Flags: needinfo?(charles)
(In reply to Charles Marshall from comment #3) > I've done test browsing sessions in 60.0b8, 60.0b4, and 60.0b3 with all > those versions exhibiting the same failure pattern. I'm now testing the > 60.01 ESR branches. What do you do exactly? For me the bug sometimes doesn't show up (~5% of the cases), which makes it harder to test. Running the mozregression for the second time now, just to be sure.
For me it's simply opening Firefox and using the browser for a few minutes. I don't have an exact recreation of the failure case, other than having the client token library installed and using the browser. It happens whether the token is plugged in or not.
Flags: needinfo?(charles)
Charles, did you manage to narrow down the regression range to a specific version of Nightly using the command `mozregression --good 59 --bad 60`? If so, what was the version?
Flags: needinfo?(charles)
@Charles I have the same. No necessary things to reproduce, just using the browser and within minutes it hangs. I will continue regression test today or tomorrow, but I've narrowed it down for me: 108:04.58 INFO: Newest known good inbound revision: 94472d41963d1ce2d76b18965f7b0064fc75fbb7 108:04.58 INFO: Oldest known bad inbound revision: ba13ada04e711ac26412f2d176a0fa80151455dd 108:04.58 INFO: To resume, run: 108:04.58 INFO: /usr/local/bin/mozregression --repo=mozilla-inbound --good=94472d41963d1ce2d76b18965f7b0064fc75fbb7 --bad=ba13ada04e711ac26412f2d176a0fa80151455dd After I've finished, I will manually test it as well, just to be sure.
Flags: needinfo?(ivo)
Also reproducing this issue. Also using the SafeNet Authentication Client (9.1.2.0) Build ID: 20180516032328 OS: MacOS Sierra 10.12.6 (16G1408) Used software: Firefox 60.0.1 Trying to use mozregression, but struggling to reproduce it reliably. I'll hopefully narrow it down as the day goes on.
24:47.03 INFO: No more inbound revisions, bisection finished. 24:47.03 INFO: Last good revision: 6b4ffe42ad3fd208af3e1d1f34e8c9a981fdb0d4 24:47.03 INFO: First bad revision: 1c8bbd57b772157a6119f7773cc4ec8f4b7c1539 24:47.03 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6b4ffe42ad3fd208af3e1d1f34e8c9a981fdb0d4&tochange=1c8bbd57b772157a6119f7773cc4ec8f4b7c1539 Given the iffy reproduction, I'm going to give this another try, to see if I end up on the same bad revision.
I've finished the mozregression, and it came up with these results. ... 66:49.71 INFO: Using local file: /Users/ivogeersen/.mozilla/mozregression/persist/6b4ffe42ad3f--mozilla-inbound--target.dmg (downloaded in background) 66:49.71 INFO: Running mozilla-inbound build built on 2018-01-23 13:43:00.381000, revision 6b4ffe42 67:13.78 INFO: Launching /private/var/folders/81/d2vs7r4d22q3pb0625xz2mv40000gn/T/tmpPeo9LW/Firefox Nightly.app/Contents/MacOS/firefox 67:13.78 INFO: Application command: /private/var/folders/81/d2vs7r4d22q3pb0625xz2mv40000gn/T/tmpPeo9LW/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/81/d2vs7r4d22q3pb0625xz2mv40000gn/T/tmpmXNO1D.mozrunner 67:13.80 INFO: application_buildid: 20180123130815 67:13.80 INFO: application_changeset: 6b4ffe42ad3fd208af3e1d1f34e8c9a981fdb0d4 67:13.80 INFO: application_name: Firefox 67:13.80 INFO: application_repository: https://hg.mozilla.org/integration/mozilla-inbound 67:13.80 INFO: application_version: 60.0a1 Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good 95:59.73 INFO: Narrowed inbound regression window from [94472d41, 1c8bbd57] (4 builds) to [6b4ffe42, 1c8bbd57] (2 builds) (~1 steps left) 95:59.73 INFO: No more inbound revisions, bisection finished. 95:59.73 INFO: Last good revision: 6b4ffe42ad3fd208af3e1d1f34e8c9a981fdb0d4 95:59.73 INFO: First bad revision: 1c8bbd57b772157a6119f7773cc4ec8f4b7c1539 95:59.73 INFO: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6b4ffe42ad3fd208af3e1d1f34e8c9a981fdb0d4&tochange=1c8bbd57b772157a6119f7773cc4ec8f4b7c1539
Given the fact that Edward Shaw had the same results as I have, I think we've successfully found the regression range. I will also check it again, just to be sure. If it fails, I'll update here.
Has Regression Range: no → yes
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86
In which case, I won't try again. I got a different (later) range the second time - I stopped being able to reproduce the issue on revisions I previous had.
So it's probably due to a change in NSS, since bug 1432177 updated the copy of NSS in Firefox. Can you get a stack trace of what Firefox is doing when it freezes? see e.g. https://developer.mozilla.org/en-US/docs/Mozilla/How_to_report_a_hung_Firefox
Flags: needinfo?(ivo)
Actually I bet this was fixed by bug 1447628. Can anyone affected by this problem see if it reproduces in Beta? https://www.mozilla.org/en-US/firefox/channel/desktop/
I can reproduce the issue on an up-to-date Firefox Developer Edition (61.0b11) Version: 61.0b11 Build ID: 20180604143143 From the troubleshooting info page, seems that build is using NSS 3.37.1, which looks like it should have the fix in? I can test on specifically Beta if desired? I'll reproduce on stable, and trigger a few crashes.
Thanks! I'm fairly sure bug 1461731 addresses this. The updated NSS should be in the next beta on Thursday. Please re-open this bug if it's not fixed with that version.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(ivo)
Flags: needinfo?(charles)
Resolution: --- → DUPLICATE
FWIW, looks like Firefox Dev Edition 61.0b12 (w/ NSS 3.37.3) has fixed the issue. Leaving this resolved.
You need to log in before you can comment on or make changes to this bug.