Closed Bug 514838 Opened 15 years ago Closed 14 years ago

Occasional "Could not initialize the browser's security component" in SM 1.1.18

Categories

(SeaMonkey :: Security, defect)

SeaMonkey 1.1 Branch
x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: epp, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9.0.13) Gecko/2009080620 Mandriva/1.9.0.13-0.1mdv2009.1 (2009.1) Firefox/3.0.13
Build Identifier:  Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8.1.23) Gecko/20090823 SeaMonkey/1.1.18

Unable to access any SSL/secure/https sites, SM 1.1.18 Linux displays an alert that the SSL protocol is disabled.


Reproducible: Always
The 1.1.18 install apparently did something to the prefs.js file, as when I removed it and copied the original prefs.js file back into the profile directory, SSL pages then came through fine.
You mean the prefs.js file in your profile? The installer should not touch that file at all.
This has now occurred on a second computer with 1.1.18 for Linux installed...
Flags: blocking-seamonkey1.1.19?
Program exited, then relaunched.  The SSL errors didn't appear.  

Something is definitely amiss with this version...
It has worked fine on all my tests on Linux. Are you seeing similar problems with SeaMonkey 2.0 beta or nightly versions or with Firefox 3.x on those machines? They all use the same NSS version as SeaMonkey 1.1.18 uses now.

Not blocking on any unconfirmed, not well-reproducible problem of a single user. Please re-nominate when there are clear steps to reproduce and possible more people seeing it.
Flags: blocking-seamonkey1.1.19? → blocking-seamonkey1.1.19-
I wasn't sure about the blocking flag, thanks for removing it.  

I've seen this now on three different 1.1.18 (Linux) installs.  There will be one instance when it's launched, the SSL alerts appear.  The browser is then closed.  Re-launched the second time and everything is fine.  When the SSL alerts first appear in the browser window, Mail & Newsgroups will subsequently not launch, while displaying a similar SSL alert itself.  Once re-launched the second time without SSL alerts, Mail & Newsgroups will then launch as expected.

I am using 2.0pre to type this comment and I have yet to see an SSL alert with this version.
I can confirm it running on ubuntu 8.10. The problem is exactly the same. "Unable to access any SSL/secure/https sites, SM 1.1.18 Linux displays an alert
that the SSL protocol is disabled. Program exited, then relaunched.  The SSL errors didn't appear."
This sounds strange indeed.
Kai, Nelson, do you have any idea from the NSS POV what could be going on there?
I am using Mandriva Linux 2009 Spring.
There are a number of known PSM bugs, for which other bugzilla bug reports
are on file, that result in that error message.  I don't know why they 
would appear in SM 1.1.18 for the first time though.  

As a diagnostic step, go into about:config, filter on security.enable_ 
and copy the results as a comment into this bug.
security.enable_java                   default boolean true
security.enable_ssl2                   default boolean false
security.enable_ssl3                   default boolean true
security.enable_tls                    defualt boolean true
security.enable_tls_session_tickets    default boolean true
CORRECTION:

security.enable_java                   default boolean true
security.enable_ssl2                   default boolean false
security.enable_ssl3                   default boolean true
security.enable_tls                    defualt boolean true

