84550 - No load action when logging on secure page

Status: VERIFIED INVALID

(Core Graveyard :: Security: UI, defect)

Description

[wing-tung Leung]

(using CVS on GNU/Linux)
(I don't know much about HTTPS or SSL)

I have an developper account on http://www.sourceforge.net and I can log in to
the personal web (https://www.sourceforge.net) easily when I use M.9.

But if I use the current CVS version, clicking on "Log in" does not send out any
request to the server.

Some debug output:

Error loading URL https://sourceforge.net/account/login.php : 2152398899

Comment 1

[Fabian Guisset]

It seems like you've hit bug 83625. Since it has been fixed, could you please
re-try? Thanks!

Comment 2

[wing-tung Leung]

No I don't think it's a dup of 83625. I can't reproduce that error. And the
problem is still here using yesterday's CVS version.

It's rather strange: it doesn't matter how many times it click on the URL for
https://www.sourceforge.net/my , but the browser does not send out any request.

Comment 3

[wing-tung Leung]

(release 0.9.1 on GNU/Linux i386)

It seems that the browsers cannot load ANY secure HTTP pages. I have the same
problems at

http://www.offcolor.com/macaquarium5.htm

In the middle of the page there are several HTTPS links, none of them work. As I
said before, no request is sent out.

Comment 4

[Fabian Guisset]

the links you mentioned in your last comment worksforme build 2001061020 win2k.
Sorry can't help you there, you will have to wait for an answer from the
networking folks.

Comment 5

[[e-mail]]

+qawanted: another person w/ Linux...please confirm.

Comment 6

[eli_v]

Same problem on linux with build 2001061721

Comment 7

[wing-tung Leung]

I have tested this with 0.9.1 build on win98, with the same result. Click or
enter a HTTPS link and the browsers immediately responds with "Done", but does
not send out ANY request. No network activity at all.

The outgoing port 80 is blocked and users here are forced to use a proxy at port
8080, but all remaining outgoing ports are open, just like 443. Playing with all
possible proxy settings does not help.

If someone sends me some patches or explains how to trace down the problem in
the code, I'll be happy to accept.

Comment 8

[wing-tung Leung]

(using CVS version from a few days ago on GNU/Linux i386)

I managed to trace down the problem till nsSocketProvider::GetSocketProvider,
but progress is made very slow. I took my 128MB PC more than 30 minutes swapping
till I had a 23 level stacktrace. And it took me more than 3 hours overall to
get to this point.

If someone has some hints to speedup the debugging or idea's what to problem can
be, please let me know.

==
(gdb) n
nsSocketProviderService::GetSocketProvider (this=0x86b4f68,
    aSocketType=0x40c7ef4b "ssl", _result=0xbfffe93c)
    at nsSocketProviderService.cpp:96
96        if (NS_FAILED(rv))
(gdb) n
97            return NS_ERROR_UNKNOWN_SOCKET_TYPE;
(gdb) bt#0  nsSocketProviderService::GetSocketProvider (this=0x86b4f68,
    aSocketType=0x40c7ef4b "ssl", _result=0xbfffe93c)
    at nsSocketProviderService.cpp:97
#1  0x40bb0929 in nsSocketTransport::Init (this=0x869a800, aService=0x8158598,
    aHost=0x8691790 "www.sourceforge.net", aPort=443, aSocketTypeCount=1,
    aSocketTypes=0xbfffea7c, aProxyHost=0x0, aProxyPort=-1,
    bufferSegmentSize=4096, bufferMaxSize=16384) at nsSocketTransport.cpp:287
#2  0x40bb9415 in nsSocketTransportService::CreateTransportOfTypes (
    this=0x8158598, socketTypeCount=1, aSocketTypes=0xbfffea7c,
    aHost=0x8691790 "www.sourceforge.net", aPort=443, proxyHost=0x0,
    proxyPort=-1, bufferSegmentSize=4096, bufferMaxSize=16384,
    aResult=0xbfffea88) at nsSocketTransportService.cpp:550
#3  0x40c0410a in nsHttpConnection::CreateTransport (this=0x88543f8)
    at nsHttpConnection.cpp:453
#4  0x40c03a8b in nsHttpConnection::ActivateConnection (this=0x88543f8)
    at nsHttpConnection.cpp:339
#5  0x40c02f34 in nsHttpConnection::SetTransaction (this=0x88543f8,
    transaction=0x8777a50) at nsHttpConnection.cpp:124
#6  0x40bfd8ab in nsHttpHandler::InitiateTransaction_Locked (this=0x85d6b68,
    trans=0x8777a50, ci=0x87760e8, failIfBusy=0) at nsHttpHandler.cpp:724
#7  0x40bfc0ac in nsHttpHandler::InitiateTransaction (this=0x85d6b68,
    trans=0x8777a50, ci=0x87760e8, failIfBusy=0) at nsHttpHandler.cpp:369
#8  0x40c083ab in nsHttpChannel::Connect (this=0x8776038, firstTime=1)
    at nsHttpChannel.cpp:241
#9  0x40c0fedb in nsHttpChannel::AsyncOpen (this=0x8776038,
    listener=0x8826f60, context=0x0) at nsHttpChannel.cpp:1855
