262366 - Always show host name in status bar (anti-spoofing)

Status: RESOLVED WONTFIX

(Firefox :: General, enhancement)

Description

[Daniel Veditz [:dveditz]]

With the demise of the always-on location bar we once again have no
anti-spoofing/anti-phishing story.

Possible solution: expand the SSL hostname thing to show the host name all the
time. If it's important to distinguish between secure "we know this for a fact"
hostnames vs "if you trust DNS" host names we could bold the secure hosts and/or
add a background field.

Comment 1

[Jim Ginn]

I have a patch for the statusbar idea. I just have one question...

Do you want the host name shown on non-secure sites:
(1) all of the time
(2) only if the location bar is not present
(3) only in pop-up windows
(4) only in pop-up windows if the location bar is not present

If there is a agreement on which approach is best, I can post the patch.

Comment 2

[chris hofmann]

if we can get this one we can get to zero open secunia issues.

Comment 3

[Jim Ginn]

Attachment: possible fix

This patch follows the approach number 3. Whenever a user sees a chromeless
popup window, the domain of the current site will be visible in the statusbar.
To differentiate between secure sites, normal sites show the broken lock icon.

Comment 4

[Jim Ginn]

Comment on attachment 160706 [details] [diff] [review]
possible fix

Asking review from Ben.

Also, please ignore the errant space in front of the ending else bracket. I
don't how that got there.

Comment 5

[Jim Ginn]

Attachment: possible fix

Its been one of those days, sorry for bugspam.

Comment 6

[Jim Ginn]

Attachment: possible fix

Also, fix pinstripe while I am at it.

Comment 7

[Gervase Markham [:gerv]]

> With the demise of the always-on location bar we once again have no
> anti-spoofing/anti-phishing story.

I'm not sure that's true. For sites where important or confidential information
is involved (and which therefore use SSL) we do. For other sites, we can't
guarantee we are connecting to the right site anyway (e.g. because of DNS spoofing).

I therefore suggest that putting the hostname in the status bar even when we are
_not_ sure we are connected to the correct site reduces, rather than improves,
security. If ebay wants anti-phishing, they should use SSL and tell Firefox
users to look for ebay.com in the status bar.

Having said that, if people disagree with me and decide to do this, then we
should have it all the time, not just when it's a popup window. This is not a
"replacement URL bar", it's a piece of security UI with a different function.

Showing the broken lock icon on normal sites is also a departure from previous
practice, and changes the meaning of that icon. I don't think that's a good idea.

Gerv

Comment 8

[Michael Lefevre]

FWIW, I agree that 1) would be better than 3), but I think either is better than
doing nothing on non-SSL sites. I'm not sure that DNS spoofing is a huge issue -
it's relatively difficult to do, and I think that spoofers would go for simpler
tricks long before they get to that. There are (not that there should be) plenty
of sites where important information is involved but SSL isn't used. You can say
"if ebay wants anti-phishing...." - but it's users (and secunia) that need/want
anti-phishing, and they'll take it from either the sites or the browser -
millions of sites and half a dozen browsers means it's easier to get the
browsers to change.

Like Gerv, I don't like the idea of having the existing broken lock icon though
- that has a specific meaning that has been used across browsers for years, and
this would be a change. It should either be a substantially different icon
(maybe a greyed-out open lock?), or no lock at all, IMHO.

Comment 9

[Jim Ginn]

Ok, I agree that showing the broken icon goes against previous practice. My
reasoning for using the broken icon is that its a pretty clear indicator that
the site is not secure and I am not sure that the average user is going to see a
difference between broken/no security. My original patch did not use an icon,
but when I tested it, the domain in the statusbar wasn’t very noticeable to me.
With that said, it is probably better to create a new icon ie. a grayed out open
lock called Security-none.png.

I still think that (3) is the best approach. DNS spoofing is fairly involved and
not showing the domain isn't that much safer (the spoofed site still looks
spoofed). (1) is also viable, but it makes the toolbar look cluttered and is
redundant considering that ~90% of users are not going to hide the location bar.
But, its trivial to switch this behavior.

Comment 10

[Michael Lefevre]

"(1) ... is redundant considering that ~90% of users are not going to hide the
location bar."

Not sure what you mean here - the concern isn't about users hiding the location
bar, but about spoof sites hiding it (and possibly replacing it with a fake
location bar).

Comment 11

[Jim Ginn]

Attachment: always show domain

I think this is what everyone wants.

This patch will cause Firefox to always show the domain in the statusbar
(number 1). Non-secure sites use the (currently) non-existent icon
Security-none.png. I also added a check to make sure about: sites don't appear
in the statusbar. I have tested the patch a bit more and everything looks good.
Chrome sites (chrome://) are a little funky, but I don't think that is a big
deal.

Comment 12

[Jim Ginn]

(In reply to comment #10)
> "(1) ... is redundant considering that ~90% of users are not going to hide the
> location bar."
> 
> Not sure what you mean here - the concern isn't about users hiding the location
> bar, but about spoof sites hiding it (and possibly replacing it with a fake
> location bar).

Please bear with me, I learning here.

Even though I obsoleted that patch I still have a question about this. To hide
the location bar, wouldn't the site have to launch a window with the
chromehidden attribute? If so, the patch whould make sure that the domain always
appeared in this situation, protecting the user. When the user is browsing
normally, the location bar (by default) is present and is probably a better
indicator of spoofing than just showing the domain.

Comment 13

[Michael Lefevre]

argh... sorry Jim, you're right and I was commenting based on a
misremembering/misunderstanding of the previous comments. Please ignore me...

Comment 14

[Jim Ginn]

If we do this, we really need to look at fixing Bug 255388.

Comment 15

[Gervase Markham [:gerv]]

> I think this is what everyone wants.

Ben Goodger gets the final word in Firefox UI decisions, and he's marked this
bug as "blocking-aviary1.0 -" so I suspect he doesn't want it. :-)

Gerv

Comment 16

[Daniel Veditz [:dveditz]]

"Not blocking" is not the same as "Wouldn't take if a reviewed patch was
available". If he meant the latter he would have WONTFIXed the bug.

Comment 17

[Jim Ginn]

Does anyone else want to review this patch if Ben is busy?

Comment 18

[timothy lim]

It is definitely something i would love to see in firefox.

Comment 19

[Josh Powell]

I think this would be good, as long as their is an uption to turn it off.
Currently I have over 5 or 6 extensions all taking up space in my status bar,
and I don't think I would have room for much else!

Comment 20

[Ian Grigg]

> I therefore suggest that putting the hostname in the status bar even when we are
> _not_ sure we are connected to the correct site reduces, rather than improves,
> security. If ebay wants anti-phishing, they should use SSL and tell Firefox
> users to look for ebay.com in the status bar.

I agree with this.  The point of putting the additional information
on the status bar is to indicate what is reliably known, and by always
putting the domain name in that spot in the status bar, this becomes
just another little detail for the user to glaze over.

Almost all phishing is non-SSL because users haven't accepted the
"padlock" security model.  Only by enlarging the padlock notion into
a more complete security display can this be made obvious to users,
and only by forcing SSL to be important can the identity information
be used to protect users against bogus identities.

Not only is more SSL information needed (other than the padlock) but
it needs to be made more obvious, so that users can get accustomed
to its presence on their favourite banking site.  It is the *difference*
that matters more than the content, as phishers create as perfect a
copy as they can.  This means that a non-SSL site should not have an
additional information shown.

(Apologies for being late to this conversation;  I had been led to
believe that nobody in Mozilla accepted / worked on phishing as a
serious problem!)

Comment 21

[Jo Hermans]

see also bug 252142

Comment 22

[Jim Ginn]

Comment on attachment 160768 [details] [diff] [review]
always show domain

I have had some time to think about everything discussed here and I still think
that always showing the domain name is still a good idea. Adding this feature
will be especially beneficial in alerting users to spoofing in pop-up windows
or for users who like to hide the address bar. It will also lessen (although it
is not the proper fix) the impact of bugs like Bug 273699.

The arguments against doing this are definitely valid and must be considered.
It is important to note that showing the domain does not degrade the meaning of
the padlock or secure sites. DNS Spoofing is quite rare and still affects the
url bar, however, to further emphasize that the domain cannot be trusted, a
tooltip can be added to state “website identity not verified” – or something
similar. In addition, Firefox does not currently allow an easy, obvious way to
access site security information (which is still important for non-secure sites
simply to tell the user the site is not secure and not to be trusted). By
allowing access on the statusbar, Firefox makes an additional step towards
making site security information to the user more apparent with the resulting
benefit of reducing the effectiveness of several common spoofing techniques.

If there is a consensus that this is the right path, I am more than willing to
update the patch for the trunk.

Comment 23

[Gervase Markham [:gerv]]

> Adding this feature
> will be especially beneficial in alerting users to spoofing in pop-up windows

Actually, I think the current arrangement is the best for alerting users to
spoofing in popup windows - because the difference between wrong and right is so
much greater.

Now, if it's a valid popup on an important site (which therefore uses HTTPS),
you'll get the domain. If it's a spoofed popup, you'll get *nothing at all*,
unless the attacker has exposed themselves by buying a cert (which does give at
least some audit trail).

If you changed it, on a valid popup you'd get a domain, and on a spoofed popup
you'd get a different (but perhaps very similar) domain. This is much harder to
spot.

So the right thing to do to help most users is keep things the way they are.

Gerv

Comment 24

[Jim Ginn]

I apologize for the delay in response, but I have been unbelievably busy. Gerv,
I have been following your blog and I agree with several of your suggestions to
prevent phishing in Firefox, but I still have issues with always showing the
domain address.

(In reply to comment #23)
> Now, if it's a valid popup on an important site (which therefore uses HTTPS),

Although that is becoming increasingly true, it is still a very dangerous
assumption. Many websites still do not use HTTPS for important data, especially
forums, webmail, and software registration sites. Consider hotmail – although a
user losing their password is not a major concern (you can easily create a new
account), the concern is that the phisher can then access secure information
within the user’s email.

> If ebay wants anti-phishing, they should use SSL and tell Firefox
> users to look for ebay.com in the status bar.

In many cases the website could care less whether they have anti- phishing
policies (thus, they have no motivation to change the site) - it is the users
that want the protection. If always showing the domain address is implemented,
then ebay would simply tell the users to look for the lock icon AND to check the
domain address. This makes more sense considering many new Firefox users are
migrating over from IE and are familiar with the concept of "checking the lock."
 
> If you changed it, on a valid popup you'd get a domain, and on a spoofed popup
> you'd get a different (but perhaps very similar) domain. This is much harder to
> spot.

And if you show nothing, the difference is impossible to spot ;) 
I view the similar domain name problem as an issue of accountability. Once
again, consider the hotmail example I stated before. Right now, if I opened
hotmail or a spoofed hotmail site in a popup window, you cannot tell the
difference between the spoofed and real versions. Additionally, since the domain
name is not shown on the real site, the user has no real reason to doubt its
validity when the domain name is not shown on the spoofed site as well (this is
true in non-popup windows even with the url bar present – think of http login
phishing). Thus, the user has a valid complaint that Firefox has not reasonably
alerted him/her to the possibility that the website is spoofed. 

By showing the domain address, we allow the decision to be in the hands of the
user. If the user is confused by similar domain names, Firefox has at least
helped the user make an informed decision, rather than simply saying the website
is not using SSL and withholding information (heuristics could also help a lot
in this situation).

And on a related note, yes I know about Page Info and
dom.disable_window_open_feature.*, but most users do not. Also, I am aware that
showing the domain name is useless against DNS tampering, however, there isn’t
much a browser can do about this in the first place.

> Actually, I think the current arrangement is the best for alerting users to
> spoofing in popup windows - because the difference between wrong and right is so
> much greater.

That is why this is only a partial fix. To truly tackle the problems of
phishing, we will need to consider heuristics, white/blacklists, etc. I do agree
that more could be done to differentiate between secure and insecure sites – but
these issues are issues for other bugs.

Comment 25

[Ian Grigg]

Currently I view the additional domain name in the status bar as an important 
proof that this is a checked domain name, as per the cert.  If the domain name 
is also shown in situations where the cert is not checked, then the cert check 
is now meaningless.  If the domain were to be shown in the same fashion as the 
non-checked domain, then there is no point in using TLS for security. 
 
What this says is that you must provide phishing protection in unprotected 
HTTP.  That's very problematical.  Without cryptographic keys it is imposible 
to make statements that can be tied down and reliable.  So however good you get 
the techniques, there is always a possibility that a bug slips through, and 
there is a growing expectation that phishers will start to attack DNS in the 
future (there are documented examples of DNS attacks already, but on a very 
small scale.  These are consistent with other leading indicators.) 
 
This is why we view the phishing fight to *assume* the presence of the certs.  
Yes, this is to draw a line in the sand.  And yes, those sites out there - 
hotmail or whoever - may miss out.  And their users.  The presence of hotmail 
and the risk the users face there does not mean that it is possible or 
desirable to attempt to protect them.  Not all the users are protected all the 
time.  And, especially, if it breaks the protection that was designed in the 
first place, this is likely to do long term harm. 
 
In browsing, TLS and certs are the security layer, they are the layer that 
promises to stop spoofing, and phishing is a spoof.  They are the only thing 
that allows the browser to say anything for certain.  That statement is 
essentially this: 
 
   a) the domain in the cert is X 
   b) CA signed that cert 
   c) you are on a crypto-secure channel to X/cert/CA 
   d) you recorded your relationship to X/cert/CA as Y. 
 
