Closed Bug 112055 Opened 23 years ago Closed 11 years ago

Mozilla fails to pass a serialized object to the server upon an SSL POST from an applet

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: bcortez, Assigned: alfred.peng)

Details

Attachments

(1 file)

The HTTPSTestApplet and HTTPSTestServlet ZIP file
8.78 KB, application/octet-stream
Details 
==================================
Mozilla Build:  2001112009
Operating System: Windows 2000
Java Plug-in: Version 1.3.1
WebServer: Apache 1.3
SSL Module: mod_ssl version 2.8
Application Server: JRun 3.1
==================================

Mozilla fails to pass a serialized object to the server upon an SSL POST from 
an applet.  An error appears in the Java Console Log (see below).

-----------------------------------------------------------
Java Plug-in Console Error
==========================

Failed to parse the response with object serialization stream: 
java.io.StreamCorruptedException: InputStream does not contain a serialized 
object

	at java.io.ObjectInputStream.readStreamHeader(Unknown Source)
	at java.io.ObjectInputStream.<init>(Unknown Source)
	at com.kronos.wfc.wfp.xmlclient.SerializationClient.getResponseForHTTPS
([DashoPro-V2.1-110100])
	at com.kronos.wfc.wfp.xmlclient.SerializationClient.getResponse
([DashoPro-V2.1-110100])
	at 
com.kronos.wfc.wfp.uiframework.datamanager.RetrieveObjectsFromServer.run
([DashoPro-V2.1-110100])


The application could not get data from the server.

-----------------------------------------------------------
Apache SSL Log
==============

[26/Nov/2001 19:19:49 00776] [info]  Connection to child 19 established (server 
aaa.bbb.com:443, client xxx.xxx.xxx.xxx)
[26/Nov/2001 19:19:49 00776] [info]  Seeding PRNG with 0 bytes of entropy
[26/Nov/2001 19:19:50 00776] [info]  Connection: Client IP: xxx.xxx.xxx.xxx, 
Protocol: SSLv3, Cipher: EDH-RSA-DES-CBC3-SHA (168/168 bits)
[26/Nov/2001 19:19:50 00776] [info]  Connection to child 19 closed with 
standard shutdown (server aaa.bbb.com:443, client xxx.xxx.xxx.xxx)


-----------------------------------------------------------
Apache Error Log
================

[Mon Nov 26 19:19:50 2001] [error] [client xxx.xxx.xxx.xxx] request failed: 
error reading the headers
oji.  This is not a blocker...
Assignee: idk → joe.chou
Severity: blocker → major
Status: UNCONFIRMED → NEW
Component: Java to XPCOM Bridge → OJI
Ever confirmed: true
QA Contact: avm → pmac
Can you supply a test case for this?
We are preparing a testcase now.  Please bear with me on this, a testcase _is_ 
forthcoming.

Thanks for your patience.... :)


Instructions for setting up the HTTPSTestApplet and HTTPSTestServlet:

- Unzip the zip file.

- The classes and source files are in a directory structure
com\kronos\wfc\test. Place this entire directory structure (staring with 'com')
in directory named '/lib' where the /lib directory resides on your web server's
root directory. The results will look like
<someWebRoot>\lib\com\kronos\wfc\test\.

- Move the file HTTPSTestApplet.html to a directory named '/html' where the
/html directory resides on your web server's root directory.

- Examine the applet tags in the HTTPSTestApplet.html file. It can use both the
OBJECT and the EMBED tags. Make sure that the way the tags are written is
correct for your browser. (This has only been tested in IE).

- Register com.kronos.wfc.test.TestServlet with your application server. For
instance, if you are using JRun, add new entries for <servlet> and
<servlet-mapping> to the web.xml file. Give the servlet the web-visible name of
"HTTPSTestServlet".

- Configure your server to be an SSL server. (In the real world, customers
typically configure the server to be https:// only, preventing any requests
using the plain http:// protocol).

- Open your browser and go to
https://someHost/someWebRoot/html/HTTPSTestApplet.html. (Be sure to use the SSL
protocol, https)

- Type https://someHost/someWebRoot/HTTPSTestServlet. (Be sure to use the SSL
protocol, https).

- Click the GET button.

- Click the POST button.

- Click the two buttons again several times.

- Open the Java console. A servlet session ID is logged for each GET and POST.
It should be the *same* for all of the POSTS and GETS. Also, there should be no
exceptions in the console.
Here is a testcase.  I don't have the ability to setup an SSL server that would
be publicly available, so the JAVA code and instructions are in the attached ZIP
file.

See Attachment #72074 [details] for the ZIP file with included instructions.  



Thanks a lot for your testcase, but I fear we are not yet there. You say in
order to use the testcase one needs an "application server". I don't have one.
How can we setup on for debugging? Can you help?

Well, first you need to setup an SSL enabled web server such as Apache 1.3 .  
Then you need to setup an application server such as Jakarta Tomcat 3.x or 
Allaire/Macromedia JRun 3.1 (JRun 3.1 is what we are using). These are 
available at:

Apache Web Server 1.3 - http://httpd.apache.org/docs/
Apache Tomcat - http://jakarta.apache.org/tomcat/index.html
Allaire/Macromedia JRun 3.1 - http://www.macromedia.com/software/jrun/


Remember to setup the Apache Web Server an an SSL server.



Ok, I have an https apache server available. I'll look into setting up tomcat
soon. Although it of course would be easier, if we already had one set up
somewhere, where we could put your files on.

Clarification of the test case instructions:

The statement, "- Type https://someHost/someWebRoot/HTTPSTestServlet. (Be sure 
to use the SSL protocol, https)." should say:

- At the top of the applet in the text input box, type - 
https://someHost/someWebRoot/HTTPSTestServlet. (Be sure to use the SSL
protocol and the real URL for your HTTPS server).


Running the testcase applet here locally, I've included some JAVA console log 
traces for reference purposes (one passes using HTTP and one fails using HTTPS)

 - Browser: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) 
Gecko/20020303
 - Build ID: 20020308
 - Java Plug-in: 1.3.1_02




1. Correct behavior during a standard HTTP session: (GET,POST,GET,GET,POST,POST)

Button click for: GET
URL is: http://bcortez/wfc/HTTPSTestServlet
Got object type: java.util.Hashtable
Result is: This is the response for doGet - session ID: 2313581015354969306
Button click for: POST
URL is: http://bcortez/wfc/HTTPSTestServlet
Result is: This is the response for doPost - session ID: 2313581015354969306
Button click for: GET
URL is: http://bcortez/wfc/HTTPSTestServlet
Got object type: java.util.Hashtable
Result is: This is the response for doGet - session ID: 2313581015354969306
Button click for: GET
URL is: http://bcortez/wfc/HTTPSTestServlet
Got object type: java.util.Hashtable
Result is: This is the response for doGet - session ID: 2313581015354969306
Button click for: POST
URL is: http://bcortez/wfc/HTTPSTestServlet
Result is: This is the response for doPost - session ID: 2313581015354969306
Button click for: POST
URL is: http://bcortez/wfc/HTTPSTestServlet
Result is: This is the response for doPost - session ID: 2313581015354969306



2. Incorrect behavior during an HTTPS session: (GET,POST,GET,GET,POST,POST)

Button click for: GET
URL is: https://bcortez/wfc/HTTPSTestServlet
Got object type: java.util.Hashtable
Result is: This is the response for doGet - session ID: 2896001015355271500
Button click for: POST
URL is: https://bcortez/wfc/HTTPSTestServlet
Result is: This is the response for doPost - session ID: 514101015355283658
Button click for: GET
URL is: https://bcortez/wfc/HTTPSTestServlet
Got object type: java.util.Hashtable
Result is: This is the response for doGet - session ID: 1017271015355284759
Button click for: GET
URL is: https://bcortez/wfc/HTTPSTestServlet
Got object type: java.util.Hashtable
Result is: This is the response for doGet - session ID: 45891015355285410
Button click for: POST
URL is: https://bcortez/wfc/HTTPSTestServlet
Result is: This is the response for doPost - session ID: 1083611015355286322
Button click for: POST
URL is: https://bcortez/wfc/HTTPSTestServlet
Result is: This is the response for doPost - session ID: 1993311015355286963



Notice the session ID remains the same (as it should) during the HTTP session, 
however, a new session ID is created for each request during the HTTPS session. 
This session ID is created by the application server (JRun 3.1) to track the 
users session.  This is standard for all similar application server 
implementations.  This session is stored as a cookie in the browser and should 
be passed along for EVERY request.  f the server recieves a request without a 
session ID cookie, it creates a new session ID and places it in the next 
outgoing cookie.  In this case, it looks as if Mozilla is NOT passing that 
cookie along for HTTPS requests.




Any progress on this issue since I posted the comments on the testcase applet 
on 3/5/2002?

I'm sorry, but I was unable to set up a test server environment, I realized it
is more than a simple compile, the installation requirements are huge. In
addition I don't have experience with servlets. If you can, please set up a
server I can use to test with, so that I only need to debug the client.


I am in the process of giving you access to a test machine to debug from the 
client.  Kai, I'll contact you offline to get the required ifo I need to make 
this happen.  I wouldn't want you posting IP addresses here....that could be 
bad :)

Hi,
I have an issue that may be related and, may have the potential to shed some
light on the SSL post issue with the applet request.

Below is a testcase that demonstrates that Mozilla treats a SSL post request as
if it was an ordinary unencrypted post request, at least at the user interface
level:

<HTML>
<HEAD>
<TITLE>Post to Secure Server Test</TITLE>
</HEAD>
<BODY>
<FORM action="https://www.verisign.com/" method="POST">
<INPUT type="hidden" name="testvar" value="test data">
<INPUT type="submit" value="Submit (post) to Secure Server">
</FORM>
</BODY>
</HTML>

Before you run this you should back up/delete your prefs.js file so you cn be
sure to get the post action warning dialog.

When you run this test, you get the following text in a dialog box:

"The information you have entered is to be sent over an unencrypted connection
and could easily be read by a third party."

Obviously the testcase is coded as to post the data over a secure connection, so
there is something wrong.

The verisign example action URL is not capable of processing a post request but
that doesn't matter. You can easily change this and I assure you that I get this
error with a properly set up SSL Java application server as well.
Kai (or whomever it may concern),

  This bug is still sitting in limbo, and I haven't heard a response from you 
concerning giving you access to our system.  If you need access to one of our 
test servers,  you'll have to send me the IP address(es) of the machine(s) you 
intend to use.  I'll have our IS dept open up our firewall to allow only 
those/that machine(s) access.  This is an important bug from our corporate 
perspective.  We've had numerous customers complain about not being able to use 
Netscape with our product.  We've explained it is a bug (and even gave them the 
bugzilla URL below)...
http://bugzilla.mozilla.org/show_bug.cgi?id=112055


Thanks for your time, hope to hear from you so we can move forward toward a 
resolution.

:)


I'm sorry, I still did not have time to look into this. In addition, I don't
have a fixed IP address either. :(

But what bht writes is actually very interesting.

bht says, Mozilla seems to think the POST over SSL is actually an insecure post.
If that is true, then maybe the cookie-sending engine makes the same wrong
assumption?

bcortez: You say you are probably not receiving cookies. Are those cookies
marked as "secure" cookies that might only be send over a secure connection?

In that case we might have found the problem, and we could start by using bht's
simple testcase, analyze and fix it, and see whether it fixes the applet problem.

bcortez: If you can, do you want to try to verify this suspicion, by temporarily
modifying your configuration, so that your cookies are non-secure cookies that
are allowed to be sent over unsecure connections, too?

Kai,

  You referred to "non-secure cookies", however, there are no such things as 
secure vs. non-secure cookies.  Cookies are cookies and should be sent with 
EVERY browser request regardless of it being a secure vs. non-secure 
connection.  That is the problem, the cookie is NOT being sent to the server by 
Mozilla as part of an SSL communication.


Actually, the cookies spec allows for the server to request that the cookie only
be  sent over an SSL connection.
ssaux, 

  I agree. I just wanted to clarify that there is no real distinction within 
the cookie itself between SSL and non-SSL transport.  It's the handlers that 
agree on when/where the cookie gets transmitted.  

As a side note, I am currently testing the Netscape 7.0 PR1 against one of our 
SSL servers to see if the cookie fixes in the Netscape branch fix this issue as 
a side-effect.  I'll keep this bug up-to-date on the outcome of these tests.  
If all goes well, I'll try to test the latest Mozilla build as well (sine that 
build is further along at this point).

Thanks for all of your input on this issue.... :)

> I just wanted to clarify that there is no real distinction within 
> the cookie itself between SSL and non-SSL transport.  It's the handlers that 
> agree on when/where the cookie gets transmitted.  

I still think there is such a thing as secure cookies.

Please have a look at:
  http://wp.netscape.com/newsref/std/cookie_spec.html

So, if your cookies do indeed have the "secure" attribute specified, Mozilla
will have remembered that.

And if indeed Mozilla makes the wrong assumption that the SSL POST connection is
non-secure, that would explain why the cookie is not sent back to you.
Chris Petersen is a new QA contact for oji component. His email is:
petersen@netscape.com
Assignee: joe.chou → petersen
fixing small error for pmac@netscape.com (filter with : SPAMMAILSUCKS)
Assignee: petersen → joe.chou
QA Contact: pmac → petersen
reassign to me
Assignee: joe.chou → joshua.xia
Reporter, does this happen on Linux or other platform?
Hi, Reporter:

Can you reproduce this bug by using appletviewer?
please try using "appletviewer
https://someHost/someWebRoot/html/HTTPSTestApplet.html"
if it also happen, it should not be browser's bug.
Status: NEW → ASSIGNED
It works on http,
the following display on my java console window:

Button click for: GET
URL is: http://baseman.prc.sun.com:8080/servlet/TestServlet
Got object type: java.util.Hashtable
Result is: This is the response for doGet - session ID: M5BlMQKSpOIKv0cguor

I think this should also works on https
->kyle
Assignee: joshua.xia → kyle.yuan
Status: ASSIGNED → NEW
Assignee: yuanyi21 → pete.zha
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
Product: Core → Core Graveyard
Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: