Closed Bug 286482 Opened 19 years ago Closed 17 years ago

Show when users are visiting a site over SSL they haven't previously visited

Categories

(Firefox :: Security, enhancement)

Product:
Firefox
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: gerv, Assigned: gerv)

References

(
URL
)

Details

This bug tracks an implementation in Firefox of the anti-phishing proposal known
as "New Site", described at the given URL. In summary, the idea is:

- Store (in hashed form) every domain visited over SSL
- Warn the user when they hit a new one.

This is on the basis that users will have visited their high-value sites before
(to establish the relationship) but will never have visited a phisher before
(otherwise they'd have been phished already). So the normal site will not show
the warning, but the phishing site will, creating a difference the user can see.

My initial suggestion for the UI warning would be to append the text "(first
visit)" to the domain name in the status bar. This text would remain present for
all pages on that site in the current browsing session.

One potential concern is the privacy issue - it is discussed in the paper. I
don't think the privacy loss is very great, and the security gain comes from
having a good and persistent record of previously-visited domains. So, my
current suggestion is to have the Sanitise function by default _not_ clear the
SSL domain history, but have a hidden pref to change that behaviour. That way,
average users get the security benefit, but ultra-paranoid users can scrub their
browser very clean.
This is a good idea. Implementation wise, I wonder if in the case of a user
having visited the said site before and being phished again by the same person,
someone might turn around and say that "Firefox didn't warn me about the site
and it should have." While this would be due solely to a lack of understanding
of how the system works, that's unlikely to stop people from complaining anyway.

Also, this doesn't address the issue that the vast majority of phishing sites
don't bother to set up SSL, and thus wouldn't be caught by this scheme anyway.
This fact may not be immediately obvious to the bulk of our end users.

Privacy wise, since none of this info is being sent to servers, I (personally)
don't see any issues with it. Different users on XP/Linux/Mac have different
profiles, and those who choose to share user accounts are already forgoing any
resonable expectation of privacy anyway.
I would actually prefer to pop up a dialog saying the user is *about to* enter a
new site, and give user an option of not going there. Or if we really want to
avoid popups, perhaps go there bug provide some button or something that the
user *must* click to show their acceptance to add this site to the already
visited and trusted SSL sites. Some notfication *before* going to the site would
be better, because just going to the site will present the attacker information
(think of a case where a spammer sends out emails where each mail contains a
unique URL to track which email addresses where active). 

Adding new sites automatically would still leave a security hole: if a hacker
manages to attract a user to the site once (even if the user was informed at
that time and went away), all subsequent visits to the site would look
legitimate to the user which is wrong.

There are some extensions for privacy concerned users that clean up all traces
of you using the browser so obviously those extensions should be able to scrub
this information as well.

Also browsers in kiosk modes probably should not be storing this information,
but that might be practically impossible to do if you can't tell when you are in
kiosk mode.
> I would actually prefer to pop up a dialog saying the user is *about to* enter 
> a new site, and give user an option of not going there.

You know as well as I do that this, or even a button version, is entirely
unworkable. :-)

> Some notfication *before* going to the site would
> be better, because just going to the site will present the attacker information
> (think of a case where a spammer sends out emails where each mail contains a
> unique URL to track which email addresses where active). 

That particular problem is only tangentially related to phishing, and is much
better dealt with on the email client side.

> Adding new sites automatically would still leave a security hole: if a hacker
> manages to attract a user to the site once (even if the user was informed at
> that time and went away), all subsequent visits to the site would look
> legitimate to the user which is wrong.

Not really. The indicator merely says "first visit". If the hacker manages to
get around it such that it's not the user's first visit, then that particular
layer of protection is gone. However, the browser and/or the user may have other
reasons to be suspicious of the site. This is not a standalone magic
anti-phishing bullet, it's one weapon in an arsenal.

Just because something only helps 99% of the time doesn't make it useless.

Gerv

