Ben Bucksch wrote:
OK. My thought is that we don't have many chances to push things like
that and have users consider it. If we make them aware of it, it better
be bulletproof, or we should not bother them with it, just treat it as
little better SSL cert, no special treatment.
You're absolutely right. Educating users is an enormous effort. That's
why I think whatever UI we choose (green bar, not green bar, whatever)
should be decoupled from the underlying enabling technology (EV, DNSSec,
phishing blacklist, whatever) we use to run it. That way, we only have
to educate users once.
Right. But how many phishers have an office with a street sign saying
"eBay" and a lobby?
...
Except you can't, because there won't be any information sources which
confirm that your number belongs to Microsoft. Because it doesn't.
...
I don't think any information source would confirm that your address
belonged to eBay.
Reliable sources like the phonebook or a random commercial database?
Do you have access to change either of those to associate your address
with eBay?
Remember, of course, the phisher does not know which sources the CA is
going to use. Those are (reasonably enough) kept confidential.
You are, and the CAs writing the guidelines are, not assuming that the
procedures are specifically gamed, things so arranged that the malicious
applicant would pass them, including renting a fake office with sign,
putting up fake phone numbers and listening them for a few days or
weeks, or specifically targetting the commercial database(s) that the CA
uses to get your bad info in there. Esp. the latter is probably
trivially easy, because the commercial databases are not security shops,
just providing contact info for initiating business. Esp. so in the US,
from what I've heard.
Yes, what you say about renting a fake office is possible. But think for
a moment - if everyone who wanted to set up a phishing site had to do
that, how much less phishing would there be?
People who rent offices leave a paper trail - they have to show their
face, leave deposits and bank details, people remember them. You can't
do all of this anonymously from Russia any more.
The CAs and guidelines (and you) don't take social engineering and
similar into account. Big error. That's what I'm pointing out.
I think they do - that's why there are lots of different checks and they
all have to come back consistent with each other.
But let me turn the question around: if "social engineering" means you
can't trust what anyone says about anything, how do you establish
anything to be true?
That's why there needs to be something that can't be faked, or has a
very well-known and established risk (even when considering fraud), e.g.
a hand-written signature that has been checked.
Checked against what? Couldn't that thing have been "socially
engineered" too? :-)
To top it, this number can then be used to verify the signature, with
"a response from someone who identifies themselves as such person
confirming that he/she did sign the applicable document".
I think you misunderstand the purpose of this step. It's to make sure
that a rogue employee doesn't apply for a certificate using the name
of someone else at the company who would be authorised to make the
application.
I don't know how you read that out "confirming that he/she did sign the
applicable document".
Joe Bloggs in the mail room at BigCorp has been bribed by a phisher to
intercept a few bits of mail so he can get an EV cert to spoof BigCorp.
However, Joe Bloggs isn't authorised to apply for EV certs under the
rules, so the phisher fakes the request as being from Fred Smith, their
CIO. The request is filed, and Joe intercepts the relevant mail.
However, Foo CA rings BigCorp, talks to Fred Smith and finds he never
signed the application, so it's rejected.
Something like that. Basically, you need to make sure that the person
who signed the application actually exists and did sign the application.
I can't quite see how you object to that check :-) It doesn't help with
the problems you are particularly concerned about, but it's not meant to.
One example: Let's say the guideline requires checking the signature.
The CA has a record saying that they checked it. But the signature was
still faked, and quite obviously so. Who's to blame? With this rule: the
browser user.
Well, presumably a court would decide that. But it could be that a
higher level of liability is needed to make it cost-effective to go
through the courts.
Thus: the CA needs to take liability, if they issue bad certs, no matter
which procedure they followed, no matter the situation.
What do you mean by "bad certs"? Do you mean "certs subsequently used
for fraud"?
An EV cert does not speak to the trustworthiness of the person who owns
it. (We've been through this before.) It just means we know enough about
the person to collar them if they use it for fraud.
Say a business is legitimate, gets an EV cert, then six months later
goes rogue and starts ripping people off. Is the CA responsible? What if
it's two months? Or two days?
So if, for example, someone gets an EV cert and uses it for phishing,
we can analyse how they did it and tighten up the guidelines to close
the loophole.
You think this will happen, and implemented, timely (days to weeks, not
months)? I don't think so.
That's part of the point of having a standard. It might take weeks or
months to update the standard, but I suspect CAs will be "unofficially"
looking out for the same tricks immediately. They don't want to be
landed with the liability and bad publicity.
Unqualified scepticism without rationale isn't really very helpful in
moving forward the discussion.
I really thing that every CA-issued certificate must be verified
using the following steps:
Just to check: you mean _every_ CA-issued certificate?
Yes. Or rather, every CA customer. The CEO can delegate to one or more
managers or admins, and that admin can then get a digital signature, and
with that the admin can create new certs on the fly automatically
without any paperwork, issued immediately.
To be even more explicit: you definitely mean "every CA-issued
certificate", rather than "every *EV* certificate"?
Sadly, I don't think we can single-handedly transform the workings of
the certificate market merely by decreeing that it be so.
Say we wrote our own guidelines, and said to all the CAs "unless every
cert you issue meets these, we'll yank your root". Who do you think
would blink first?
Given that nothing breaks anymore, we have no need to blink.
What do you mean by "nothing breaks"? If we are talking about *every*
certificate, then for non-EV ones, all we can do if they tell us to get
stuffed is to yank roots. And then lots of things break.
What about countries where there is no such register, or it's unreliable?
Example?
Well, the US has no country-wide business register, as far as I am
aware. States have them, but there is a variation in quality,
completeness etc.
I guess we'd have to see how things work there, how they can be made
reliably based on their customs. In a few countries, Africa maybe, this
may not be possible, but we don't want the Nigerian scammer to get an EV
cert, do we?
Not all Nigerians are scammers.
Well, who cares about majority when we're facing 25 CAs? You said we
effectively have a veto right, so...
Well, not quite. The voting rules are such that two Nos causes a vote to
fail.
This, and pretty much only this, will ensure that the card holder
really is who he claims to be, in real life, as seen by the
government and courts. Thus, before EV, I assumed that the above is
performed for the $100/year certs.
Really? There's no way any CA could make money doing this at $100 a cert.
Nonsense. Sorry, that's just CA margin-improving nonsense.
It's not. You can't do the sort of checks you are suggesting for $100.
First, they make $100 (per year, per cert) for that action (once, per
customer). And it's $1000 now with EV.
You said above you were talking about all certs, not just EV.
As I said, exactly this is offered as service in Germany for 10 Eur,
one-time fee. If they can make a site visit, they can also look at a
personal ID card and check a signature. My grocery store does it! What
gives?
Germany is not the rest of the world.
Surely you can see the massive differences between the grocery store
situation and the cert situation? They are not even vaguely comparable.
You are present at your grocery store, you are making a one-time
purchase of a small amount of goods, and you can give them an ID card. I
want to get a cert from Verisign. Do I have to go round their building
in Mountain View to present my ID? And when I've done that, they still
have to check I'm the same Gervase Markham who owns the domain I'm
asking for a cert for.
I'm not saying that there shouldn't necessarily be tighter checks on the
applicant; I am, however, saying that it's a far more complicated
problem than you seem to think.
In the US, there are networks of companies which will do site visits
and this sort of verification for you, but in other countries, there
aren't. Such a visit would cost several hundred dollars to have
performed.
Nobody's forcing them to have a flat world-wide fee. In fact, lots of
things will be different in many countries, out of necessity, even with
EV as-is.
Indeed, no one is forcing them to have a flat fee. Although if they
aren't flat, some people (not me) may consider it discriminatory.
Anyway, I point this out merely for information. It's not cheap to get
site visits done.
Their legal business name? Or their "trading as" name? Or the real
name of the person at the company who made the application?
I don't know. I'd say the legal business name - "trading as" would be a
different field.
But then you'd have certs with O fields with names no-one had ever heard
of. If you go to what you think is Sony's site, and it says "Sonii
Corporation" (one possible official romanisation of their Japanese
name), that would make you really suspicious, wouldn't it? It should.
That's exactly the sort of thing phishers do, after all - have a name
that's similar but not quite the same.
I mention this merely to show that it's not an easy problem to solve.
Gerv
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
