Closed Bug 451543 Opened 16 years ago Closed 16 years ago

Web page authentication confirmation error

Categories

(Firefox :: Security, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: p.holubniak, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16

Assume that I have certificate www1.domain.com signed by Verisign or other organization, installed on server www2.domain.com (this happens a lot especially when someone steels key and certificate from server) 

When I connect with Firefox to page https://www2.domain.com , initially Firefox informs me, that certificate was issued for different address, but after user accepts it and starts working with this page, there is no information that certificate do not corresponds with given page.   This is all the time that user is working with browser!  

Firefox shows that page is safe, when you clicks on lock, it displays wrong information that authentication of this page was confirmed  by Verisign which is not true because it was confirmed for www1.domain.com not www2.domain.com

Suggestion is:
-	allow people to accept his decision, that he wants to connect to that page even that certificate was not issued for given address. But maybe this should be done in the way that IE7 does. Do not allow person to just click OK, but refuse connection and force person to read information about problem and then choose proper option 
-	All the time, when you stay working with this page, mark it somehow that user sees that something is wrong with its authenticity.  Make place with url, red with information that authentication of this page was not confirmed etc. I suggest that maybe entire window should be read and even blinking. Make some place when you user can click and read what is wrong with this page. 
-	I suggest that if domain name in the certificate is different that this one on server (eg. www.domain_a.com, www.domain_b.com) that do to allow to connect. 

This will help preventing phishing or other attacks (man In the middle) on users. 

Regards

Piotr     


Reproducible: Always

Steps to Reproduce:
1.
2.
3.



I have no idea whether it is a serious bug. Sure, this can be exploited by someone, especialy in some public places like internet-caffe. So I mark it as a security problem.
This does not need to be security sensitive, we have been thrashing out the new identity UI in public.

(In reply to comment #0)
> but after user accepts it

You mean "after the user jumps through hoops to override our determination that we cannot trust the cert and tells us to use it anyway" we do in fact take the user at their word and use that cert for that site, either permanently or for the session according to what the user told us.

> there is no information that certificate do not corresponds with given
> page.

There are proposals to show exception sites differently, but it's not true that there's no information. It's just a little buried: If the user clicks on the favicon (Site information button) "Larry" will in fact say that that it was a user exception, rather than "Verified by Equifax" (like this site) or whoever the CA is.

> Firefox shows that page is safe, when you clicks on lock, it displays wrong
> information that authentication of this page was confirmed  by Verisign which
> is not true because it was confirmed for www1.domain.com not www2.domain.com

Oh, Firefox 2. Yeah, we fixed that in Firefox 3.

> Do not allow person to just click OK, but refuse connection and force
> person to read information about problem and then choose proper option

Firefox 3 does that.
Group: core-security
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Component: Phishing Protection → Security
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.