OCSP blocks HTTPS access from corporate LAN with NAT

VERIFIED DUPLICATE of bug 111384

Status

Core Graveyard
Security: UI
--
major
VERIFIED DUPLICATE of bug 111384
15 years ago
a year ago

People

(Reporter: George, Assigned: Darin Fisher)

Tracking

Other Branch
x86
Windows 98

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624

I am on a corporate LAN behind a firewall. The LAN uses NAT (network address
translation), and HTTP/HTTPS proxy to get out.

For some reason, I am unable to connect to SSL-encrypted sites, no matter what
the SSL settings are. Mozilla seems to try to connect for about 30s, then an
error message pops up saying "Error establishing secure connection to
"web.address.com". Error code: -5933". After another 30s or so the same message
pops up again. After dismissing the message window, I can use Mozilla to access
non-secure sites.

The same proxy works perfectly for HTTPS through another provider (no firewall
and NAT).

This problem is exhibited by 1.3 final and 1.4 final. It should be corrected in
1.4.1. The problem seems to be corrected in the latest daily, build 20030717.

One more strage thing: I have found one secure web page that I can access even
when I am unable to view anyting else through HTTPS. The address of the page is:

https://ibank.amsouth.com/Body/HTML_Workspace_DualSignOn.asp

It is the largest frame from the home page: "https://ibank.amsouth.com/". Now,
when I view this home page, the top and left side frames do not download because
of the error, but this largest one on the right does. Go figure!.....

Reproducible: Always

Steps to Reproduce:
1. Go to any secure web site. It will not work.
2.
3.
Not a trunk bug... (and I sort of doubt there will be a 1.4.1).
Version: Trunk → 1.4 Branch
Can you please disable OSCP in the Preferences (Privacy&Security/Validation) ?
(Reporter)

Comment 3

15 years ago
Matti,

Bingo, disabling OCSP verification in Validation solves the problem. However, it
would of course be nice to be able to use OCSP, and there should be no reason
for it not to work in a NAT environment.

However, when I first checked the latest daily build, of course, OCSP was also
disabled, and everything worked just fine. I have just checked it with OCSP
enabled, and, of course, it does not load secure sites. Thus it *IS* a trunk
bug, present in daily build 20030717.

In summary, the bug description is "OCSP validation does not work with NAT and
also blocks HTTPS access from working in a NAT environment."
Summary: No HTTPS access from corporate LAN using NAT → OCSP blocks HTTPS access from corporate LAN with NAT
(Reporter)

Comment 4

15 years ago
Changed version to Trunk bug.
Version: 1.4 Branch → Trunk
thanks

*** This bug has been marked as a duplicate of 111384 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Component: Networking: HTTP → Client Library
Product: Browser → PSM
QA Contact: httpqa → junruh
Resolution: --- → DUPLICATE
Version: Trunk → unspecified

Comment 6

15 years ago
V
Status: RESOLVED → VERIFIED

Updated

13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.