Closed Bug 196827 Opened 20 years ago Closed 20 years ago
it says that site is secure when it isn't because the connection was canceled
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
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.
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.
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.
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!
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+
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: 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.