Clearly image, script, stylesheet, frame, etc loads should not count as a
"visit". Only the top document whose URL would be visible in the locationbar
counts.  Necko can already make this distinction, just want it on the record.
Dan: good call; I subconsciously knew that had to be the case, but I hadn't
thought of it specifically.

Gerv
(In reply to comment #3)
> Not really. The indicator merely says "first visit". If the hacker manages to
> get around it such that it's not the user's first visit, then that particular
> layer of protection is gone. However, the browser and/or the user may have 

How about adding the same kind extra toolbar (not sure what terminology to use
her) that Firefix shows when it has prevented a popup? And have a button on that
toolbar to REMOVE this site from remembered safe SSL sites (and possibly close
the window as well as an added benefit, so that you won't accidentally start
using it /me remembers acutely trying to use an image of a browser window I made
myself)?
> How about adding the same kind extra toolbar (not sure what terminology to use
> her) that Firefix shows when it has prevented a popup? And have a button on 
> that toolbar to REMOVE this site from remembered safe SSL sites 

You need to get away from thinking that remembered SSL sites are safe.
Remembered SSL sites are merely sites you've visited before, and the UI reflects
that - it says "first visit", not "safe site". If we were trying to keep a list
of safe SSL sites, we'd probably be doing it differently, with a great deal more
UI, user interaction and complexity. And it wouldn't be as useful.

Gerv

(In reply to comment #7)
> > that toolbar to REMOVE this site from remembered safe SSL sites 
> 
> You need to get away from thinking that remembered SSL sites are safe.

A slip of the tongue. s/safe/visited/. But I do in fact think remembered SSL
sites are safe (or at least much safer than new SSL sites). I have a pretty
small set of SSL-enabled sites I go to, and I trust them quite a bit more than
the SSL sites I have never visited. I counted 7 SSL enabled sites in the last 7
days - I probably use on the order of about 20 SSL sites regularly.

The reason I think this is important, is that without this kind of thing
implementing this feature is only a minor speed bump to hackers. If somebody
goes to a suspiciouos site once, then it seems likely they will be as easily
tricked to go there a second time, and on the second time they get no warning. 

If I were a hacker, I would even set up a chain of 20 redirects (our maximum
default) through bad SSL sites ending up at a the real site the user tried to go
to. Then, using cookies or whatnot, seeing the user on one of those sites again,
just don't redirect and serve them the phishing page.

And this redirect makes me realize the the remove button should in fact keep
track of redirects as well, and remove all of the new sites in the redirect history.

The sad part about this is of course that no normal user would need to know why
they would need to use the remove button. But without it this feel basically
useless to security-savvy people.

And I also realized thet showing the same kind of warning as popups do might not
work well - image case where there are both blocked popups and new SSL site. So
maybe just showing that info somewhere with the padlock.
(In reply to comment #8)
> The sad part about this is of course that no normal user would need to know why
> they would need to use the remove button. But without it this feel basically

This came out wrong. Should be "...no normal user would know why..."

(In reply to comment #8)
> The reason I think this is important, is that without this kind of thing
> implementing this feature is only a minor speed bump to hackers. If somebody
> goes to a suspiciouos site once, then it seems likely they will be as easily
> tricked to go there a second time, and on the second time they get no warning.

Do you think so? I strongly suspect that most phishes are performed on the first
visit to a site. After all, if it's the second visit, either a user has already
been phished, or the phisher has had to fake enough of the site to support what
seems like legitimate transactions (e.g. a statement or balance transfer). And
why would they bother when they can just harvest the details first time?
 
> If I were a hacker, I would even set up a chain of 20 redirects (our maximum
> default) through bad SSL sites ending up at a the real site the user tried to go
> to. Then, using cookies or whatnot, seeing the user on one of those sites again,
> just don't redirect and serve them the phishing page.

That's a fair point - perhaps we should only add sites to the "already visited
list" when the user has viewed them for a certain period of time. Or perhaps
remove them again if they leave quickly. Or something like that.

> The sad part about this is of course that no normal user would need to know why
> they would need to use the remove button. But without it this feel basically
> useless to security-savvy people.

Are security-savvy people going to get phished?

> 
> And I also realized thet showing the same kind of warning as popups do might not
> work well - image case where there are both blocked popups and new SSL site. So
> maybe just showing that info somewhere with the padlock.

If you read the proposal, that's exactly what I suggested.

Gerv

(In reply to comment #10)
> > The reason I think this is important, is that without this kind of thing
> > implementing this feature is only a minor speed bump to hackers. If somebody
> > goes to a suspiciouos site once, then it seems likely they will be as easily
> > tricked to go there a second time, and on the second time they get no warning.
> 
> Do you think so? I strongly suspect that most phishes are performed on the first
> visit to a site. After all, if it's the second visit, either a user has already
> been phished, or the phisher has had to fake enough of the site to support what
> seems like legitimate transactions (e.g. a statement or balance transfer). And
> why would they bother when they can just harvest the details first time?

Suppose we have this implemented, and the user goes to a phising site the first
time. They notice, with our help, that it is fake and go away. A week later they
get tricked again to go to the site. This time they are likely going to fall for
it. First time user didn't do anything there, but the second time the trick
probably succeeds. Third time is not needed. With the simple implementation I
guess our only hope would be that phishing sites would come and go quicker than
it takes to get a user going there more than once. I suspect some phising sites
will stay up for extended periods of time, though.

> > If I were a hacker, I would even set up a chain of 20 redirects (our maximum
> > default) through bad SSL sites ending up at a the real site the user tried to go
> > to. Then, using cookies or whatnot, seeing the user on one of those sites again,
> > just don't redirect and serve them the phishing page.
> 
> That's a fair point - perhaps we should only add sites to the "already visited
> list" when the user has viewed them for a certain period of time. Or perhaps
> remove them again if they leave quickly. Or something like that.

I wonder if it would be enough to remember only the last site in the
automatically redirected sequence. Although things get complicated when you add
a slow redirect: say you go to site 1, start filling in your info, half way
through it uploads your data to site 2, then redirects to site 2 that looks
identical to site 1 and your data already filled in so that it looked more or
less like a reflow of the page, and so forward.

> > The sad part about this is of course that no normal user would need to know why
> > they would need to use the remove button. But without it this feel basically
> > useless to security-savvy people.
> 
> Are security-savvy people going to get phished?

Given the fact that I have fallen for an image of a brower window I made myself
I'd say yes. Less likely than with other people, though.

> > And I also realized thet showing the same kind of warning as popups do might not
> > work well - image case where there are both blocked popups and new SSL site. So
> > maybe just showing that info somewhere with the padlock.
> 
> If you read the proposal, that's exactly what I suggested.

Yes, I know. I just pointed this out to show why my idea wasn't as good one as I
first thought.
> Suppose we have this implemented, and the user goes to a phising site the first
> time. They notice, with our help, that it is fake and go away. A week later they
> get tricked again to go to the site. This time they are likely going to fall for
> it. 

Interesting - although "fool me once, shame on you. Fool me twice, shame on me."

> With the simple implementation I
> guess our only hope would be that phishing sites would come and go quicker than
> it takes to get a user going there more than once. I suspect some phising sites
> will stay up for extended periods of time, though.

I did a talk on phishing a few weeks ago and tried to find some examples from
phishing emails in my spam folder. This very unscientific survey concluded that
phishing sites have a lifetime of 24 hours or less. I doubt that's true of all
of them, but the average lifetime is probably short.

I know one highly-phished company has a group dedicated to finding and shutting
down phishing sites.

> Although things get complicated when you add
> a slow redirect: 
<snip>

There are definitely implementation issues. Although if we can get them setting
up things as complex as this, we are doing well.

Gerv
Sorry for jumping into the conversation...

I agree with Heikki, that a new site should be displayed as a browser message
and not just in the statusbar. In addition, I think that the bar should force
the user to decide on the validity of the site and not just exist as a passive
warning. A good way to do this would be to disable all forms in the page on
first visit and force the user to click the browser message to enable form
submission (not my idea, I am not sure where I read this).  The browser message
system in place is great for this as it avoids some of the inherent flaws of
pop-up type dialogs. Although this might be annoying for valid sites, SSL sites
are rare enough that this would be an acceptable annoyance.

Most importantly, Firefox must be upfront that it is storing secure site
information, so much so that I think it should ask users to enable the
protection at first startup. Also, the new site notification should never ship
with a white list.
(In reply to comment #13)
> I agree with Heikki, that a new site should be displayed as a browser message
> and not just in the statusbar. In addition, I think that the bar should force
> the user to decide on the validity of the site and not just exist as a passive
> warning.

I strongly suggest that there will be very poor user reaction to such a feature,
and they will start clicking on "It's valid" as a reaction.

Again, please stop thinking of this feature as some sort of "trusted sites"
feature. Such a feature would be a lot more complicated, and require much more
UI and design. It's just one of many things we can do to raise the bar for
phishing. I specifically chose the words "first visit" to be security-neutral.

> A good way to do this would be to disable all forms in the page on
> first visit and force the user to click the browser message to enable form
> submission (not my idea, I am not sure where I read this).  

You may well have read it in my writings on anti-phishing. This was my suggested
course of action for sites of which the browser was particularly suspicious.
Doing it for all SSL sites seems to me to be extremely counter-productive - both
because it hassles users, and because if you then use it for sites you suspect
of phishing, users will not notice and click "Dismiss" on the yellow bar anyway.

Note that users are more likely to want to use forms on an SSL site than on an
average site.

> Although this might be annoying for valid sites, SSL sites
> are rare enough that this would be an acceptable annoyance.

Ideally, every site on the net would use SSL, no matter what the contents, and
we are making other changes to the UI to encourage that. We do not want to put
barriers in the way of greater SSL usage.

> Most importantly, Firefox must be upfront that it is storing secure site
> information, so much so that I think it should ask users to enable the
> protection at first startup. 

If Firefox cached SSL certificates to improve SSL connection times, would you
also require that users explicitly agree to that at first startup? The
information we are storing is less of a privacy risk than that (because it's
hashed).

> Also, the new site notification should never ship
> with a white list.

I'll certainly agree with you there - although it wouldn't be possible anyway,
because the hashes stored are hashes of the domain with a random value set on a
per-browser basis at installation time.

Gerv

The basis of my suggestion is my fear that throwing an alert only will be
ineffectual. Pop-up dialogs have been shown to have marginal effect as the
average user rarely reads them and simply dismisses them out of annoyance.
Showing a browser message is a definite improvement as it is less annoying and
cannot be dismissed. Although better, without interaction, I still believe that
users will gloss over the bar (i.e. do users stop and think “Firefox blocked a
pop-up” every time the blocked pop-up bar appears?). User interaction at least
forces to think about what they are doing on some level. Disabling forms was the
best option I could think of to force users to interact with the security
dialog, although, I hope there is a better option. If SSL becomes more
widespread, then this policy could be revised.

(In reply to comment #14)
> If Firefox cached SSL certificates to improve SSL connection times, would you
> also require that users explicitly agree to that at first startup? The
> information we are storing is less of a privacy risk than that (because it's
> hashed).

The reason I suggested we tell the user upfront is that, without an alert, we
run the risk of attacks by privacy advocates. Consider the password manager - we
always prompt the user first to store passwords and make it easy to
clear/disable this feature. If Firefox stored visited secure sites (even hashed)
and makes it difficult to clear the record or disable recording, it is possible
that Firefox could be accused of keeping a stealth browser history of critical
sites (often sites where money is exchanged) without the user’s permission. This
is especially discouraging if SSL sites become more common (as you suggested).
This discussion has moved on miles since this bug; it serves no further purpose.

Gerv
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.