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)
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.
Comment 2•23 years ago
|
||
ssl proxy problem. Darin, you know anything about this?
Comment 4•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
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
Comment 7•23 years ago
|
||
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.
Comment 9•23 years ago
|
||
cc'ing PSM folks to get some help understanding this crash, etc.
Comment 10•23 years ago
|
||
I'm not at all familiar with the psm 1.x code, so I probably won't be much help.
Comment 11•23 years ago
|
||
KenW do you have the Talkback ID from the crash?
Comment 12•23 years ago
|
||
Is anyone still seeing this in recent builds? Much has changed at the socket level.
Keywords: qawanted
Reporter | ||
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
Thanks for the feedback! I'll be looking into this shortly.
Comment 15•23 years ago
|
||
I suspect there might be some problems (similar in nature to bug 31174) on the part of HTTP. Though I'm not really sure.
Assignee | ||
Updated•23 years ago
|
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.0
Comment 17•23 years ago
|
||
Is this still a problem with the most recent builds (using PSM2)?
Target Milestone: --- → 2.0
Reporter | ||
Comment 18•23 years ago
|
||
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
Comment 19•23 years ago
|
||
A bug in CONNECT was fixed over the weekend. Please try a 4/30 or later build.
Reporter | ||
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
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.
Comment 22•23 years ago
|
||
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
Reporter | ||
Comment 23•23 years ago
|
||
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.
Comment 24•23 years ago
|
||
much changed for 0.9.1 ... i'd bet this was fixed on our end.
Comment 25•23 years ago
|
||
Marking worksforme. The download speed through a proxy now appears very quick.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 26•23 years ago
|
||
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
Comment 27•15 years ago
|
||
VERIFIED WORKSFORME for almost 8 years. Removing QAWANTED.
Keywords: qawanted
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•