#10 0x40e0dab1 in nsDocumentOpenInfo::Open (this=0x8826f60,
    aChannel=0x8776038, aCommand=7, aWindowContext=0x84a8b70)
    at nsURILoader.cpp:184
#11 0x40e0f52d in nsURILoader::OpenURIVia (this=0x8172e08, channel=0x8776038,
    aCommand=7, aWindowContext=0x84a8b70, aLocalIP=0) at nsURILoader.cpp:521
#12 0x40e0f2aa in nsURILoader::OpenURI (this=0x8172e08, channel=0x8776038,
    aCommand=7, aWindowContext=0x84a8b70) at nsURILoader.cpp:482
#13 0x40ed5e86 in nsDocShell::DoChannelLoad (this=0x84a8b70,
    aChannel=0x8776038, aLoadCmd=7, aURILoader=0x8172e08)
    at nsDocShell.cpp:4720
#14 0x40ed5665 in nsDocShell::DoURILoad (this=0x84a8b70, aURI=0x864ee78,
    aReferrerURI=0x865bd20, aOwner=0x84b1928, aLoadCmd=7, aPostData=0x0,
    aHeadersData=0x0) at nsDocShell.cpp:4509
#15 0x40ed4689 in nsDocShell::InternalLoad (this=0x84a8b70, aURI=0x864ee78,
    aReferrer=0x865bd20, aOwner=0x0, aInheritOwner=1, aStopActiveDoc=0,
    aWindowTarget=0xbffff390, aPostData=0x0, aHeadersData=0x0,
    aLoadType=2097153, aSHEntry=0x0) at nsDocShell.cpp:4328
#16 0x40ee1291 in nsWebShell::HandleLinkClickEvent (this=0x84a8b70,
    aContent=0x864e920, aVerb=eLinkVerb_Replace, aURLSpec=0x864ef70,
    aTargetSpec=0x402909dc, aPostDataStream=0x0, aHeadersDataStream=0x0)
    at nsWebShell.cpp:831
#17 0x40f067ce in OnLinkClickEvent::HandleEvent (this=0x864ef28)
    at nsWebShell.cpp:677
#18 0x40ee0922 in HandlePLEvent (aEvent=0x864ef28) at nsWebShell.cpp:691
#19 0x401ee9c3 in PL_HandleEvent (self=0x864ef28) at plevent.c:590
#20 0x401ee7a0 in PL_ProcessPendingEvents (self=0x80b1d50) at plevent.c:520
#21 0x401f0d6c in nsEventQueueImpl::ProcessPendingEvents (this=0x80b1d28)
    at nsEventQueue.cpp:374
#22 0x409b2292 in event_processor_callback (data=0x80b1d28, source=7,
    condition=GDK_INPUT_READ) at nsAppShell.cpp:168
#23 0x409b1e18 in our_gdk_io_invoke (source=0x8176338, condition=G_IO_IN,
    data=0x81ac070) at nsAppShell.cpp:61
#24 0x4049c4ba in g_io_unix_dispatch (source_data=0x8176350,
    current_time=0xbffff624, user_data=0x81ac070) at giounix.c:135
#25 0x4049d9f6 in g_main_dispatch (dispatch_time=0xbffff624) at gmain.c:656
#26 0x4049dfb1 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#27 0x4049e129 in g_main_run () at gmain.c:884
#28 0x403b948a in gtk_main () at gtkmain.c:220
#29 0x409b2a2d in nsAppShell::Run (this=0x8122310) at nsAppShell.cpp:360
#30 0x40940f65 in nsAppShellService::Run (this=0x81026f0)

Comment 9

[David Bradley]

I'm getting this same problem on ess.aol.com. My build is from the trunk from
about 6/25 and I'm running Win2k. I'll do another pull and retest and report
back. I can probably get a better stack trace as well.

Comment 10

[David Bradley]

What I tracked this down to is that the contract ID
"@mozilla.org/network/socket;1?type=ssl" is not found in function
nsComponentManagerImpl::ContractIDToClassID, and returns kNoCID. I'll attach a
stack trace.

Comment 11

[David Bradley]

Attachment: Stack trace to nsComponentManagerImpl::ContractIDToClassID

Comment 12

[David Bradley]

I just did a build from CVS as of 4pm today, and still seeing the problem.

Comment 13

[Fabian Guisset]

over to security general, CC'ing neeti and dbradley so they don't lose track of
this bug. sounds like an easy fix, if it's really just a bogus contract id
Marking NEW.

Comment 14

[David Bradley]

FYI: I heard Mitch is out this week. Not sure when he's due back. This seems
like a fairly serious regression, so might want to seek more immediate
attention. Also for another simple site to test on, https://www.complient.com
(yes it's complient not compliant).

Comment 15

[John Unruh]

Changing to PSM. The 6/29 Linux commercial build works for me with SSL2, SSL3, 
and TLSv1 even through a proxy.

Comment 16

[wing-tung Leung]

Good news, I discovered the problem. HTTPS did not work because the PSM module
was not installed. I had chosen the custom install and deselected that module.

So, now it would be fine if the browser would give some usefull feedback about
the needed module, instead of jumping back without any alert message. Or maybe
even provide a direct install link to install the module.

Comment 17

[Stephane Saux]

PSM needs to be installed to work.
Marking invalid.

Comment 18

[John Unruh]

Verified.