Closed
Bug 196827
Opened 22 years ago
Closed 22 years ago
it says that site is secure when it isn't because the connection was canceled
Categories
(Core Graveyard :: Security: UI, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
psm2.4
People
(Reporter: bugzilla, Assigned: KaiE)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [adt1])
Attachments
(2 files)
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
KaiE
:
review+
jag+mozilla
:
superreview+
asa
:
approval1.4b+
|
Details | Diff | Splinter Review |
try this: 1) go to http://gemal.dk 2) after this paste this into the Location https://secure.tdconline.dk/certifikat/phpinfo.php and press Enter 3) now press the Security Info in the lower right corner. It says that gemal.dk is secure!
Reporter | ||
Comment 1•22 years ago
|
||
Indeed, trick works on other sites as well. Is this a Mozilla issue or the phpinfo.php page? Either way, a page shouldn't be allowed to trick the browser into saying it's secure.
Reporter | ||
Comment 4•22 years ago
|
||
the problem is not the php script. The problem is that if you cancel a https connection Mozilla still shows the secure icon in the lower right corner indicating you're at a secure site. if you click the secure icon pageinfo just gets the current loaded URL (gemal.dk) and shows that. Mozilla should remove the secure icon if the user cancels the secure connection In details: 1) you go to http://gemal.dk 2) you enter https://secure.tdconline.dk/certifikat/phpinfo.php in the Location and press enter. 3) the phpinfo is a script that requires the browser to present a certificate. So the Mozilla select certificate dialog pops up (if you set the ask every time pref) and then you press CANCEL. This terminates the secure connection of secure.tdconline.dk. But Mozilla still shows the secure icon. Now it looks like the current site gemal.dk is secure and even pageinfo says so.
Comment 5•22 years ago
|
||
one doesn´t even need the php-file, going to https://secure.tdconline.dk/certifikat/ is enough for this to happen. I can see this on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030310 (1.3 RC) but not on Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.3a) Gecko/20021207 Phoenix/0.5 (last official phoenix release) Perhaps you should mark it blocking 1.3, since that could be some serious security issue and should be fixed before releasing Mozilla 1.3
Reporter | ||
Updated•22 years ago
|
OS: Windows XP → All
Summary: it says that site is secure when it isn't → it says that site is secure when it isn't due to connection dont load
Comment 7•22 years ago
|
||
Mozilla 1.2.1 (last official release) isn´t affected, so the regression occured after opening the 1.3a trunk
Flags: blocking1.3+
Comment 9•22 years ago
|
||
PSM. Bruno, you are NOT someone who can usefully mark bugs as blocking a release, last I checked. You can set the flag to a request to consider the bug as blocking a release.
Assignee: mstoltz → ssaux
Severity: normal → critical
Component: Security: General → Client Library
Flags: blocking1.3+ → blocking1.3?
Product: Browser → PSM
QA Contact: carosendahl → junruh
Version: Trunk → 2.4
Comment 10•22 years ago
|
||
uh, sorry Boris. I wanted to set it to ? but apparently I was too confused and choose +. Will have better look next time.
Updated•22 years ago
|
Flags: blocking1.4a?
Keywords: nsbeta1,
regression
Summary: it says that site is secure when it isn't due to connection dont load → it says that site is secure when it isn't due to connection don't load
Updated•22 years ago
|
QA Contact: junruh → bmartin
Updated•22 years ago
|
Flags: blocking1.4a?
Flags: blocking1.4a-
Flags: blocking1.3?
Assignee | ||
Comment 11•22 years ago
|
||
I can confirm this bug. Sounds pretty bad. I could not reach your test https site, but have created a new one. So here is what you do: - go to www.kuix.de/ca/ns.php and trust the cert for web site certs This is to make the demonstration nicer. Do this with a new profile if you don't want to trust me, you should not :-) - start mozilla - go to mozilla.org home page - go to https://www.kuix.de/misc/test196827 - no new content gets loaded, mozilla.org page still shown, but is reported as being insecure.
Assignee | ||
Comment 12•22 years ago
|
||
I confirm it is a regression. Mozilla 1.0 up to 1.2 behave correctly and do not switch the lock icon to secure. Mozilla 1.3 and later incorrectly change the lock icon to secure.
Priority: -- → P1
Target Milestone: --- → 2.4
Assignee | ||
Updated•22 years ago
|
Updated•22 years ago
|
Flags: blocking1.4b? → blocking1.4b+
Updated•22 years ago
|
Flags: blocking1.4?
Summary: it says that site is secure when it isn't due to connection don't load → it says that site is secure when it isn't because the connection was canceled
Assignee | ||
Comment 15•22 years ago
|
||
The cause of this bug is a different behaviour in the notifications the web progress listener sends out. I traced and saw the following is different between 1.0 and latest trunk: Although there is the failure at the SSL layer, and although no application bytes are being transfered, the web progress listener sends out the STATE_TRANSFERING notification. This flag is used by the lock icon tracking code to make the decision, whether the lock icon should get updated or not. When talking to Darin, he quickly had the right idea what is causing this new behaviour. Darin gave me a patch that fixes the problem!
Assignee | ||
Comment 17•22 years ago
|
||
Comment on attachment 121976 [details] [diff] [review] Patch v1 r=kaie
Attachment #121976 -
Flags: review+
Comment 18•22 years ago
|
||
Comment on attachment 121976 [details] [diff] [review] Patch v1 sr=jag
Attachment #121976 -
Flags: superreview+
Assignee | ||
Updated•22 years ago
|
Attachment #121976 -
Flags: approval1.4b+
Assignee | ||
Updated•22 years ago
|
Attachment #121976 -
Flags: approval1.4b?
Assignee | ||
Updated•22 years ago
|
Attachment #121976 -
Flags: approval1.4b+
Comment 19•22 years ago
|
||
Comment on attachment 121976 [details] [diff] [review] Patch v1 a=asa (on behalf of drivers) for checkin to 1.4b
Attachment #121976 -
Flags: approval1.4b? → approval1.4b+
Assignee | ||
Comment 20•22 years ago
|
||
fixed on trunk Thanks for the patch, Darin!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Flags: blocking1.4?
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
•