It's very simple stuff (all three things need to be on the chrome).  Armed with 
that information, the user can apply some security metrics. 
 
(Note, even this is not ideal.  She is still vulnerable to a data re-writing 
attack on the node, so a more complete solution would be to make sure the 
Firefox DB is encrypted and protected as best as possible...  which still 
leaves keylogging.  But, let's be practical here, and not lose sight of what 
*can* be achieved.) 

Comment 26

[Ian Grigg]

I should add that the security model calls for cert-checked information to be 
shown differently.  That doesn't say that you can't show the domain on the 
status bar.  What it says is that if must look different.  So, if you were to 
duplicate the mighty impressive yellow bar effect for cert statements and leave 
the boring grey or white for unchecked statements, that would also align with 
the security model. 
 
(But, please consider adding the CA's name next to the domain.  Simply putting 
the domain name there as checked by a cert is not sufficient security, as it is 
too easy to acquire a cert from another CA in the same name.) 

Comment 27

[Jim Ginn]

(In reply to comment #26)
> I should add that the security model calls for cert-checked information to be 
> shown differently.  That doesn't say that you can't show the domain on the 
> status bar.  What it says is that if must look different.  So, if you were to 
> duplicate the mighty impressive yellow bar effect for cert statements and leave 
> the boring grey or white for unchecked statements, that would also align with 
> the security model. 

Absolutely, I agree that we should make secure sites and insecure sites that
much different in the statusbar – and it probably can be done by simply changing
the background of the text (say to bright yellow for secure sites, red for
broken security, none for insecure, etc.). That way we don’t degrade the secure
model and help improve its prominence.

I wanted to add that the risk of confusing the user is largely negated
considering we already show the full url in the url bar. Therefore, based on
some of the arguments against showing the domain in the statusbar, shouldn’t we
also hide the address in the address bar, since we cannot verify it really is
the correct address? No, of course not. If anything, showing the domain in the
statusbar adds additional protection by alerting to http login phishing and by
shortening long urls that may be constructed to confuse the user. Additionally,
if a hacker corrupts the users DNS, then the url bar will also show the bad
address as well, thus, we are not placing the user at an additional risk.

I also wish to reiterate that a secure website is always going to be the best
protection against phishing. Firefox does a great job with alerting the user of
this additional protection by changing the address bar and adding the lock in
the statusbar. Hopefully, we can continue this by improving protection on the
sites further – with a clear UI alert system, heuristics, white/blacklists, etc.
For insecure sites, showing the domain is just a bandaid fix at best, but
considering we loose nothing by showing it, it is better than doing nothing.

Comment 28

[Ian Grigg]

The precise mix of those decisions and presentations is not really something   
that can be determined in advance of some testing.  As you suggest above is a  
good start - yellow / red / boring.  But you might want to keep an eye on  
adding more colours later. 
 
Bear in mind that in terms of the original security model, the URL bar was what 
the user typed in.  There should be a second bar that shows what the browser 
then connected to.  In security terms, they should show the difference, and the 
statement made by the browser should be as 'proven' as possible.  So arguments 
for/against the status bar do not apply necessarily to the URL bar. 

Comment 29

[Michael Lefevre]

"I agree that we should make secure sites and insecure sites that
much different in the statusbar – and it probably can be done by simply changing
the background of the text (say to bright yellow for secure sites, red for
broken security, none for insecure, etc.). That way we don’t degrade the secure
model and help improve its prominence."

It sounds to me like that would degrade the secure model - anything that
increases the complexity of the UI reduces security. Currently, the user has to
look for one thing - it is either there or it isn't. Now you'll be asking the
user to look for several different things and understand the difference between
them.

Also, in Firefox 1.1 no background means "secure" - you're planning that in a
future version no background will mean "insecure". So if the user switches
between versions, they will need to be aware of which version they have in order
to understand the meaning of the UI...

Comment 30

[Ian Grigg]

> It sounds to me like that would degrade the secure model 
> - anything that increases the complexity of the UI reduces 
> security. Currently, the user has to look for one thing - 
> it is either there or it isn't. Now you'll be asking the 
> user to look for several different things and understand 
> the difference between them. 
 
The converse of that would be to simplify the complexity until there is no 
security.  Obviously, the security optimum exists somewhere between a null 
system and a too-complex system.  Right now, the security standard is a padlock 
that is not looked at by users;  one that creates a binary signal that hides 
whether the identity of the site is as expected, whether the CA is as before, 
and whether either have ever been seen before.  As the padlock is widely 
ignored, adding complexity can't really hurt security! 
 
> Also, in Firefox 1.1 no background means "secure" - you're 
> planning that in a future version no background will mean 
> "insecure". So if the user switches between versions, they 
> will need to be aware of which version they have in order 
> to understand the meaning of the UI... 
 
Security is generally signalled by a positive signal, such as a green light at 
a traffic stop.  Also, security is not an absolute signal, there are degrees of 
security. 

Comment 31

[Darin Fisher]

I'm in favor of this approach.  I think it makes sense to put the hostname in a
reliable place.  Encourage people to look there instead of at the URL bar.  It
frees people from having to parse URLs in their mind, and that's a good thing
even for insecure pages.

Perhaps if we do this then we should have the notion of an unlocked icon or some
other icon that indicates no security.  (Doesn't seamonkey do this?)  Maybe if
users hover over it or double-click it we can explain what it means to be
insecure, etc.

Comment 32

[Gervase Markham [:gerv]]

Having discussed it with dveditz, I've come round to (a modified form of) this idea.

If we can maintain a clear and visible difference between "site identity
verified", and "site identity not verified", and not confuse people upgrading
from 1.0, and get rid of the URL in the title bar, then I'd go with this. It has
the additional advantage of branding all windows with a clear indication that
they are browser windows, which reduces UI spoofing.

We will always be balancing the needs of web applications with the need for
security. I would like to suggest that we draw a line and say "the status bar is
ours - it's all about security, you can't get rid of it. Everything else can be
controlled by the site within the normal security models, to provide a rich user
experience."

I think we need some way of saying "site identity verified as correct" without
implying "connection encrypted". If phishers start to attack the DNS, and we
implement DNSSec or other counter-measures, we can than flag "site identity
verified", without flagging "connection encrypted".

This suggests to me that the way we indicate that the site identity is verified
should be _different_ to the way we indicate that a site is secure - i.e. we
shouldn't just duplicate the yellow background stuff. I'm not sure what the
correct solution is yet, though.

Gerv

Comment 33

[Jim Ginn]

I have ported over a modified version of the previous patch to the trunk and I
have been running a build with it for a while. Right now it will:

1) Always show the domain, except for about links (chrome links are shown, but
this should not be a big deal)
2) Not show an icon in the statusbar when at an insecure site (to reduce user
confusion)
3) Not change colors - although I feel this might be beneficial, not changing
colors allows for better flexibility when implementing additional anti-phishing
or security UI in the future (as Gerv said in comment 32).