(tls_session_tickets) was from version 2.0pre (had two versions running at the same time..  :(
security.enable_java true
security.enable_ssl2 false
security.enable_ssl3 true
security.enable_tls  true
OK, those outputs rule out the possibility that this is bug 368130.
I'm puzzled by the reported statements that restarting SeaMonkey corrects
the problem.  I'm aware of several issues that have been seen with NSS 3.12.x
on Linux, such as incompatible versions of some system shared libraries, 
and/or shared libraries not found (not in the LD_LIBRARY_PATH), but none of 
those problems would go away on a mere restart.  

The problems that go away on restart are generally TLS intolerant server 
detection bugs, but those only cause the reported symptoms (claiming that 
"SSL is disabled") when SSL3 is disabled, which comments 12 and 13 disprove.

Is this a one-time-only per profile occurrence?  
After you restart SeaMonkey is the problem never seen again for that profile?  
Or is this a toggle, with the problem happening every second time you start
the browser (e.g. problem on even numbered starts, not on odd numbered starts)?
> Is this a one-time-only per profile occurrence?
No.

> After you restart SeaMonkey is the problem never seen again for that profile?
No.


> Or is this a toggle, with the problem happening every second time you start
the browser (e.g. problem on even numbered starts, not on odd numbered starts)?

I would write "This happens about once per day at first launch only. Subsequent executions always work and everything is fine until I shut the computer down. I can even logout from Gnome and log on again. Everything is working." But now, after 2 hours I know that it's not true. That is weird, I can't reproduce it. However one thing I know for sure. Once it fails, just restart it and everything is working as it should.
Just a note. I can't reproduce the steps, but the problem is still there.
On first launch when I subsequently launched Mail & Newsgroups, it displayed a similar error that it could not run because of the security being disabled, yet it managed to download one e-mail that was waiting.  Going to a secure web site in the same session, it displayed the error that it could not load the page in question because SSL was disabled.

Closed SM and relaunched.  Errors did not appear and was able to connect to the secure site in question.
On two subsequent sessions beyond the last one listed in Comment 18, both times, it displayed the SSL alerts, which are as follows:

Could not initialize the browser's security component.  The most likely cause is problems with files in your browser's profile directory.  Please check that this directory has no read/write restrictions and your hard disk is not full or close to full.  It is recommended that you exit the browser and fix the problem.  If you continue to use this browser session, you might see incorrect browser behavior when accessing security features.

SeaMonkey can't connect securely to (securesite.com) because the SSL protocol has been disabled.



For the record, the profile directory can be written to as well as deleted from and there are many Gb's of storage remaining on the hard drive, it is no where near close to being full.
Edwardp,
You are describing a different problem than the problem originally reported
in this bug.  There is a HUGE difference between "Could not initialize the
browser's security component", and "SSL is disabled".  Please do not mix 
these issues together.  

Just be be clear, I'm going to ask all the contributors to this bug to 
check and report whether they are experiencing "Could not initialize the
browser's security component", or "SSL is disabled".
It is "Could not initialize the browser's security component blablabla... SSL is disabled".
Wait, I see Edwardp *IS* is the original reporter.  <blush>

PSM should not report these two separate error codes in the same error 
dialog or error page.  If it does so, that's a (another) PSM problem.  :-/
Summary: Unable to access SSL (secure/https) sites - alert displays SSL protocol is disabled → Occasional "Could not initialize the browser's security component" in SM 1.1.18
I've never before seen any report of a "Could not initialize the browser's security component" problem that can be fixed by mere browser restart. 
All known causes of that problem in the past have necessitates changes to 
files in the user's profile or elsewhere.
Subsequent sessions have continued to display these same errors, it has become hit-or-miss.

To clarify Comment 19, when the first error appeared "Could not initialize...", I clicked OK.  Then the second error appeared immediately afterwards.
OK, thanks for comment 24.  The question, then, is: 
  Why does PSM sometimes think that initialization has failed?  

Try this test.  Run the browser with this environment variable:

NSS_STRICT_NOFORK=DISABLED
(In reply to comment #25)
  
> Try this test.  Run the browser with this environment variable:
> 
> NSS_STRICT_NOFORK=DISABLED

I have never run anything with an "environment variable".  Could you please explain how this is done or where that information is placed?  (I'm not a programmer, sorry.)
I've since learned what to do.  Running SM using that variable, has not yet brought up the reported SSL errors.
Edward, I just want to be sure I understand your report in comment 27.
Are you saying that the problem is effectively solved by using that 
environment variable?
For all Unix users affected by this issue, I need to know two things:
a) does NSS_STRICT_NOFORK=DISABLED effectively solve the problem for you? and
b) please copy and paste the output of the Unix shell command "uname -a" into
a comment in this bug.
a) No, I see no difference.
b) Linux no 2.6.27-14-generic #1 SMP Tue Aug 18 16:25:45 UTC 2009 i686 GNU/Linux
(In reply to comment #28)
> Edward, I just want to be sure I understand your report in comment 27.
> Are you saying that the problem is effectively solved by using that 
> environment variable?

I cannot say for certain that running it with that variable fixed the problem.  On the two proceeding launches of SM before running that variable, it launched without displaying the SSL errors.  On the third launch preceding it, the SSL errors were displayed.  

The laptop where the above occurred has a Intel Pentium M processor.  

From a desktop system where this also occurred: 
Linux mandriva 2.6.29.6-desktop586-2mnb #1 SMP Sun Aug 16 22:48:48 EDT 2009 i586 AMD-K6(tm) 3D processor GNU/Linux

The same release of Mandriva with the same kernel revision is also installed on the laptop.
I went into the Preferences and changed the home page to a secure site (https).  Upon every launch of 1.1.8 since then, that secure site has come up perfectly and none of the SSL errors have displayed.
For the first time, I ran into this problem yesterday too in my Debian box with .tar.gz installation (/home/Programs/SeaMonkey).

There might be clues though that might help? Before I went to https://webmail.earthlink.net/, I was trying to vote on http://ve3d.com/, but it gave me an error about not being able to write (cache related?) or something. I didn't write the error down because I thought it was unrelated to SSL. I went to Webmail and it gave me that SSL error. I exited SM and relaunched to Webmail, but no errors. I tried to repeat what I did today, but failed. It seems to random and rare. :(
Oh and I forgot: 

$ uname -a
Linux ANTian 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686 GNU/Linux

This is a dual core Athlon 64 X2 box with 3 GB of RAM. See http://alpha.zimage.com/~ant/antfarm/about/computers.txt (secondary/backup machine) for the full details.
I suspect that what's going on here is something like this.
I think it may be a problem with the order in which operations are performed
in the browser, up to and including the point where the browser attempts to 
initialize NSS.

The user starts up his browser, but NSS is not initialized or used right away.
So, he visits other pages, perhaps loads lots of web pages into process memory, perhaps uses other browser extensions, which perhaps alter the process's 
LD_LIBRARY_PATH.  Then he visits an https page, or does some other action that
uses NSS, which causes NSS to be initialized.  The initialization fails because
of some reason such as
a) Process runs out of available virtual memory space
b) system runs our of swap space
c) necessary NSS libraries cannot be found because LD_LIBRARY_PATH is changed
d) perhaps other issues related to forking/cloning/threading (which I'll not 
expound on here).

