Closed Bug 92742 Opened 23 years ago Closed 22 years ago

Proxy: SSL problems via Squid

Categories

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

Other Branch
x86
Linux

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 149868
Future

People

(Reporter: ltskinol, Assigned: javi)

References

()

Details

(Keywords: qawanted, regression)

Attachments

(1 file)

Linux, 2001072906

_Some_ SSL pages don't work through the Squid proxy.

To reproduce:

1. Install Squid proxy (I'm using Mandrake 8.0 - it's on CD1)
2. Configure Mozilla to use "localhost" port 3128 for HTTP, FTP
and SSL.  Leave others blank.
3. Browse to listed URL.  

Result: blank page, except for HTML skeleton body (html, body,
slash body, slash html).

Note: this seemed like a dupe of bug 52824 (which is a duplicate
of bug 31174), except that that test URL 
(https://www.fortify.net/sslcheck.html) works, while mine doesn't.
confirming. -> http

relevant log bits:
....
1026[8105918]: http response [
HTTP/1.0 200 Connection established
]
1026[8105918]: nsHttpConnection::OnHeadersAvailable [this=8807498
trans=89e8970]1026[8105918]: SSL proxy CONNECT succeeded!
1026[8105918]: nsHttpConnection::ProxyStepUp [this=8807498]
1026[8105918]: resetting transaction's response head
1026[8105918]: nsHttpResponseHead::Reset
1026[8105918]: nsHttpTransaction: listener returned [rv=0]
1026[8105918]: mTransaction->OnDataReadable() returned [rv=0]
1026[8105918]: nsHttpConnection::OnDataAvailable [this=8807498]
1026[8105918]: nsHttpTransaction::OnDataReadable [this=89e8970]
1026[8105918]: nsHttpTransaction::Read [this=89e8970 count=4096]
1026[8105918]: mSource->Read [rv=80004005 count=4096 countRead=0]
1026[8105918]: nsHttpTransaction: mSource->Read() returned [rv=80004005]
1026[8105918]: nsHttpTransaction: listener returned [rv=80004005]
1026[8105918]: mTransaction->OnDataReadable() returned [rv=80004005]

... and we return NS_ERROR_FAILURE.

works on the comm branch bits, so this is a regression
Assignee: asa → darin
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
Keywords: regression
QA Contact: doronr → benc
I have a similar setup and I can't reproduce all of this. I can reach
Fortify's site with no problem. Mozilla even pops up a dialog telling me
that Fortify's site certificate has expired. The squid logs show a
successful CONNECT request.

The hercules site does fail for me. Squid's logs show that the 
connection is only open for a few milliseconds. This usually means the 
server has an issue with TLS1. I tried OpenSSL's s_client and this, 
indeed, seems to be the case.

Not really a network problem.
bbaetz: does this problem happen w/ a direct connection?
Whiteboard: DO NOT DUPE
no - it works fine when going direct.
tenthumbs: You have the same problem as I - Fortify's site works,
hercules does not.

Benjamin: No proxy works for me as well.  Only if I use squid do I 
have a problem.
This seems related to what I have been seeing.
I've reported the behavior under bug 88792 , although I'm not sure that is the
right place.
With the Windows 2001073103 trunk build I could not get to
https://www.accountonline.com/CB/Login.jsp  This is the website for account
servicing of Citibank credit cards.   It is a high volume site with millions of
registered users.   I get the <HTML><BODY></BODY></HTML> response.

As of the Windows 2001080303 trunk build I cannot get to any secure sites. I
enter the URL in the URL bar, the throbber throbs, stops throbbing and nothing
changes.  The previously displayed page is still there.
qawanted - flagged as problem that needs definition.
clarified summary
okay, is this now a trunk & branch concern?
bradley, do you have squid already or should I make time to load it?
Keywords: qawanted
Summary: SSL sometimes doesn't work with Squid proxy → Proxy: SSL problems via Squid
I have squid set up, and I did confirm this originally. darin, any ideas?

Does this work without a proxy?
-> moz0.9.4
Severity: normal → major
Priority: -- → P2
Target Milestone: --- → mozilla0.9.4
this looks like a PSM bug to me.  after the ProxyStepUp, our next call to
PR_Read returns an error (PR_GetError gives 0xffffe8ce), which doesn't seem to
be a standard NSPR error.

-> PSM
Assignee: darin → ssaux
Component: Networking: HTTP → Client Library
Product: Browser → PSM
QA Contact: benc → ckritzer
Target Milestone: mozilla0.9.4 → ---
Version: other → unspecified
Can we configure the client to use SQUID like a proxy (i.e., without having it
installed locally)  We don't have the proper set up to qa.
P3
->future.
->javi
Assignee: ssaux → javi
Priority: P2 → P3
Target Milestone: --- → Future
it seems really wrong to future this bug since it is only a very recent
regression.  what has changed?  why would PSM be reporting this error?  what
does it even mean?
Um, future? You can't break proxy usage for https sites and mark it future.

Inside the firewall, you can point your browser at 208.12.38.206:3128 for an
open squid proxy. (Thats my linux box. Its a DHCP assigned address, but it
hasn't changed since the last power outage)

This is not a problem on the branch - something changed since then.
Keywords: mozilla0.9.4
QA Contact: ckritzer → junruh
Another site that this fails on is https://www.nmefcu.org/onlineserv/HB/Signon.cgi

using Mozilla 0.9.6
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

This is going through a squid proxy on our firewall.
Another site that this fails on is https://www.nmefcu.org/onlineserv/HB/Signon.cgi

using Mozilla 0.9.6
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

This is going through a squid proxy on our firewall.
*** Bug 123778 has been marked as a duplicate of this bug. ***
nsbeta1
Keywords: nsbeta1
Keywords: nsbeta1nsbeta1-
*** Bug 136155 has been marked as a duplicate of this bug. ***
Depends on: 149868
The patch in bug 149868 seems to help.

Without the patch, the connection to the site seems to be stale.

With the patch, I'm able to connect, but there seems to be problem with the
content on the site.

However, I suspect, that it is because the site changed, and the patch in bug
149868 would make it work correctly, if the site had correct content.
*** Bug 150816 has been marked as a duplicate of this bug. ***
Resolving as a duplicate, because I believe this is now fixed.
If you still can reproduce, please reopen.


*** This bug has been marked as a duplicate of 149868 ***
Status: NEW → RESOLVED
Closed: 22 years ago
No longer depends on: 149868
Resolution: --- → DUPLICATE
Whiteboard: DO NOT DUPE
Verified dupe.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: