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

Status: VERIFIED FIXED

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

Description

[Henrik Gemal]

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!

Comment 1

[Henrik Gemal]

Attachment: screenshot showing that gemal.dk is secure but it's not!

Comment 2

[Patrick]

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.

Comment 3

[Bruno 'Aqualon' Escherl]

Could you please post the source of your phpinfo.php?

Comment 4

[Henrik Gemal]

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

[Bruno 'Aqualon' Escherl]

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

Comment 6

[Drew "DanteAliegri" Ogle]

I see this in linux trunk 2003041109 ; OS should be set to ALL.

Comment 7

[Bruno 'Aqualon' Escherl]

Mozilla 1.2.1 (last official release) isn´t affected, so the regression occured
after opening the 1.3a trunk

Comment 8

[Bruno 'Aqualon' Escherl]

marked as blocking 1.3

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[Bruno 'Aqualon' Escherl]

uh, sorry Boris. I wanted to set it to ? but apparently I was too confused and
choose +.

Will have better look next time.

Comment 11

[Kai Engert [:KaiE:]]

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.

Comment 12

[Kai Engert [:KaiE:]]

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.

Comment 13

[Stephane Saux]

kai: let's fix this.

Comment 14

[Samir Gehani]

Per adt: nsbeta1+/adt1

Comment 15

[Kai Engert [:KaiE:]]

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!

Comment 16

[Kai Engert [:KaiE:]]

Attachment: Patch v1

Patch provided by Darin

Comment 17

[Kai Engert [:KaiE:]]

Comment on attachment 121976 [details] [diff] [review]
Patch v1

r=kaie

Comment 18

[jag (Peter Annema)]

Comment on attachment 121976 [details] [diff] [review]
Patch v1

sr=jag

Comment 19

[Asa Dotzler [:asa]]

Comment on attachment 121976 [details] [diff] [review]
Patch v1

a=asa (on behalf of drivers) for checkin to 1.4b

Comment 20

[Kai Engert [:KaiE:]]

fixed on trunk

Thanks for the patch, Darin!

Comment 21

[John Unruh]

Verified.