So, the user gets frustrated because he cannot do SSL, so he restarts his 
browser, and this time he immediately does some operation that uses NSS to do
SSL.  This newly restarted browser has a pristine LD_LIBRARY_PATH and has 
lots of available memory, and consequently, NSS initializes just fine.  

In comment 32, Edward reported that he changed his startup page to an https
page, and subsequently has not seen a repeat of this problem.  He cited it as
evidence that the environment variable had fixed the problem, but I think it 
is possible that this change, by itself, was a cure in his case.  It ensured
that NSS gets initialized early in the browser process lifetime.  

Now, I'd like the help of the participants in this bug to do some things:

1) confirm/refute the hypothesis that the problem is due to the order of 
events by changing their browsers to visit an https page as the startup page
as Edward did in comment 32, and see if that eliminates or greatly reduces 
the frequency of the problem.

2) Setup a second profile without any extensions, so that we can confirm or
refute the hypothesis that one or more extensions are involved

3) help us identify the exact cause of the failure using strace.  To that end,
if you know of some sequence of events that you can do that will always, 
(or nearly always) cause the problem to be reproduced, so that you can reproduce it "on demand", please let us know here.  We can supply some Linux
instructions for how to gather info that will help us to determine the 
immediate cause of failure to initialize.
Nelson: What should we be checking when we reproduce the problem since we cannot easily reproduce the issue? Do we check memory, LD_LIBRARY_PATH, etc.?
Not sure if it's a detail that helps in any way, but one user that runs into the problem told me that he tried 2.0 Beta 2 now (1.9.1-based) and he doesn't run into that problem there.
Does xpfe do things way enough differently than toolkit? I guess searching differences between 1.8.1 and 1.9.1 would not be too helpful, given the large amount of stuff that has been done in that period.

