Closed Bug 17697 Opened 25 years ago Closed 25 years ago

[BETA] No warning when mozilla can't find https

Categories

(Core :: Security, defect, P2)

Product:
Core
Component:
Security
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: junruh, Assigned: jud)

References

Details

1.) Install the export version of PSM.
2.) Attempt to connect to https://junruh:1449/ncryptsvr.htm - a server running
only a RC4-128 bit cipher.
What is expected: A dialog box stating "Netscape and this server cannot
communicate securely because they have no common encryption algorithm(s)"
What I get: No warnings, the site simply doesn't connect.
Blocks: 13785
Actually, there seems to be a dearth of any kind of alert dialog boxes.
No indication is given for DNS failure or connection failure either.
It is possible that alerts in general are simply not working yet -
if that's the case, then this report is waiting on that before it
will be possible to test if the security alert described is not appearing,
or if the problem is only that *no* alerts are appearing.
Can't we get an inline error in the layout widget?  Dialog boxes are just so
interrupting.
marking as m12.
QA Contact: dshea → junruh
Changed qa contact to junuh@netscape.com
Assignee: dougt → warren
Status: ASSIGNED → NEW
Warren mentioned that unknown and/or unsupported protocols would be handled by
the webshell (?).  He may know who is working on this, or have an idea who
should work on this.  I am reassigning to him.
Assignee: warren → valeski
Summary: No warning when mozilla can't connect to high-encryption site → No warning when mozilla can't find protocol
I thought there was a bug for this, but now I don't see it. Jud was handing
this sort of thing.

Changing summary from: No warning when mozilla can't connect to high-encryption
site
to: No warning when mozilla can't find protocol
Status: NEW → ASSIGNED
Depends on: 13374
the webshell redesign has pushed all these front-end/back-end tie in bugs off.
In today's world the webshell would through a dailog when it couldnt' create the
url (note: it doesn't do this right now), but I"m not sure how this is handled
in the new world.
Moving what's not done for M12 to M13.
*** Bug 21336 has been marked as a duplicate of this bug. ***
*** Bug 20970 has been marked as a duplicate of this bug. ***
OS: Windows NT → All
Priority: P3 → P2
Hardware: PC → All
Summary: No warning when mozilla can't find protocol → [BETA] No warning when mozilla can't find protocol
*** Bug 22637 has been marked as a duplicate of this bug. ***
*** Bug 22831 has been marked as a duplicate of this bug. ***
*** Bug 22587 has been marked as a duplicate of this bug. ***
*** Bug 22806 has been marked as a duplicate of this bug. ***
*** Bug 23108 has been marked as a duplicate of this bug. ***
*** Bug 23511 has been marked as a duplicate of this bug. ***
Summary: [BETA] No warning when mozilla can't find protocol → [BETA] No warning when mozilla can't find protocol, e.g. SSL
Adding "e.g. SSL" to Summary to facilitate searching (since most of the dups
and use cases of this bug are for lack of SSL in the mozilla.org binary bits).
Summary: [BETA] No warning when mozilla can't find protocol, e.g. SSL → [BETA] No warning when mozilla can't find https
if we can't find a registered protocol, we assume http (thus we "never" can't
find a protocol). This bug is really about SSL. Changing summary from "[BETA] No
warning when mozilla can't find protocol, e.g. SSL".
I think we're going to have to special case "https".
if I type foobar:// into the url, I would like to get a page that tell me I do
not know what the hell I am talking about.  Is this something which we can do?
I think that assuming http is wrong.  (yes defaulting is what 4x did).
I have part of this fix.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fix checked in 01/12/00 2:55pm pac time.
*** Bug 24207 has been marked as a duplicate of this bug. ***
On WinNT, an alert comes up front and center every time warning that
"https is not a registered protocol". The same alert appears on Linux, 
but often over on another virtual desktop, where it would not necessarily be 
seen. This last is probably another bug entirely, one that I think has been
reported, but it may prevent verification on Linux so long as it exists.

I can't be sure, but when the Mozilla window is in one of the rightmost 
"screens" of a 2x2 desktop, the modal alert dialog may appear "offscreen"
where it cannot be dismissed, making Mozilla unresponsive and requiring the 
user to kill the task. In any case, Mozilla did freeze more than once while 
testing this on Linux, while other times it worked exactly as NT did.

Tested with:
2000-01-22-08-M14 nightly binary on Windows NT 4.0sp3
2000-01-22-09-M14 nightly binary on Linux custom Slackware 4.0, fvwm2

Reopening - there are still no security warnings. 
1.) Connect to https://junruh.mcom.com:3002/ciphers.html
2.) You will not be able to connect, but are given no warning that you cannot.
3.) Connect to http://omen, then https://omen.
4.) Note that you are not warned that you are entering a secure site.
Status: RESOLVED → REOPENED
please file a new bug and assign it to dougt. this one is closed.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Verified - opened bug 24901.
Status: RESOLVED → VERIFIED
No longer blocks: 13785
*** Bug 22743 has been marked as a duplicate of this bug. ***
*** Bug 26544 has been marked as a duplicate of this bug. ***
*** Bug 26801 has been marked as a duplicate of this bug. ***
Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.
Component: Security → Security: General
*** Bug 24512 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.