Closed
Bug 213028
Opened 22 years ago
Closed 22 years ago
OCSP blocks HTTPS access from corporate LAN with NAT
Categories
(Core Graveyard :: Security: UI, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 111384
People
(Reporter: wsz1w0d02, Assigned: darin.moz)
References
()
Details
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.
Comment 1•22 years ago
|
||
Not a trunk bug... (and I sort of doubt there will be a 1.4.1).
Version: Trunk → 1.4 Branch
Comment 2•22 years ago
|
||
Can you please disable OSCP in the Preferences (Privacy&Security/Validation) ?
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
Comment 5•22 years ago
|
||
thanks
*** This bug has been marked as a duplicate of 111384 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Component: Networking: HTTP → Client Library
Product: Browser → PSM
QA Contact: httpqa → junruh
Resolution: --- → DUPLICATE
Version: Trunk → unspecified
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
•