In any case, this problem is one more reason for me to get SeaMonkey 1.1.x EOLed ASAP - which doesn't change that we still will need at least two or three security updates to it, so if we can find out what's going on here, it's definitely helpful.
Ant: I hope to have some detailed instructions/suggestions later today or 
tomorrow.

Robert: I believe that the newer code now uses NSS to check for updates over 
an https (SSL) link very early during process startup.  I think this 
effectively ensures successful startup.  I gather that the older code didn't 
do that.  But I'm not sure.
We should give these users a special build of
libnss3.so and libsoftokn3.so that prints to
a log file the error codes of nss_Init (which
all NSS initialization functions call) and
NSC_Initialize.
Hmmm.  Where have I heard that idea before?  :)

Given that ordinary builds of NSS now have the PKCS#11 module tracing facility
built in, that feature by itself will suffice to monitor all PKCS#11 activity 
to/from the built-in softoken module, IINM.  

Improved logging of NSS_Init* and also PR_LoadLibrary* would definitely help.
I think the first diagnostic step that people should perform is also the 
simplest.  Change the browser's startup page to an https page. I suggest
https://wiki.mozilla.org/SeaMonkey:Home_Page 
and see if that alone is enough to make the problems stop.  Let us know.
(In reply to comment #38)
> Robert: I believe that the newer code now uses NSS to check for updates over 
> an https (SSL) link very early during process startup.  I think this 
> effectively ensures successful startup.  I gather that the older code didn't 
> do that.  But I'm not sure.

Ah, yes, that sounds true, we at least look for extension updates early in startup in toolkit, and of course we that over SSL. XPFE doesn't have any automatically downloaded updates for anything, we only compare a non-SSL-RDF-provided version number and display a notification when an update is due, the user must download and update himself, completely manually.
If that analysis is true though, we might just have unintentionally papered over the whole problem in Firefox and SeaMonkey 2+.

The other thing I wonder about is that the older NSS always worked, and 3.12.3.1 shows this problem (and btw only on Linux). Did NSS change anything in loading that makes it easier for us to fail loading it properly?
(In reply to comment #41)
> ... Change the browser's startup page to an https page. I suggest
> https://wiki.mozilla.org/SeaMonkey:Home_Page 
> and see if that alone is enough to make the problems stop.  Let us know.

Done. The error didn't appear.
When I revert to my original home page I see the error again.
Next question for the people who have experienced this error:  

When you see the error message about "Could not initialize the browser's 
security component", it should also include a detailed error message that 
says exactly WHY it could not do so.  It might also include a symbolic error 
name (something like sec_error_mumble_grumble) or a negative number or hexadecimal code.  Any of that would be helpful. 


Robert: Is there any circumstance under which SM does a sequence of events 
like the following?
- initialize everything
- fork
- parent exits, execution continues in the child
? 
If so, is it possible that that sequence of events preceeds the failures 
that these folks have seen?
Is it possible to get datas (e.g., errors) if one runs SeaMonkey from a terminal? Maybe something shows up if the problem is reproduced?
(In reply to comment #44)
> Robert: Is there any circumstance under which SM does a sequence of events 
> like the following?
> - initialize everything
> - fork
> - parent exits, execution continues in the child
> ? 
> If so, is it possible that that sequence of events preceeds the failures 
> that these folks have seen?

I don't think SeaMonkey 1.x does that, i only think Firefox and SeaMonkey 2 do that sometimes, actually. I don't know the code though, Neil might know more.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #44)
> Is there any circumstance under which SM does a sequence of events like the following?
> - initialize everything
> - fork
> - parent exits, execution continues in the child
As I understand it, Linux SeaMonkey 1.x never forks. Instead, it switches profiles by issuing profile teardown and startup notifications.

Windows SeaMonkey 1.x does restart itself, but only so that it can reset turbo mode [Quick Launch] after quitting the application.
(In reply to comment #44)
> Next question for the people who have experienced this error:  
> 
> When you see the error message about "Could not initialize the browser's 
> security component", it should also include a detailed error message that 
> says exactly WHY it could not do so.  It might also include a symbolic error 
> name (something like sec_error_mumble_grumble) or a negative number or
> hexadecimal code.  Any of that would be helpful.

That's the error message. No error code.
http://mxr.mozilla.org/mozilla1.8/source/security/manager/locales/en-US/chrome/pipnss/pipnss.properties#391
(In reply to comment #35)
> 2) Setup a second profile without any extensions, so that we can confirm or
> refute the hypothesis that one or more extensions are involved

I'm running SeaMonkey with a new profile and I don't get the error anymore. Thanks.
Carlos, 
this suggests that one or more extensions may be factors in the problem.
Would be interesting to find out if any of your extensions use NSS.
FYI from my Debian box. I still haven't seen the problem again so far, but then I don't use my SeaMonkey much on it these days. Here are my extensions:

Last updated: Thu Sep 17 2009 21:23:16 GMT-0700 (PDT)
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090823 SeaMonkey/1.1.18

Extensions (enabled: 17)
* Adblock Plus (http://adblockplus.org/)
* BugMeNot (mailto:ehamiter@gmail.com)
* Colored Tabs 1.3
* Coralize 0.9 (http://piki.org/patrick/)
* Extension Uninstaller API 2.0 (http://jgillick.nettripper.com/)
* Flashblock (http://flashblock.mozdev.org/)
* Mnenhy - Chrome Manager (http://mnenhy.mozdev.org/)
* Mnenhy - Custom Headers (http://mnenhy.mozdev.org/)
* Mnenhy - Junk Filter Tools (http://mnenhy.mozdev.org/)
* Mnenhy - MailNews FolderStore (http://mnenhy.mozdev.org/)
* Mnenhy - MailNews Sidebar (http://mnenhy.mozdev.org/)
* Mnenhy - MailNews-Enhancements (http://mnenhy.mozdev.org/)
* Mnenhy - Registry Viewer (http://mnenhy.mozdev.org/)
* Mnenhy - Text Codecs (http://mnenhy.mozdev.org/)
* Preferences Toolbar (http://prefbar.mozdev.org/)
* SessionSaver 0.2d (http://adblock.mozdev.org/sessionsaver/)
* TinyUrl Creator 2.0 (http://mozmonkey.com/)

Let's compare. ;)
I see flashblock, but not flash.  What do you use for flash?  
On some platforms, flash uses NSS.
Nelson: I use Adobe's Flash and always keep it updated. SeaMonkey's about:plugins show:

Shockwave Flash

    File name: libflashplayer.so
    Shockwave Flash 10.0 r32

MIME Type 	Description 	Suffixes 	Enabled
application/x-shockwave-flash 	Shockwave Flash 	swf 	Yes
application/futuresplash 	FutureSplash Player 	spl 	Yes
No extensions are being used here.  Plugins are Flash and Sun's Java.
I've got the error message again. No extensions or plugins are being used.

I see the problem more often when I have many programs running at the same time (seamonkey, openoffice, audacious, transmission) and I think it fails because my system is running out of available memory. However, the message says there's something wrong with my profile. It's not true.

You can try
1.load a lot of programs
2.set home page http://www.folha.uol.com.br/
3.load http://clubber-musicasemaismusicas.blogspot.com/
4.error dialog
My laptop has 1.5Gb of installed memory and Linux with SeaMonkey also running uses less than 500Mb in all.  I do not believe it is memory-related.
Agreed with #56. I don't see how this is a memory issue. I have 3 GB of RAM of this old 32-bit Debian box.
I suspect that this problem occurs if you do some other activity before
visiting an https page, and I suspect that activity may involve the flash
player and flash "pages" from certain flash sites.  I suspect that it's 
as simple as this:
   visit the flash page first, then the https page: fails to init
   visit the https page first, then the flash page: is OK
It would help a lot if we could confirm (or refute) this, and if it can
be confirmed, to identify one or more flash pages that have this effect.
I follow the steps
1. set home page http://www.terra.com.br/; restart seamonkey
2. open http://www.neworderonline.com/
3. error - could not initialize browser's security...

then I've tried
1. set home page http://www.neworderonline.com/, restart sm
2. open http://www.terra.com.br/
3. ok. no error

Finally I've deleted the MOZ_PLUGIN_PATH variable
1. unset MOZ_PLUGIN_PATH
2. set home page http://www.terra.com.br/
3. open http://www.neworderonline.com/
4. OK . No error

My MOZ_PLUGIN_PATH used to work fine with SeaMonkey-1.1.x. I didn't change it recently.  

ls -l
-rwxr-xr-x 1 root staff 10131640 2009-03-06 21:33 libflashplayer.so
lrwxrwxrwx 1 root staff       56 2009-04-12 09:50 libjavaplugin_oji.so -> /usr/local/java/jre/plugin/i386/ns7/libjavaplugin_oji.so
I saw the error again. I was on digg.com, reading forums, looking a few links, and then I went to log in on mycokerewards.com to see the error. :(

Also, I do NOT use MOZ_PLUG_PATH variable. Ia also had to reboot my Debian box after 158 days of uptime due to a X and NVIDIA driver nasty crash. :(
Are there any updates on this? I am seeing this problem a lot now more since I am using my Linux/Debian box more these days. It doesn't take long either for me.

I still have not found any specific patterns to easily reproduce it, but I did notice it seems to happen when I have multiple tabs and can get the same problem even if I exit Web browser and resume it with tabs intact (using old SessionSaver extension).

We need logging so we can catch the issue. :(
Version: unspecified → SeaMonkey 1.1 Branch
I downgraded my v1.1.18 back to v1.1.17, so far no problems. I hope someone figures this out since I didn't get any help to debug since I can reproduce it after a few minutes even though I can't find the specific patterns. :(
(In reply to comment #62)
> I downgraded my v1.1.18 back to v1.1.17, so far no problems.

Looks like anyone being able to intercept your SSL connections is not a problem for you, then :P

So far, it seems pretty clear that when some plugin is initialized (probably Flash or Java), it messes up something (some environment variable?) so that we are not able to init NSS correctly any more.
Neil, do we have any possibility to always init NSS somewhere early in the xpfe-based suite startup so that an eventual 1.1.19 release can come without this problem?

For now, the workaround is to set your default homepage in 1.1.18 to some https page, that should make things always work. For anyone reading this bug for advice, do not downgrade to 1.1.17, as it allows all your SSL connections to be intercepted, i.e. all "secure" connections in 1.1.17 are in fact insecure. Use 1.1.18 instead and set your default homepage to a https page, or, even better, move to 2.0, which is in RC right now and final very soon.
Maybe something as simple as

var tokendb = Components.classes["@mozilla.org/security/pk11tokendb;1"]
                        .createInstance(Components.interfaces.nsIPK11TokenDB);
var token = tokendb.getInternalKeyToken();

would force PSM to init NSS?
Robert, thanks for the tip. I will put a secured site on my home page when SM v1.1.18 loads up.

I doubt it is related to Flash and Java because Flash is blocked due to FlashBlock extension and Java is mostly disabled (rarely use it and only enable it with PrefBars).
Not sure if this is being worked on with any enthusiasm, but I'll add in that I'm seeing this exact same bug in both SM 1.1.18 and 1.1.19 on Solaris Sparc.  I can also confirm that it is definitely not present in 1.1.17.

I'll try the various workarounds/troubleshooting discussed above and see if any are helpful on this platform.
Actually, as we have end-of-lined the 1.x series, stopped all support for it and it's even a security risk to use it because of its vulnerabilities, we better admit that we can't and won't fix this any more. Sorry.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.