191845 - Could not establish an encrypted connection, error -8182 or -12219

Status: RESOLVED INVALID

(Core Graveyard :: Security: UI, defect)

Description

[Fred Musick]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

HTTPS sites will not load- all attempted so far - Site name changes in error
message but otherwise persists to all sites tried.  ERROR MESSAGE READS

Could not establish an encrypted connection because certificate presented by
<my.screenname.aol.com> is invalid or corrupted.  Error Code: -8182

Attempt to access intranet OWA site prompted for acceptance of internal
certificate. selected always accept | clicked OK | returned error connecting to
OWA Error code: 12204

Reproducible: Always

Steps to Reproduce:
1. Attempt to open ANY httpS site
2. Attempt to open OWA Intranet site
3.

Actual Results:  
Same as details above - every time

Expected Results:  
established a secure connection to the site or in the case of the OWA site
accepted the local cert when prompt was marked accept and OK'd

ALL tabs under Preferences | Privacy&Security | Certificates | Manage
Certificates  are vacant except Authorities.  The file cert7.db does not exist
on this computer

Comment 1

[Boris Zbarsky [:bzbarsky]]

psm

Comment 2

[John Unruh]

Reporter, can you try setting up a new profile? Your cert DB may have become
corrupted. You might also want to upgrade to 1.3a, installing into a new directory.

Comment 3

[Ken Johanson]

I too am experiencing this bug - its seems to have come about in the 1.6 builds,
as 1.5 is fine. I either get error code -8182 or 12219. I have tried creating
new profiles, as well as various combinations of SSL3/TLS restrictions under
Prefs->Security->SSL -- same result always.

Here are some sample URLs:
https://www.breezeway.tv (CA signed, valid)
https://www.onnet.cc (self-signed wildcard)

Probably related to bug 225159. I hope this bug doesnt get into a 1.6 release.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Ken, 
in bug 191845, you claim to see error -8182.
In bug 225159, you claim to see error -8183.

These bugs have very different causes.  See
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html#1037303

Please confirm what you're seeing, and whether it is reproducible with the 
latest nightly build.  Thanks.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

I should have written:  these *error codes* have very different causes.

BTW, this does NOT appear to be an NSS regression.  The combination of 
mozilla 1.3.1 with the latest NSS trunk does not exhibit this problem.

Comment 6

[Ken Johanson]

On last nights build, I now get only error -12219 (not listed on the codes page)
on all the sites I had problems with. I no longer get any other code, so cant
confirm which it was... Will continue trying to dupl.

The error 12219, at least, does ONLY happen on post 1.5 builds, including last
night's...

Thanks for the link to the error codes - I must be awful at finding these things
- my searches never found this page so I hand no clue what was wrong (just a
number). Could the error codes be shown in the error dialog, beside the number?

Comment 7

[Ken Johanson]

Hmm the error code is on that page - see how bad my search skill are?

"Unspecified failure while processing SSL Client Key Exchange handshake."

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Ken, On what exact URL do you get error -12219?

This error typically means that NSS thinks the public key in the server's 
cert is an invalid RSA key.  I want to see if the site's key is bad, or 
if this is an NSS bug.  NSS experienced a regression in that area 
several weeks ago, but it was fixed just a few days after it occurred.
nightly builds should not still be experiencing that bug.  

However, the subject of _this_ bug remains error -8182.
error -12219 should get its own bug report, if it is indeed a bug.

Comment 9

[Ken Johanson]

Here's several different sites, all with different certs:
https://www.breezeway.tv/ is CA signed,
https://www.onnet.cc/ is self signed,
https://home.encorehollywood.com/ is also self signed.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Ken, thanks for those URLs.  They explained what's going on.  
When I visit https://www.breezeway.tv/ I get error -12219
When I visit https://www.onnet.cc/     I get error -8182

In both cases, mozilla had detected an important problem with the certs,
and has reported it.  Mozilla is behaving correctly here.  Mozilla is 
detecting a problem with these certs that older versions of mozilla,
(and apparently current versions of other products) did/do not detect.

Both of these certs have the same problem: 
The RSA public key has a public exponent value that is the number 1 !!

When such an RSA public key is used to encrypt, no encryption whatsoever is
actually done.  That is, the "RSA encrypted" data is identical to the 
unencrypted data that was "encrypted".  This is totally insecure.

Any SSL "secure connection" done with a web site that uses such an RSA 
public key can be trivially decrypted by anyone who can record the 
connection (e.g. with a sniffer).  

So, mozilla protects its users by not allowing a "secure connection" to 
be done with those keys.  In the case of error -12219, it is detecting
the invalid RSA key when it goes to actually encrypt the SSL pre-master
secret to send to the server.  In the case of error -8182, mozilla is 
detecting the error at the point that it validates the signature on the
certificate, causing mozilla to report an invalid signature.  

So, this "bug" is not a mozilla bug at all, and I will mark it invalid.

I'm surprised to find certs in actual use with such a public key, 
especially in certs issued by well known public CAs!  

Comment 11

[Ken Johanson]

Wow! Finally good to here a response on this bug from an expert!

So I guess it goes without saying that this is an error that Mozilla should be
made to be much more verbose on, if possible (enless there's 10s or 100s of
similar exceptions as well).

Does mozilla have a built in SSL debugging mechanism, ala verbose logging or the
protocol perhaps. Or can you recommend some Java/C package that would
demonstrate this.

Yes, it truly is strange that no other client product (that I've ever used, app
or API) complains about this. My faith about SSL's strength is slightly
devastated. :)

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

There is an SSL trace feature in the source, but you have to compile it in.
That is, you have to build your own NSS to get this feature.

The released NSS binaries include a number of useful command line tools,
such as vfyserv, which tells you what it finds in a server's cert chain, and
ssltap, which acts like a proxy server (sort of), and simply reports what goes
by (analyzing the unencrypted portions of the SSL records and messages).