Closed Bug 70209 Opened 23 years ago Closed 23 years ago

ssl via tunneling proxy horribly slow, fails to load completely, displays junk

Categories

(Core Graveyard :: Security: UI, defect, P3)

1.0 Branch
x86
Windows 95
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME
Future

People

(Reporter: ken_warkentyne, Assigned: ddrinan0264)

Details

(Keywords: perf)

When I try to access https://www.verisign.com with build 2001022209 via a 
tunneling proxy (Raptor), the page never finishes loading and the top of the 
browser window displays what looks like the HTTP reply headers:

"Server: Netscape-Enterprise/3.6 SP2 Date: Mon, 26 Feb 2001 17:56:36 GMT 
Content-type: text/html Connection: close"

At least it doesn't crash the app or my PC anymore.
sending to networking, CC'ing dougt
Component: Browser-General → Networking
ssl proxy problem.   Darin, you know anything about this?
I'll look into this.
Assignee: asa → darin
this could be remedied in recent builds. Isn't this the kind of problem we were
seeing in bug 31174 before the dougt branch landed?
I downloaded build 2001022605 (via build bar at Mozillazine) and the problem 
still exists. One small difference, after trying to download 
https://www.verisign.com for a while, PSM crashes but the browser continues to 
work and I can browser non-secure pages.
I think the PSM folks should look into this.  Regardless of what mozilla does,
PSM shouldn't be crashing.
Assignee: darin → mstoltz
Component: Networking → Security: General
QA Contact: doronr → ckritzer
I agree. However, I am not the PSM folks. Reassigning.
Assignee: mstoltz → ddrinan
Component: Security: General → Security: Crypto
QA Contact: ckritzer → junruh
More info: TLS is turned off as per the comments in bug 31174. When the PSM
crashes, I get the little Windows alert box containing the following debug info:

PSM caused an invalid page fault in
module MSVCRT.DLL at 0137:7800d560.
Registers:
EAX=00700078 CS=0137 EIP=7800d560 EFLGS=00010246
EBX=0080000c SS=013f ESP=00effe4c EBP=00effe6c
ECX=30000000 DS=013f ESI=ffffffff FS=0dd7
EDX=008caa7c ES=013f EDI=008c88c0 GS=0f6e
Bytes at CS:EIP:
89 79 08 0f 84 15 01 00 00 8b 4d f4 8b 7c f1 04 
Stack dump:
0000000c 00000010 00000000 816d7560 00000020 00703018 00000000 00000017 00effeac
7800ce77 0080000c 008caa80 00000000 008af4c0 7800ef03 7802e248 

However, the fact that PSM eventually crashed may or may not be related to the
original problem.
cc'ing PSM folks to get some help understanding this crash, etc.
I'm not at all familiar with the psm 1.x code, so I probably won't be much help.
KenW do you have the Talkback ID from the crash?
Is anyone still seeing this in recent builds?  Much has changed at the socket
level.
Keywords: qawanted
Keyser Sosez: The crash didn't seem to generate a "talkback" (even if it 
did, talkback doesn't seem to work through our corporate firewall).

Darin Fisher: I downloaded the March 12th nightly via the link at Mozillazine 
and tried it again. This time, hitting the stop button doesn't crash PSM. 
However, the original bug report stands. A few slight behavioural changes: the 
HTML loads much faster but still has HTTP header garbage at the top, the images 
don't seem to load at all (I haven't waited more than a couple of minutes). I 
have tried the same build from my home PC, which connects directly to the 
Internet, and it works fine with exactly the same URL.
Thanks for the feedback!  I'll be looking into this shortly.
I suspect there might be some problems (similar in nature to bug 31174) on the
part of HTTP.  Though I'm not really sure.
Setting to new and qawanted.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.0
Is this still a problem with the most recent builds (using PSM2)?
Target Milestone: --- → 2.0
I just tried out a build from April 27 (see below) and ran into a (new?) problem 
with the proxy authentication. When accessing an internal secure site, Moz is 
pretty snappy. Here's a blow by blow description of what happens when I try to 
go outside the firewall:

1. Try www.verisign.com (http, not https). Get prompted for user id and pw, page 
loads fine.

2. Try https://www.versisign.com. Get prompted again for user id and pw (should 
not happen). Error page from firewall loads. This is the error page that gets 
displayed if I try to access the firewall itself as a web site. The firewall is 
an old Raptor firewall that uses the CONNECT protocol to establish an SSL 
tunnel.

Of note: We are on a very secure internal network. There is no access to the 
outside except through the firewall; the internal DNS does not resolve any 
external addresses. Would it be possible for a group of engineers to set up and 
work within a special network zone that mimics this setup, which is pretty 
standard for security conscious/paranoid corporations? I think this would be a 
big help in identifying the source of the problem.

Overall, the browser seems to be rounding in to pretty good shape, which makes 
this particular bug very frustrating!

Version: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.8.1+) Gecko/20010427
A bug in CONNECT was fixed over the weekend.  Please try a 4/30 or later build.
Okay, tried out the latest win32 nightly (2001043004) and we're partially back 
to the original problem. The difference is that the page loads quite fast but 
the images are still missing and there is still HTTP header junk displayed at 
the top of the page. We also still have the problem with the browser asking for 
the firewall password a second time.

From trying to look at the images (using the very nice 'page info' interface), 
it looks like the HTTP header junk is also getting mixed up with the image 
content, which would explain why they aren't being displayed.
Possible dumb question:

Is there any reason people think this is a PSM and not a Necko problems?

This is important becase if this is Necko related, it needs to be nominated and
targeted for mozilla 0.9.1.

Asa had mentioned to me that m0.8.1 would ship with serious performance problems
in necko, regarding HTTPS via SSL proxy.



Bug only exists in very specific environment which we can't replicate easily,
retargeting to future.
It's also possible that it's a necko bug.  Anybody from the necko team want to help?
-> future
-> p3 
Priority: -- → P3
Target Milestone: 2.0 → Future
My company just upgraded our firewall proxy and the problem has gone away (or
maybe 0.9.1 did something to fix it). It is still a bit worrying that IE, NN4,
and Lynx had no problem with the old firewall and I'm still attempting to
analyze the difference. However, the issue has lost its urgency. 
much changed for 0.9.1 ... i'd bet this was fixed on our end.
Marking worksforme. The download speed through a proxy now appears very quick.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Verified worksforme. https://junruh/knox/color/color.html takes 3.5 seconds
through a proxy and 2.5 seconds without a proxy. Tha page has 100 small gif files.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.0 → 1.0 Branch
VERIFIED WORKSFORME for almost 8 years.  Removing QAWANTED.
Keywords: qawanted
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.