Closed Bug 124901 Opened 23 years ago Closed 6 years ago

Webclient won't load SSL pages with questionable certificates

Categories

(Core Graveyard :: Java APIs to WebShell, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mpepstei, Assigned: joe.chou)

References

Details

Attachments

(1 file)

It seems that if you try to navigate to a page with Webclient that uses https 
and the certificate doesn't completely check out (e.g. the name is different 
from the server or the authority is not recognized), the Webclient does nothing 
(it just stays on the current page). I tried this in the application where I'm 
embedding as well as the EMWindow sample application that comes with it and I 
got this no-op behavior. If you go to the same site with Mozilla or IE, you get 
a warning dialog. Note that pages with completely valid SSL certificates seem 
to load just fine.

Try this:
go to https://login.yahoo.com
This has a valid certificate and should be fine

Now try https://mail.yahoo.com
Nothing happens

Do this in a regular browser and it will inform you that the certificate 
applies to login.yahoo.com, not mail.yahoo.com, so you must authorize the 
connection.

Note that in both my application and EMWindow the Prompt interface is 
implemented, but is not brought into play for this certificate situation.
Reporter: Please always specify which "Build ID" you're using,
as found in the title bar of the main Mozilla window. Thank you for using Bugzilla!
Oops. Meant to do that. I'm running Gecko/20010726 Netscape6/6.1 with
Webclient 1.1 (Win32).
Ed, do you know of any way to deal with this?
This also happened with Mozilla 0.96, there was a MessageBox which told about
the invalid certificate, but after confirming nothing happened.

On Mozilla 0.98 I receive the following error-message after I confirm: 
"www.mmc-startup.com ha received an incorrect or unexpected message. Error Code:
-12227"
There doesn't seem to have been any activity on this bug since it was reported. 
I understand the developers are probably very busy with getting Mozilla 1.0 
out, but it would be greatly appreciated if someone could confirm or resolve 
this issue and offer some sort of workaround if there is one, or at least 
explain why this bug is not getting attention.
This bug is a real problem for me, because I have to use IExploder for pages
with questionable certificates. So I can't exclusivly use Mozilla but I'd love to.
You might want to compare against bug 113007 :

http://bugzilla.mozilla.org/show_bug.cgi?id=113007

to see if this is a dupe or dependent on that bug. It would be nice to 
consolidate them if we can.
I guess this bug is a dupe of bug 113007 . However the thing I reported here was
about something else and I just "got this bug wrong".

So I have added a new bug 143744 , which is about "my" problem.
Clearly this is a duplicate of Bug 113007. Can somebody please mark this one as
duplicate.
Is it clearly a duplicate? Many comments in Bug 113007 talk about fixing
MFCEmbed. If I understand it correctly, MFCEmbed is just one embedding client,
not the main embedding API. Does this problem need to be fixed in each embedding
client or is it one fix in the embedding core and everything works? If each
needs to be fixed, then this bug applies to the Java Webclient and should remain
independent.
marking NEW to get more attention
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hi, my problem may be related to this bug (I am not sure),
I have written my own HTTPS server and recognized the following:

If I close the socket of the https request after 100 milliseconds 
of inactivity I can NOT access the page with Mozilla 0.9.7 ... 1.1beta,
but if I configure the server to close the socket after 10000 milliseconds 
I can. With Netscape 4.77 this problem don't occure, and the reason is:

At the first access to the server a certificate check is started and this 
needs a long time (because user interaction is needed), at the end the user
accepts the server certificate but the connection is perhaps closed; now:
Mozilla don't remember that the user accets the certificate but Netscape 4.77
does. As a result I can connect to the https-page with netscape on the second
try but I can't access it on the second try with mozilla because it starts
a new certificate acception process with the user.
This bug is related to problems with certificates in Mozilla Webclient, a Java
embedding API for Mozilla. From your description, it sounds like your issue may
be related to Mozilla in general. Do you have the certificate problem using an
embedded version of Mozilla (in which the browser is inside a different
application) or using the actual Mozilla browser?
My problem occures with a not embedded version of mozilla,
on a SuSE Linux 7.2 Box; and other browser like Netscape 4.77 
opera, links, ... don't have this problem
I believe this is my problem as well.  I use a self-signed certificate (so login
passwords are not sent clear text) for my personal web page.  Other browsers
(IE, Opera for example) will report the state of the certificate correctly and
allow access.  Mozilla (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1)
Gecko/20020830) reports:

Error establishing an encrypted connection to <addr>.
error code -8183

