Closed Bug 196827 Opened 17 years ago Closed 17 years ago

it says that site is secure when it isn't because the connection was canceled

Categories

(Core Graveyard :: Security: UI, defect, P1, critical)

1.0 Branch
x86
All
defect

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)

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!
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.
Could you please post the source of your phpinfo.php?
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.
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
I see this in linux trunk 2003041109 ; OS should be set to ALL.
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
Mozilla 1.2.1 (last official release) isn´t affected, so the regression occured
after opening the 1.3a trunk
Flags: blocking1.3+
marked as blocking 1.3
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
uh, sorry Boris. I wanted to set it to ? but apparently I was too confused and
choose +.

Will have better look next time.
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
QA Contact: junruh → bmartin
Flags: blocking1.4a?
Flags: blocking1.4a-
Flags: blocking1.3?
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: ssaux → kaie
Blocks: lockicon
Flags: blocking1.4b?
Keywords: nsbeta1nsbeta1+
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
kai: let's fix this.
Keywords: nsbeta1+nsbeta1
Per adt: nsbeta1+/adt1
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1]
Flags: blocking1.4b? → blocking1.4b+
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
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!
Attached patch Patch v1Splinter Review
Patch provided by Darin
Comment on attachment 121976 [details] [diff] [review]
Patch v1

r=kaie
Attachment #121976 - Flags: review+
Comment on attachment 121976 [details] [diff] [review]
Patch v1

sr=jag
Attachment #121976 - Flags: superreview+
Attachment #121976 - Flags: approval1.4b+
Attachment #121976 - Flags: approval1.4b?
Attachment #121976 - Flags: approval1.4b+
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+
fixed on trunk

Thanks for the patch, Darin!
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Flags: blocking1.4?
Verified.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.