Open Bug 98203 Opened 23 years ago Updated 3 years ago

Timeout during SSL handshake causes about: blank to be displayed

Categories

(Core :: Networking, defect, P5)

Product:
Core
Component:
Networking
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

People

(Reporter: cfu, Unassigned)

References

(
URL
)

Details

(Whiteboard: [PDT-], [necko-backlog]) 

I have a CMS4.2 sp2.  When I point my Netscape6 2001083003 at the agent url, and
signed in as an agent, the first page I see is always
"<html><body></body></html>".  After reload, it's ok.
Assignee: ssaux → rangansen
Priority: -- → P1
Target Milestone: --- → 2.1
setting to P1, t->2.1

maybe the same problem as 97997
Keywords: nsenterprise
Marking nsentreprise+
Keywords: nsenterprise → nsenterprise+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbranch+
Group: netscapeconfidential?
I trust this is some kind of server timeout problem. We get a
PR_CONNECT_RESET_ERROR whenever the problem shows up, implying the server quits
the connection[probably times out].  
Sounds a bit weired, but this is what I observed:
When I Try to visit a ssl enable cms server url [https://cfu:8100, for example]
I am propmted for my certificate. If I select the certificate and put in thec
password etc fast enough, things go ok. But if I wait for more that a minute, or
so, I get . This can be almost always reproduced using Netscape 6, as well as
communicator 4.7.
Looks like this might be a cms server related bug. Also, I could not find any
way to set the timeout in the cms server.
cfu: what are your views on this issue?
Also, including Stephane in the cc list.

Okay, so this is resolved - this was a timeout problem - default timeout on cms
server, I was told, was set to 15 sec by default.

But this still leaves another problem - when connection snaps during the data
exchange, the page should not show "<html><body></body></html>" as it does now -
this would be wrong as this  data was never received. Communicator used to show
a dialog box indicating a network error. We should have something like that, or
may be a error page, showing the error details etc.

This happens in number of other places, but this particular bug would provide a
good ready-made test case. So, I am changing the summary of this bug as
relevant, and assigning this to network module.
Assignee: rangansen → neeti
Component: Client Library → Networking: HTTP
Product: PSM → Browser
QA Contact: bsharma → tever
Summary: no body in page after ssl client auth → Page does not display proper info when http connection snaps midway
Target Milestone: 2.1 → M1
Version: 2.0 → other
Whiteboard: <html><body></body></html> bug
gagan
Assignee: neeti → gagan
Whiteboard: <html><body></body></html> bug → PDT <html><body></body></html> bug
-->darin
Assignee: gagan → darin
This does not look like a stop ship from the enterprise perspective.  Marking
nsenterprise-.
Keywords: nsenterprise+ → nsenterprise-
Darin - What's the status on this one?
-> mozilla 0.9.5 ... i have yet to investigate this bug.
Target Milestone: M1 → mozilla0.9.5
Gagan - Can you take a look at this one? It looks pretty serious, and we'd like
this one in ... Pls come to the PDT tomorrow @ noon to discuss the progress on
this bug.
Severity: normal → critical
we need a testcase for this bug... can someone provide a testcase?  it's
possible that my fix for bug 97997 will fix this as well, but without a
testcase, i cannot be certain.
0. get a new profile
1. go to http://cfu [Enrollment][Directory], enter uid "teest1" and password
"test1" [Submit] (now you got yourself a cert
2. make sure the ca is trusted in your certificate manager.
3. visit https://cfu:8100, you'll be presented with the ssl client auth cert
selection.  Don't do anything, just sit there and wait for over 1 minute.

After that minute+, just select the cert and "ok" (you might be asked to log
into your software token, if you haven't done so before), you'll see it.
christina: can you verify the problem with a 9/21 build?
Darin: I was able to get a <html><body></body></html> page using today's branch
build. If you want me to try other builds, ask me. Christina's running full
functional test on an earlier build.

Notes:
- Configure to have your browser to "Ask everytime" for client auth cert
selection (pref->priv&sec->certificates)

- The user for the directory enrollment is test1/test1. Christina's comment had
a typo.

- Once you have the cert, it's sufficient to go directly to https://cfu:8100.
If you get an Unauthorized access (what should happen if the bug wasn't there)
and reloading the page always gives you that, you can get out of it by doing
task->priv&sec->pwd mng->log out.

- Finally, just in case this isn't specified the unexpected result occurs when
the server reaches it's configured timeout to complete the full handshake
including the client auth.

ssaux: thanks for the feedback... i'll try to investigate this problem on monday.
Status: NEW → ASSIGNED
status pls ... we'd like this one.
Whiteboard: PDT <html><body></body></html> bug → [PDT], <html><body></body></html> bug
Since this says we behave identically to 4.x, and there are no serious
consequences of the error, why is this P1 critical?  I understand the desire to
have a good error message, but is this a situation that millions of people are
going to run into?
it's unclear at this point how many consumers would be effected by this bug, but
i suspect that it is not that many.  however, if this is not a problem with IE,
then it would just be additional encouragement for a user to not use ns/mozilla.

i'll have some more comments later tonight.
Whiteboard: [PDT], <html><body></body></html> bug → [PDT], <html><body></body></html> bug, [ETA ?]
I've seen this one on occassion on www.techcu.com
URL: www.techcu.com
ok, i've reproduced this bug... it is very easily reproducible.  however, i
suspect the fix will be very involved.  the problem is that we have already read
some data from the socket, when suddenly a call to PR_Read returns 0xffffe8d8 or
PR_CONNECT_ABORTED_ERROR.  i don't understand why the server chooses to abort
the connection part way through, but i suspect that it means that we should not
be blocking the connection with a UI dialog.  making the dialog non-modal is
probably not easy... ssaux: your thoughts?
FWIW, IE5.5 doesn't seem to have this problem
The test case involving the client auth is not in my opinion dependend on
whether or not the various dialogs (master pwd, cert chooser) are modal or not.

During the SSL handshake with client auth, the server and the client have sent
each other strings of random bytes, and the server has requested that the client
sign a massaged version of this data with a client private key that matches the
CA/purpose listed in the server request. At this point, the client presents the
user with the choices of matching certs/keys.  Once the selection is complete,
the signing operation takes place, and the signed data plus the certificate
chain corresponding to the private key used to sign the data is sent to the server.

The connection snap occurs between the time the server request is received and
the time the signed data/certificate chain is sent.  I don't see a way in which
the modality of the various dialog could affect the outcome.

cc ddrinan.

When you say that it works with I.E., do you mean the client auth test case
(cfu:8100, with a cert select dialog which allows the timeout to be reached)?

Finally, in the case of the cfu:8100 site, the server snaps the connection as a
matter of policy (no data received before before timeout delay).


ssaux: with IE is repeated the exact same test steps outlined above:

1- got a cert
2- went to https://cfu:8100/
3- got a select dialog
4- waited several minutes
5- got the "Unauthorized access" page

(not sure how to duplicate the "Ask Everytime" mozilla preference in IE, or even
if it is essential to this bug)

i understand your point about modal dialogs vs. non-modal dialogs.  no matter
what we have to wait for the user's input, and it seems that once we exceed some
threshold delay, the server times out.  so, then how do we recover from this
timeout?  can we in fact recover from it?  i'm not sure we can since the socket
transport has already read data... would it really make sense to restart the
HTTPS transaction on a new connection?  wouldn't that go through the same cert
select dialog fu?
what are the chances this will make the 0.9.4 branch?
probably not, since we don't really have any idea how to solve the problem yet.
*sigh* ok ... keep working on it, and let us know of any good news. i think it
would be a  good thing to have for the release. thanks ...

p.s. - this is not a regression, right? did 0.9.2 and 0.9.2 ship with this?
i don't think this is a regression.  in fact, the problem exists with netscape
4x as well.  only IE seems to handle this problem correctly.
PDT-, since this will not make the branch.
Whiteboard: [PDT], <html><body></body></html> bug, [ETA ?] → [PDT-], <html><body></body></html> bug, [ETA ?]
-> mozilla 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
The <html><body></body></html> problem is also bug 102737.
I'm hoping to find time to help develop a solution sometime in the mozilla 0.9.8
timeframe.
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Blocks: 107066
Keywords: nsbranch+
cc'ing evangelist to see if they have heard of this stuff happening in the wild
for this or other related bugs mentioned.
we use extensively Cocoon as a content manager.
and we have this error very very often. somthing like once each minute or so.

no reproductible thing, but very annoying.

as said in the previous comments, IE does handle the problem flawless.
i'm not sure anything can be done about this in the mozilla1.0 timeframe.  seems
like a major architectural change to avoid connection timeouts when modal
dialogs  are left unattended.

-> future
Severity: critical → major
Priority: P1 → P2
Target Milestone: mozilla0.9.8 → Future
Keywords: nsbeta1
gonna go ahead and nsbeta1- this one per darin's comments.
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [PDT-], <html><body></body></html> bug, [ETA ?] → [PDT-], <html><body></body></html> bug
No longer blocks: 107066
updated summary...
Summary: Page does not display proper info when http connection snaps midway → Timeout during SSL handshake causes about: blank to be displayed
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Component: Networking: HTTP → Networking
QA Contact: tever → networking
Target Milestone: Future → ---
Whiteboard: [PDT-], <html><body></body></html> bug → [PDT-], [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P2 → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: major → S4
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.