One problem I have run into deals with tooltips. Right now the default tooltip
for insecure sites is "Displays security information about the current page"
(http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/resources/locale/en-US/security.properties#51).
 This statement is not very meaningful and I am inclined to change it to
something like "Web site identity not verified". This change, however, probably
impacts Seamonkey as well, so I am not sure of the correct course of action.

Comment 34

[Jim Ginn]

Would anyone oppose splitting the ssl and host name indicators into separate
statusbar panels? This might make the transition easier for previous users and
has the added benefit of allowing for better flexibility when implementing
additional spoofing protection in the future.

Comment 35

[Gervase Markham [:gerv]]

We're currently trying to work out a more general strategy for this bit of UI,
taking into account some other concerns which are SSL-related, over in
n.p.m.security.

Gerv

Comment 36

[Mike Connor [:mconnor]]

Gerv, I'm minusing this for now in the absence of anything concrete with
consensus in the last 3-4 months since your comment.  Please renominate and
provide details if we have a plan that we can execute on in the next two weeks.

Comment 37

[Jim Ginn]

I could put together a patch, but I was hoping to get a response from comment 34.

Comment 38

[Gervase Markham [:gerv]]

Jim: the host-name indicator is closely associated with the SSL lock icon, so
having them in different panels would be a backwards step IMO.

We currently are not planning to fix this bug as it's currently titled, but I
have some different ideas on how to solve the problem. Minusing it is the
correct thing to do for now.

Gerv

Comment 39

[Jim Ginn]

What is the status of this bug? Should it be Wontfixed? I know that there has been considerable effort to institute mechanisms to protect users from phishing/spoofing for version 2.0 and I think this bug is still beneficial. I will create a new patch if there is interest.

Comment 40

[Gervase Markham [:gerv]]

I don't think there are any plans to fix this bug as it stands. IMO, we only want to present verified information to the user; the hostname of a non-SSL site is not verified.

However, given that it was originally filed by our security lead, I'm not going to WONTFIX it myself :-)

Gerv

Comment 41

[Gervase Markham [:gerv]]

A year has passed, and I've got bolder than I was in comment #40 :-)

Gerv