Closed
Bug 181822
Opened 23 years ago
Closed 23 years ago
Login to Schwab returns error code -8190 when trying to establish an encrypted connection
Categories
(Core Graveyard :: Security: UI, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: mrp.bugzilla1, Assigned: ssaux)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b; MultiZilla v1.1.25) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b; MultiZilla v1.1.25) Gecko/20021016
We are unable to access the Schwab web site with Mozilla. When clicking on the
'login' button, a dialog box pops up with the following error message:
"Error establishing an encrypted connection to investing.schwab.com. Error
code: -8190."
IE and Netscape 4.79 have no problems with it. The problem is repeatable on all
versions of Mozilla I have tested (> 0.96) and on both Windoze and Linux platforms.
Needless to say, it breaks my heart to crank up Netscape 4.79 to access Schwab.
Reproducible: Always
Steps to Reproduce:
1. Surf to www.schwab.com
2. Click on the "Login" icon or keyword
3. Up comes the error message (popup dialog), and further progress into schwab
will not be possible.
Actual Results:
A dialog box pops up with the following message:
"Error establishing encrypted connection to investing.schwab.com. Error code:
-8190."
Expected Results:
Established an https connection to investing.schwab.com. The
Investing.schwab.com web page should ask for a user name and password.
The problem has been tested with:
Mozilla 1.2b on WindozeXP
Mozilla 1.0 on Mandrake Linux 8.2+Ximian
Mozilla 1.1 on Mandrake Linux 9.0
The problem has existed for quite a while (> Mozilla 0.96). The problem has
been repeated on machines both at home and at work, so it is not isolated to a
"bad configuration" or "hosed registry". Unless, I've configured all four
machines similarly, and incorrectly.
Home machines have no proxy. Work machines try to access schwab through a proxy
firewall. Problem exists in Netscape 7.0 also. However, IE and Netscape 4.79
are able to access schwab from these same machines with no problem. For the
Linux platforms, Konqueror and Galeon work as well.
Have tried using HTTP 1.0 with pipelining and keep alive turned off--no success.
Have disabled most of the crypto except SSL2 (which is what I believe schwab
wants)--no success.
Problem could be user error--as I find bug reports indicating that others are
accessing schwab with only limited problems. But, for the life of me, I can't
figure out what I could be doing incorrectly. To me, it appears to be a Mozilla
bug at this time.
Comment 1•23 years ago
|
||
-> PSM (please read the component description sice securtiy doesn't hanle
SSL/TLS bugs)
Have you tried it with a new (additional test) profile ?
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: Trunk → unspecified
| Reporter | ||
Comment 2•23 years ago
|
||
Creating a new "test" profile clears the problem right up! Sorry I didn't think
to try that. Also, sorry about mis-classifying the component of the bug
report--tried my best, and guessed wrong.
Mozilla (and I) are VERY happy at this point. However, should the report stay
open since it doesn't work in the default profile?
Thanks for the help!
Comment 3•23 years ago
|
||
Have you migrated old NS4.7x profiles ?
Please rename/move to another location this files from your old profile:
cert7.db , key3.db
Comment 4•23 years ago
|
||
Reporter, can you check your old profiles to see if OCSP was turned on? That may
have been the problem. Edit>Prefs>Privacy>Validation. If so, set it to "Do not
use OCSP", which is the default.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
| Reporter | ||
Comment 5•23 years ago
|
||
Answers to comment #3:
Yes, it is highly likely that the Netscape 4.79 settings were migrated.
As instructed, for the default profile I renamed cert7.db and key3.db to
cert7.db-old, and key3.db-old respectively. That does not clear up the problem.
Answers to comment #4:
OCSP is off per the default install. I will admit to fiddling with it to see if
it was the culprit; however, when it didn't correct anything, I restored it to
the original setting (off).
Thanks for the suggestions. I'm willing to try any others, as it seems a 'bad
thing' for one profile to work and another one not. Particularly when the other
one is the default profile.
| Reporter | ||
Comment 6•23 years ago
|
||
Found it! The Schwab web page breaks if I enable FIPS in the
Privacy&Security>Certificates>Manage Security Devices.
Looks like I caused the problem by setting this option. However, I reopened the
report for evaluation. SSL shouldn't break because FIPS is turned on, should it?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Comment 7•23 years ago
|
||
No, SSL should not break when FIPS is enabled. That is a separate bug to disable
SSL2 when FIPS is enabled, which for some reason, Schwab uses exclusively, no
SSL3 or TLSv1. Marking worksforme instead of duplicate of bug 106604.
Reporter, you might have better error messages with a more recent nightly build
at www.mozilla.org. Install into a clean directory in case there is a problem
with a particular night's builds. All of your profiles will still be available.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•