Same situation with Netscape 7.0 (Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.0.1) Gecko/20020823 Netscape/7.0).
Running Mozilla 1.1 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826) on Windows 2000 SP1. May have further evidence related to this bug.
I access a site with no valid cert chain. Mozilla (correctly) complains (e.g.
"you have attempted to establish a connection with mail.yahoo.com". BUT it then
goes on to say "however, the security certificate presented belongs to "Raymond
Foulkes 222159". This is MY server certificate stored on MY local smartcard,
visible through the security options. It looks like Mozilla is reporting the
wrong cert i.e. a local one, not one presented by the https site. Would be nice
if it got the cert right and allowed me to OK it (some of our certs not
traceable to root authority built into Mozilla). I am not a developer, just a
user, so I cannot take part in the "component" discussions.
I sort of have renewed interest in this bug now. I checked the behavior with
Webclient 1.3 (and Mozilla 1.0.1 and JDK 1.4.1_03) and it's gotten WORSE! Now,
Webclient simply does not connect to SSL sites, regardless of whether the
certificate is correct. I would imagine this puts a kink in a lot of projects. I
haven't tried this against what's in CVS (I lack the skill to build Webclient),
but if SSL doesn't work, I would consider this a showstopper. Have others had
problems with SSL? Can someone verify if the problem still exists in a CVS build?

I suspect there is a connection between this bug and bug #113007. See comment
#10 of this bug for more on that. Interestingly, someone "recently" indicated
that 113007 has worsened in the same way as this bug (37th comment of 113007),
but no one has yet commented on whether the SSL problem stems from the embedding
library or the particular embedding clients (e.g. Webclient, MFCEmbed, etc.).

Any feedback on this issue would be much appreciated, especially a sense of when
this might get some attention.
Hi M. Epstein,
Can you please specify steps to reproduce your problem? I want have a look into
the probem. I have found that the Webclient application hangs while accessing
https pages when cookies dialog is displayed in the demo application, but if
have cookie accepted and offered to remember it works without problem. And I
have found it also hang when password save dialog appears in https page. Off
course for invalid certificate nothing happens. I think the embedded
clients(like Webclient etc) need to handle this situation based on some event.

I am using 
a) Webclient 1.3 
b) JRE 1.4.1_05
c) MOZILLA 1.0.1

FYI: I have juts compiled webclient in cvs against MOZILLA 1.4 but I feel it is
not stable as 1.3. I am in process of testing it.
To reproduce this problem:
1. Start the Webclient test application (if installed according to its
instructions, this is located in the Mozilla directory under
bin\javadev\example) by double-clicking its runem.bat file.
2. In the application's location bar, type in a URL for a site with a known
problematic certificate, e.g. https://mail.yahoo.com.
3. Note that nothing happens (at least in Webclient 1.3 with Mozilla 1.0.1).

To address some of your other questions and comments:
We have found Webclient 1.2 often hangs if a modal dialog is displayed (on
non-secure sites). We've gotten around this problem by displaying the dialogs in
a separate thread. Interestingly, the cookie dialog appeared while using
Webclient 1.3 to reproduce this bug and it did not hang the application.

It's possible the certificate problem is rooted deeper in the Mozilla embedding
infrastructure. Have a look at bug # 113007 for some discussion on that.

I'm glad to hear work is going towards getting Webclient working with newer
versions of Mozilla.

I finished testing the latest webclient compiled with mozilla 1.4 and it is
quite unstable. I could reproduce the certificate problem. As mentioned it has
gotten worse in latest version of webclient with jdk1.4+. Now you can't visit a
page https page itself . I get the following error when visiting HTTPS page
---> WARNING: no registered socket provider. 
I suspect some PSM problem.

I don't think  Mozilla embedding has problem as off mozilla version 1.4.
As i have found "mfcembed" works perfectly when visiting site like 
https://mail.yahoo.com, It shows appropriate message as the normal browser would do.

edburns has published webclient2.x design, but i don't know when he would start
it. I am thing of implementing webclient based on how "mfcembed" is implemented.
 Any suggestion would be realy helpfull. 



 
I don't know a whole lot about Mozilla's embedding architecture, so I couldn't
make informed suggestions for improvements but it would definitely be nice to
see some of the stuff in CVS (e.g. the Selection API) made available and it
might be easier to integrate new browser features quickly if the Java-to-XPCOM
bridge were revived (see http://www.mozilla.org/projects/blackwood/connect/),
but this discussion is probably best suited to the Mozilla Java newsgroup
(netscape.public.mozilla.java or mozilla-java@mozilla.org) instead of this bug.
If possible, it's probably better to try to work with the existing Webclient as
opposed to making a rival one.
Webclient 2.0 a1 TestBrowser app won't load *any* https page with the following
error printed at the console:

     [java] WARNING: no registered socket provider, file
.../mozilla/netwerk/base/src/nsSocketTransport2.cpp, line 751

To reproduce:

1. Apply attached patch so that TestBrowser class passes https URLs down to
Webclient API.
2. ant.bat run.test.browser (make sure it rebuilds TestBrowser.java!)
3. Type in https://login.yahoo.com/ -- nothing happens in the browser, the
above error message is printed in the terminal

Win2k, MOZILLA_1_6_RELEASE, Webclient 2.0 a1.
Depends on: 113007
Product: Core → Core Graveyard
Java APIs to WebShell isn't a thing anymore. Closing.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: