Amir Herzberg wrote:
Ian Grigg wrote:
[Guys, I've added the mozilla-security group to this thread.
We are discussing this proposal:
http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm ]
Thanks, I think it is a good idea to discuss this in the Mozilla forums
esp. considering our prototype implementation is on Mozilla (although
the idea of course could and - I think - should be applied to all
browsers). Although, maybe the crypto forum is more appropriate than the
security one, according to their definitions (I haven't really followed
these forums so far). In any case, I've posted an announcement about
this work in both forums to give context.
No, the crypto-mozilla forum seems to be inappropriate.
The security model needs to be deployed top to bottom,
and I guess the drivers for that come from the apps
people.
...
(See screen shots of Mozilla in above URL.)
Please do look at the screen shots... if you're too lazy to see them in
the paper, at least see:
http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing_files/image006.gif
Definately.
what I propose and why I believe there is no problem
whatsoever in confirming the CA logo set:
Each CA's root is expanded to include the logo set.
E.g., the default root list of Mozilla includes for
each CA a root cert, a small logo and a big logo [4].
I think we should not assume that every CA trusted by the browser for
SSL, should also be trusted to certify logos. As you said in many
places, it probably makes sense for browsers to accept even self-signed
certs for SSL, and certainly users don't know or trust the many CA in
the browser. I don't think this should work in the same way for Logo
certification authorities: these should be entities that the user
actually trusts to validate the logos.
This is the crux of the assumption of "all CAs
are equal" within the SSL model. Removing this
assumption is critical to security, but unfortunately
it has more ramifications than are obvious at first
blush.
In the beginning half of this year, there was a long
debate conducted by Frank Hecker of MF for the purpose
of creating a "new CA" policy. That policy is written
up and I believe in draft form, but is effectively
the one in effect.
The reason for so many CAs being present is partly
historical - the big rush in the 90s to fill Netscape's
list - and partly because the world is a complicated,
segmented case. x.509 is really a country-oriented
situation, and the conditions within each country
vary dramatically. So, for a start, we can practically
assume that the order of magnitude of count of CAs is
going to be driven by how many political boundaries
there are. 200 countries.... may mean 200 CAs. See
for example QuoVadis, serving Bermudan companies.
And that's before we get into industry and economic
structuring as shown by CACert.
So I think the result of all this is there will be
a lot of CAs now, and in the future. And, I think
the same situation applies to LCAs - not everyone
is going to be keen on another country's logo signer.
2. If the scammer gets an Anazom cert from the
ChineseMinistryOfIntellectualProperty, a known and
accepted CA, and then deploys that in an attack,
the user should notice the change in brand of CA.
Or maybe the user doesn't approve the
ChineseMinistryOfIntellectualProperty as a Logo CA at the first place.
Why should Mozilla (or MS...) decide that I must trust a particular
entity? Let the user decide.
OK, so one key difference I hadn't realised was
that the Logo CA has to be approved by the user.
This sits oddly against Mozilla's policy of
delivering a browser that is set up for the
ordinary user with no intervention. That is,
Mozilla works for the default user, not for the
user who knows how to look after herself. This
is "policy" and has been well thrashed out.
So the implications of this would be that
Mozilla Foundation (MF) would need to present
a set of LCAs that are pre-trusted, and allow
the user to add any others. (Maybe you
envisage that set to be empty?)
Of
course, Amazon, having purchased the premium Verisign
package, will have been displaying the VeriSign logos
in that branding box for years.
Of course; and I agree that this gives extra security. But still many
users may not notice the change of the CA cert; so it is critical to
make it difficult to present an Amazon-like logo in the first place.
I think the thing here is that those targets that
are subject to phishing can actually deal with this.
Right now, we see nonsense like that thing posted on
the cryptography list about "best practices..." which
one reads and one knows that a) it's a sales blurb,
and b) it isn't going to change the threat of phishing
to the users.
However, when we have a Verisign cert up on the top
of browser as well as potentially a Bank of America
logo - I think it reasonable for Bank of America to
say to all its clients: make sure you see the CA
logo up the top. That CA will make sure nothing
cunning slips in.
Compare and contrast this to for example the key/
padlock. Telling the user to look for the key/padlock
misses the vital element - who cares if there is a
key/padlock if it is the wrong site?
And, who says it is the wrong site? Not Bank of
America, that *is* the site. It is Verisign that
says it is the right site. Their claim needs to be
surfaced and made part of the user experience.
The users can see that change. They can see that
change like they see a change in adverts on the TV,
because it is branding and it is designed to give
the user a sense of comfort when there, a sense of
worry when not [8].
Yes, but ads in TV do not contain the brand/logo of somebody that
approved the logo of the company... The basic logo proteoction is
improtant, not just that of the CA.
...
Adds on TV carry the brand of the TV station. They
also carry a high price. These two work together to
avoid any reasonable fraud. The TV station conducts
due diligence on the advertiser. If I walk into the
TV station with my advert for KloakaKoala with the nice
curvy red writing, the funny bottle shapes, and a jungle
that sounds just like another famous cola company, I
will not be able to air my ad - because the TV station
might be sued by that other Cola company, CocaCola.
Which is why, for example, I can see that Amazon and
Paypal are going to be paying a lot of money for this
protection. Which is fine - because the protection
is worth it to them. Aligning the costs to the needs
is an important thing that needs to be done.
On the one hand, certs and logos for big account companies
like Wachovia are going to cost a bomb. On the other
hand, maybe I'll finally be able to set up my little
test account systems with SSL and not have to pay $'000
per annum for the privilege. These are both good things:
we need both SSCs to be accepted by the browser, and high
end expensive logo-based cert packages. See my rant on
differentiation.
3. If the scammer uses a self-signed cert (SSC),
then the branding box shows "Self-Signed Cert" in
very boring, non-logo grey. The user can notice
this as above. Same, same - if the user expects
an SSC, then all is well and good. If not, then
raise red flag [9].
Again, the fact that a site is self-signed (i.e. not certified by one of
the CAs burned in the browser) does not mean in cannot get a logo
certificate... or possibly that the user could manually validate the
logo (see paper...)
OK.
So, the user (and the browser together) police the
SSC space by looking at the bland display and the
count of uses of that cert.
And by approving and confirming the display of the site's logo!
Here, I need to finish reading the paper.
4. If the scammer doesn't use a cert at all, then
the branding box shows a black hole with the number
zero. The user can notice this [10].
I prefer what our current protype does i.e. we simply display a very
clear `this site is not protected` warning (see paper/screen shots...)
...
Yup, that's fine too, I like the red. I'd still stick
the number in there.
Yet, now, we have our first real threat, in the
form of phishing [11], and we can now see that what
is needed is not crypto strength, but a CA brand:
Actually, we also need proper crypto validation that the site is the
owner of the certified public key (i.e. has the corresponding private
key), implying he `owns` the certified logo.
That is what the CA cert does, no? It signs the
user's certificate, thus validating that the site
owns that public/private key. And, any logos
that are added.
The problem that arises is that right now, no CA
has an incentive to care if they get it right. Any
phishing attack does not show who the CA is that
didn't do their job. So why should the CA care?
They're all equal, by definition and by protocol,
so wheey hey, let's sell some certs....
But you can tell the user that Citibank uses
GeoTrust certs, and if that pretty picture of
the red arrow/blue corner changes, watch out [12].
And you know the Citibank logo itself - and certainly won't trust any
Logo Certification Authority that will allow a logo that looks very much
like Citibank's ...
Well, this is precisely my point with the certs.
If the CA is surfaced and on the page, then the
users will desert that CA if ever a phishing
attack is found against it. Whether it be via
a logo or a simple domain name. What I'm arguing
is that it is not the presence of the user's logo
here that makes the difference - but the presence
of the CA's logo. Only branding the CA can make
the CA do its job.
It's like the time Verisign issued a Microsoft
cert to someone who asked for it. Why did they
care? They didn't. Because nobody knows what
they do. Nobody out there in USERLAND has any
concept that Verisign or Geotrust or any of the
others had anything to do with the lock or padlock.
That's the thing that has to change - all CAs are
not alike, by definition, and that assumption has
to be rooted out and exorcised, before the SSL
infrastructure can be made to work against the
real threats.
I'm using the system currently, without any CA, just by approving logos
manually, and it is really very easy and convenient. But I hope to make
it available to all of you soon so you'll be able to judge for yourself.
Excellent.
No reason to have 100 or more CA's pre-appoved in the browser for this.
Ah, on that point, alone, you probably want to
review the long debate on Frank's Policy. I think
this is a situation that will not change in the
short or even medium term.
iang
_______________________________________________
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security
