HJ wrote:
Nelson B wrote:
HJ wrote:
Having troubles reading the text, try this one:
http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg
First of all, i've just updated my screenshot:
http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet-v2.jpg
Excellent. HJ, I would say your english is too
good and too formal and too techie :-) There are
simply too many long words there.
Having said that, I'm not the right person to
construct fewer words; I'm never ever been
caught being concise when I have a chance
of being comprehensive ;)
Finding the right set of words is the prize.
I suggest you talk to lots of people, who aren't
techies, and don't understand. Use the
experience to distill out the real essence of
the message.
Something like:
"MultiZilla sees a new secure website!
Are you sure this is the one you wanted?
If it is, click [YES] and MultiZilla will remember
that in future.
If not, this may be a phishing site for one of
your special trusted sites?
Check the certificate details...
If unsure, click [UNSURE] and MultiZilla will
put a big red question mark on the site in
the future.
If this site is bad, click [BAD]... "
Hmmm.... too many words...
The "Common Name" is no longer considered the "right" place to
contain the server's domain name. The right place is in the
certificate's list of
"subject alternative names", and that list may contain multiple domain
names and/or IP addresses.
It's good to continue to display the common name, as many legacy
certificates
still use that. But more and more we see modern certs that don't
have the
domain name in the "common name", and hence the server's domain name
doesn't
appear in that dialog. If the dialog was fixed to display subject
alternate
names, that would help a lot.
It's a shame that this wasn't fixed in mozilla years ago. But PSM is an
orphan. You're doing more to help PSM than has been done in a long
time,
and I (for one) appreciate it. I just wish your work was going into the
main mozilla PSM source, rather than into an offshoot.
Well, at least we're discussing a possible solution, and who knows
what happens at the end. It sure won't hurt ;)
Lets take this example, Gerv wrote in his paper that SSL History
should be user accessible, but I don't agree because what if I go to a
public Internet cafe or use Internet from some public computer in my
hotel?
That's a special case. If the place is untrusted, then
it matters not what you do, as an attack involves
perverting everything.
It's better to fix what we can fix for the average
stable user - Alice at home on her Windows PC.
Later on, improve that and also tune for the
exceptions like public computers.
Someone might add the wrong validation keys, and I'll end up visiting
a phony site, without being notified about my error!
In practice, a proper company like Kinkos or
whichever re-installs the whole thing every
user. At least, that's the ideal, and I gather
they do that because the FBI was grumbling
that they couldn't get the data on what
terrorists were communicating about...
Another problem is that Gerv paper only covers SSL protected sites,
but most recent phishing attacks (example:
http://www.rceasy.com/paypal/ ) do not even use SSL protection, so I
might still be fooled, without being notified.
The problem with providing *any* protection for
non SSL phishing is that even if it is done and
done well, it still doesn't cover the DNS attack.
The phisher can always just install a virus or
poison the DNS system, so any protection will
be a short term fix.
(DNS viruses have been deployed against online
payment systems, as of about 4-6 months back.)
So the strategy is to de-emphasise non-SSL protections,
and to emphasise that SSL protects against phishing.
But it can only do that if the cert info and naming
info is displayed and under user control. So there
are several steps needed to get to that point.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
