235715 - gererally cannot establish an SSL connection (via squid proxy)

Status: RESOLVED DUPLICATE of bug 111384

(Firefox :: General, defect)

Description

[Paul Robertson]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

Windows 2k SP2.  Firefox 0.8

Clicking on an https:// link times out establishing an SSL connection for most
secure sites.

Oddly enough http://www.fortify.net's SSL check link works perfectly.
Even more oddly, Amazon.co.uk's checkout is mostly OK, but I get time-out errors
from ssl-images.amazon.com when it tries to render the images.

Mozilla 1.3 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
Gecko/20030312] is fine with same proxy set-up.

Proxy is Squid running on OpenBSD

Reproducible: Always
Steps to Reproduce:
1. go to http://www.lloydstsb.com
2. Click on "log on - personal account" in left hand box at top

Actual Results:  
Alert dialog reading "Error establishing an encrypted connection to
online.lloydstsb.co.uk, Error code -5990"
Click OK
Alert dialog reading "Operation timed out when attempting to contact
online.lloydstsh.co.uk"


Expected Results:  
It should go to the https log-in page

Default theme.
No crash.

Comment 1

[Paul Robertson]

*** Bug 235716 has been marked as a duplicate of this bug. ***

Comment 2

[Tomi Junnila]

(In reply to comment #0)

I'll have to add a me-too. Most https:// urls do not open and only result in the
two alert dialogs (actually, the dialogs are repeated a short while later even
if I don't try to open the same link again).

Netscape 7.0 works ok with the same proxy setup. I have no control or
information on the proxy used, it used to be a Netscape proxy but that was years
ago so it could have been changed.

The same steps as the original poster used reproduce the error. Also,
https://inetpankki.samlink.fi/pop results in the error, whereas
https://www.tuug.fi/ opens up without any problems.

Comment 3

[Tomi Junnila]

I found the cause for this (at least for me).

In my preferences, I had selected "Use OCSP to validate only certificates that
specify an OCSP service URL". After changing this to "Do not use OCSP for
certificate validation", all SSL URLs listed under this bug report started to
work (including the Lloyds one). I had already had the latter option selected in
Netscape.

Does Firefox try to access the CRL URL directly? That would explain why the
connections fail.

Comment 4

[Gavin Chappell]

> Does Firefox try to access the CRL URL directly? That would explain why the
> connections fail.
> 

Yes, it certainly appears to. If I have the "Use OCSP to validate only
certificates that specify an OCSP service URL" option selected, whenever I try
to open an https:// I get:

TCP    rogue:1398             12.166.243.30:http     SYN_SENT

in my netstat output, then it all flails and times out. Our campus firewalls
block incoming SYN/ACK packets from coming back, so the connection can never be
established.

Again, disabling OCSP altogether means I can surf secure websites as normal.

Comment 5

[Bruno Rohée]

I can fully confirm this bug too (Firefox 0.9.3/Win32). I cannot verify without
a proxy now but thru a proxy (squid, eitehr manual or automatic configuration)
activating OSCP verification makes most https sites fail. (self signed
certificates seems OK thought...).

Before I can do further checks without a proxy it seems that at least OCSP +
squid proxy is a big no no.

For the sake of helping people looking for the bug here the message I get (+
keyword SSL)

"Error establishing an encrypted connection to www.foobar.com. Error Code: -5990."

Comment 6

[Bruno Rohée]

Shouldn't this be labelled "OCSP validation doesn't honor proxy settings" and
moved to the PSM product? (checked that it is indeed the proxy causing problems).

I suggest clean-report and ecommece keywords too.

Someone with enough power, bug submitter?

Comment 7

[Josh Birnbaum]

It's a known limitation that OCSP and proxies don't mix.

*** This bug has been marked as a duplicate of 111384 ***