Nelson B wrote:
Hi Ian,
I wasn't asking "what do you think is the cause of a low
incidence of eavedropping", but rather "on what evidence do you
gather that there is not a high incidence of eavesdropping?"
Ah, the evidence of the busts. There is a continuous
series of bad guys getting caught,
[nice description of Chinese root attack snipped]
Unless the laws change, we'll NEVER hear of "busts" for collecting and
selling info (except truly stolen info). As long as the marketing firms
control themselves NOT to buy TVs with our credit card numbers, they'll
continue to be able to gather our personal information. If they can use
MITM to get it, they will (and do).
OK, so I was looking at rogue employees and you
are suggesting datamining as a variant.
This isn't "conclusive" but it's pretty darn close;
reports of anyone eavesdropping stand out a mile,
Only when a law is being broken. Most eavesdropping in the US
is legal (as long as the government isn't doing it), especially
if the user has agreed, as part of signing up for some service,
in some fine print they didn't read, to allowing it to be collected.
What you are talking about is more datamining. Collecting
data you are allowed to have, legally.
What you are suggesting to me is I change my definitions
somewhat. I'll think on that.
That's it. Just the laws of incredulity; if you
never ever hear about it then it isn't happening,
unless you also believe in UFOs, ESP and the return
of Elvis.
I've never seen ChoicePoint. I've seen only one report about them.
Should I not believe they exist, and many more like them?
Sorry, yes, it only applies if you look. If you never
looked, then you don't know what's out there. I've
been looking for eavesdropping for the last many years,
and nothing found. I knew about that industry back in
98 or so, and I always wondered why the SSL people were
so fanatical about SSL when that was going on, but I
wouldn't classify as listening to own-customers' traffic
as eavesdropping, as it's all in the agreement.
( Choicepoint isn't eavesdropping. That's
buying and selling of public information - in fact
with Choicepoint what they were doing was buying
and selling *public* information, AFAIR, which
is different again to private information held by
others on you. )
If the discovered activity was AGAINST THE LAW, the employee might be
able to reveal it to law enforcement and enjoy some legal protections
for breaking his NDA. But as I said, selling info is quite legal.
Whistleblowing. Been there, seen the cost. As an
aside, don't ever be a whistleblower, unless you are
smart enough to turn it to your advantage (nobody here
is including myself). Whistleblowers get destroyed.
Mind you ... I'm prepared to be persuaded - you say
that all this information is readily sellable - can
you offer any evidence, any anecdotes?
Let me describe a scenario to you. Someone signs up with a broadband
Internet service provider, but doesn't install the software on the CD
his ISP sends him. When he attempts to visit his bank's online
banking website, he gets a warning about a cert from an untrusted
issuer. He calls his ISP, and his ISP first suggests that he install
that CD he got. When he refuses, the ISP helps him reconfigure his
browser not to use the ISP's proxy. Problem solved. No "busts" in
the paper. His browser's reliance on trusted CAs helped him detect
and avoid the MITM.
OK, but this is all standard practice, right?
But some ISPs' services cannot be used without installing their software.
Sure. Life's a bitch. Change ISP. We aren't
responsible for molly coddling all our users.
We are as a security community desparate for some
data points on this... I occasionally grill people
who should know and they can't come up with any.
Maybe their NDAs keep their mouths closed.
Right. But info leaks. That's why I say that
people in credit card operations confirm there
isn't any eavesdropping. What they do confirm,
and what the press confirms, is that the biggest
threat is the same as it always has been - the
rogue employees selling the data out of the
database. Which is similar to what you are
saying, except with your case it is the company,
and it's legal. So we've always been talking
about the same threat.
In fact, today, mozilla empowers users with the tools to
detect and avoid these things. The SSH model doesn't.
I'm sorry, I can't keep up. I looked up this
quote, and it seems we are talking about the
Chinese ISP scenario, where the user has to
download the ISP's software and install that,
and/or root keys.
Yeah, but let's call it the American Broadband ISP scenario.
And installing the root CAs is usually optional. It's never done
by itself. The user is never made aware that he's installing root CAs.
He's only installing the ISP's software CD, which the ISP encourages
him to do (and the broadband installer will do to his system unless
he is adamant against it) and what that software does is never quite
clear.
When the user does that, then
Mozilla and SSL's cert protection can be
bypassed. I'd say that this is call for a
general security warning in the download and
install process.
But fundamentally once done, we can't *stop*
it. And it's legal.
What we can do is show the user what happened,
which is fine, as it doesn't change the rights
or the legality of what has been done.
Let's revisit the scenario I described above as an example.
The user is new to his ISP. He starts browsing, and every time he
visits an https site FOR THE FIRST TIME, in the SSH model his
browser says "hey, here's a new cert. Do you want to use it?"
No warning about unknown issuer, this is SSH-style. It protects
you against CHANGES in public keys, but not the first visit.
OK, nice description. Remember the caveat that
proposing SSH-style checking is an addition to
the PKI style of checking. Not a replacement,
so there can quite happily be warnings about an
unknown issuer.
I can see that we should invent a new term here,
as the usage of the term 'SSH-style' is actually
holding us back from seeing the meaning of it.
(You may recall that I once thought that SSH users tended to attempt
to verify public keys by some out-of-band means on first contact.
But you set me straight about that, revealing that users always just
say "yes" on first contact. Since then, I've gotten involved with a
lot more SSH users and have found that you were 100% right about that.)
Cool! Facts are good. But, did you notice that it
works for them and they are secure? That's because
it works in that environment. If there were any
failures, they would find out ... and then the
problem would be fixed. Feedback is a very important
part of security, it stops security systems protecting
from the wrong threat.
So the SSH-style user says "Sure!" because that's what he and all
other SSH users always say when they encounter a server's public key
or cert for the first time. And after that, he's happy, his ISP is
happy, his ISP's information broker is happy. Everybody's happy.
SSH really came through for him. Right?
No. The ISP's information broker is pissed because
when the first time user clicks on the link to go
to the trusted site, the advisory says that this is
a new cert. (That far we're agreed on.)
But the advisory also says that this is a cert signed
by CheapCA and the domain is for the ISP. OK, so the
user then clicks OK and follows the instructions any
way. This is in essence just the same social engineering
attack as phishing.
Then, when she goes to her bank, the cert's logo and
the cert's signer show on the chrome. The bank site
says "make sure you see that we use VeriSign" and it
has a little picture that has a little red circle and
an arrow showing where she should look on her browser.
So she looks and hey presto she sees .... CheapCA and
not VeriSign. She looks further, and see the domain
is the ISP. She starts to panic and calls her son
who is some sort of high school wannabe geek and he
says "Whoa, that's so dead" or whatever passes for
english these days ...
The user is now alerted to the fact that the cert
that she has some how found is not the bank's cert.
And the signer of the cert, CheapCA is not the one
the bank uses. And this exposure was all done by
the browser, and the browser alone, by following
one guiding principle: give the user the information
on the chain of signatures.
TrustBar kills your Chinese scenario stone dead, or
will do when it has more than just VeriSign's logo
delivered inside it.
Check it out.
You said above that mozilla avoids those things
Today, mozilla's root list does a pretty good job of protecting
the user in this case. (I don't know of any MITM who attacks
mozilla's trusted list in the way they attack IE's list.)
So what you mean is that mozilla's root list protects
until someone attacks the root list. This is one
of the biggest problems with the secure browsing
scenario - it assumed that a secure model could be
created that was perfect. But no such thing pertains,
and we *have* to involve the user(s) in the protocol
in order to address attacks like that.
and now you say that the SSL isn't secure?
I say that people who let ISPs or marketing companies install CAs
in their trusted CA lists will have little or no SSL security, yes.
Right. That's a fact, in today's situation. It's
an MITM attack on the browser, and it works and it
has always worked ... and it always is a future
possibility too. But, this sort of MITM is exactly
what we've been discussing for the last year - how
to stop someone substituting a cert that they somehow
acquired by whatever means.
SSH - you might have the wrong idea about
what is being suggested there. In discussions
of SSH style acceptance, the notion is to
augment or add the caching of history to the
existing regime.
That's news to me. That's not what I recall reading in numerous
recent posts. In fact, I recall reading about dividing certs into
groups, with one group being certs from unknown issuers, including
self-signed certs, handled by SSH-like techniques alone. A user
only has to slip once, and accept that self-signed cert that claims
to be for his bank once.
First part is technically correct. I used to talk
about self-signed certs because they are a great
thought experiment; anything that is cohesive and
secure should work seamlessly with self-signed certs,
so they form a great test of your security model.
But it seems that they caused more angst than it
was worth, so we don't talk about them anymore. The
goal is security, and the threat is phishing so let's
drop the distractions. Self-signed certs were never
the goal, they are just a tool like any other.
However, second part, it's not correct to say that
the proposals turned off any of the existing protections.
In the chrome display design, the CA is always shown,
just like Bob Relyea said the security folks wanted
it back in the good old days.
For a self-signed cert it says "UNSIGNED" or whatever
scary word you can come up with. For Verisign, it
should ideally show the nice verisign logo (they
probably spent a million bucks on that, so we might
as well use it) and something that says which root
signed it. Preferably one logo per signing root,
so then she gets to see your "high"/"low" assurance
statement in its full meaning: the CA said what it
was.
(These logos should be securely delivered by the
browser in the root list.)
So even if the user slips up and enters the wrong
cert, it tells her every time she uses it. One
day she will notice. Even if she is socially
engineered, one day she'll figure out that the
dodgy ISP MITM is what it says, right there in
front of her.
I guess I'd ask the question: if we trust the CA list for the first
time, why don't we trust it for the second? Could it be that you
don't trust CAs in the trust list?
Then there's my bank's server farm, where each server has its own HSM
and its own cert. SSH doesn't work too well with that.
Right, what Amir said is that once the user has
accepted and signed off on a given CA, then every
cert from that CA is accepted. So the server
farm has to limit itself to using one CA.
(In fact, it breaks the pure "SSH model", because
SSH does not have certs in its basic form, so there
is no way to sign off on a CA. There are options
or plans to add certs to SSH, but that's another
story.)
Now, when the root is attacked, by whatever means,
then that root is now accepted fully and any certs
that the ISP creates will pass through and be accepted.
What we are then left with is the only protection
being the display of the DodgyISPCA name and logo,
and the cert's name and logo as well. Visually,
these will be distinct. One day she'll figure it
out.
(Bear in mind that trademark law stops the dodgy
ISP from copying the logos of well-branded CAs.
If they try that, then you can expect the CAs to
load for bear. And phishers will try and steal
the logos when they attack the root list with
viruses, but this can be addressed by signing in
the longer term.)
Buying merchandise paid for with stolen CC's is not a sustainable
long term business model, because the users detect the theft from
the bogus purchases that appear on their statements.
! Credit card fraud has been runnning at around
0.1 to 1% since ... forever. I'm not sure how
much more sustainable that can get. Any credit
card whizzes here who can give us some figures?
But that's not a single thief doing it over and over, over the course
of years, AFAIK. That's lots of teenagers who frequent "L33T" (elite)
underground bulletin boards, and doing it a couple times before getting
busted. Any evidence to the contrary?
Well, it's both really. In the industry, they have
ways of spotting the newcomers and the experts. The
category of experts is ignored, because they are
too clever and there is no return on chasing them.
I don't know how it is these days, but in the pre-
internet days, anything international was considered
to be expert and was totally ignored.
Also, now, the whole CC and phishing is industrialised.
There are specialisations and no one group does more
than one or two things. The Choicepoint break was
when a group were simply collecting information, as
far as I recall, they were simply passing it on to
the next chain.
Selling info about consumers with large bank balances to merchants
who are not required under law to reveal their sources is a very
sustainable business plan.
Ah. Sure, but mostly they acquire the information
using legal methods. Their existence doesn't mean
that they use illegal methods.
Right. SSL MITM is not inherently illegal, at least not in the USA.
Well, right, if you own the wires, they belong
to you. You can do what you like. The courts
in MA recently affirmed that an ISP can read
email and that's not a crime. If it did anything
with the info, that's a different situation.
(I forget the details, it was a complex case
where a bookseller was acting as an ISP for
other booksellers and reading their mail.)
I know of active MITM proxies operating right now that I dare not
accuse of wrong doing because (a) according to US law, what they're
doing is legal, and (b) I might have to hold them harmless. But that
doesn't mean that mozilla shouldn't protect its users from them.
OK. Now, the old PKI doesn't really defend against
them because once the user is tricked into adding
the root cert, the browser keeps mum and lets the
traffic move. Life's a bitch.
Do you agree that the model that we have been
discussing here actually does address this threat?
That is, put the CA's logo on the chrome - force
the CA into the light and let the user direct her
wrath at the real threat?
I knew a guy who did this; it was all totally legal,
and it was very very legal deliberately, because he
had a lot of enemies who wanted to shut him down.
Only by being very careful was he able to keep going.
Yeah, In the USA, he'd probably be a succesful information broker.
<mmmph> It's not my job to protect Americans from
themselves ;-) But let me suggest that for the most
part, like phishing, data mining is an American problem,
and when it is seen in other countries, it is both
more controllable and more limited in its threat
nature.
Would you call the info collected in my above scenario stolen?
I'm afraid it isn't stolen. It's only stolen if
a crime was committed. The user implicitly and
explicitly gave permission.
However, the fact that it is not stolen does not
say that it is not threatening. In our industry,
we are used to characterising the NSA as a threat,
yet they do not steal.
So I'd call the information collecting via the
ISP root MITM as a threat. Purely and simply,
this is an MITM attack on the browser.
So let's deal with it?
Doesn't the word "stolen" imply law breaking? wrong doing?
Stolen does imply law breaking, but you are yourself
saying that what is done is legal. No law broken.
Wrong doing - that's subjective. That's an expression
of your outrage leading you to assume that the other
guy was wrong. No, what he did was threatening to you,
but you may very well have to put up with it. If it
is legal.
What is fruitless, utterly fruitless is expecting someone
else like the government, the church or Mozilla to protect
you just because you feel "he dun bad!"
Not really. It's been going on for years. Few have noticed, and
some in this newsgroup have even denied that it is going on.
Show us some evidence. I'm very keen to hear it.
Of course you are. I'd say it if I could.
I'd have told you a year ago if I could have.
Here's the problem - back in the early days there
was lots of talk of MITM as "the threat" and this
justified all sorts of things. Yet, there was no
MITM in those days. So it became very difficult
to determine the difference between "there's a
real threat here" and the alternate which was
"some companies want to sell certs". In all that,
the real goal of security disappeared, and you and
I are here trying to clean up the mess.
So, even the existence of proxies - that are agreed
to by the users - falls short of evidence. What is
needed is real fraud, real thefts, real threats.
Only then can we unravell fears from losses. It's
a fact that the NSA collects up lots of Internet
traffic. Do we panic? No, because there are no
losses involved; the NSA knows that it should
never use its info if it wants to keep collecting
it.
Same with the Chinese government and your mythical
broadbrand ISP. It's only when they misuse the
info that they shift from "ok, that could happen"
to "users are taking losses..."
Literally, if there's never been a bust then I
doubt it is going on.
It's Not illegal. People doing legal things don't get busted.
Accusing people who are not law breakers of being law breakers is
a good way to get sued out of your house and life's savings.
Right. That's why I suggest that Mozilla needs to
be very careful not to characterise data mining
as something they've sworn to stop.
We are talking about a billion users of the net, and
millions of merchants ...
Yes, indeed we are. All the more reason for mozilla to be VERY careful
about those trusted CAs.
But, I'm sure you can see now that even the best
CAs can be bypassed? This is the whole point of
your threat as outlined - the CA can be bypassed
and then it matters not what the policy says.
My version of CAs is not so dissimilar - maybe
trust them to sign a cert or two, but who they
are is very important and never ever should be
hidden from the user.
The users run an installer program to get the supplier's "software",
never realizing that they're installing a bogus root cert that
defeats SSL's MITM protections for them. (These schemes primarily
target IE users today, because Windows has an API by which any
little program can install root CA certs silently.)
So ... you're saying that Mozilla should not allow
changes to the root list?
... not allow additions to be made in the field on a running browser.
I think most users would be best served by that policy, yes. Most
users will never in their lives need to add a new CA, or know what a
CA is. Therefore the ability to add a CA is for them mostly risk,
mostly a chance to do the wrong thing.
If the CA properly identifies itself to the user,
wouldn't that be a better solution?
In any case, mozilla's root CA list should never be changed without
the user being actively informed of what's going on and actively
agreeing to it. I believe that's the browser's policy now for
additions being made to the list on the user's running browser.
Well, this is to an extent what TrustBar does, it
starts out with a zero set, and as each root engages,
it encourages the user to accept it. So it adds the
idea of user acceptance on top of the existing root
list and CA chains. Augmentation, so that any
attacks on the CAs themselves or the root list can
be picked up.
doing this stuff. It's really difficult to follow
when we only hear half the picture. I'm still not
clear whether Mozilla defeats this attack or not.
Today, the MITM site's CA is not in mozilla's CA list, and the site
does not offer software to "enhance" mozilla (as they do for IE).
While that remains true, mozilla users are protected. Mozilla users
who use this company's proxy will see a lot of SSL server certs from
unknown issuers. In that way, mozilla protects them. It is exactly
the way that mozilla protects all users from MITM attacks.
Right, ok. But, this is a sideeffect of the fact
that they haven't tried. Obviously, if they managed
to trick users of IE, and they've managed to trick
users into putting their root into the list, then
they can bypass any protections that mozilla can
think of. Trying to stop them by not letting them
into the root list is not going to represent any
great difficulty to them, AFAICS.
Of course, if mozilla users become conditioned (as SSH users are) to
accept and trust new certs on first encounter (which mozilla DOES
let them do, if they want, though I wish it didn't), then they aren't
protected.
Right, so forget SSH. That was an idea and the idea
didn't transmit itself well enough.
Think CA logo on the chrome. If it is SSL, there should
be a CA logo on the chrome. That should present who it
is - identity - who is behind this SSL-protected connnection.
And if this company approaches mozilla and says "look, we have a
webtrust seal, so add our CA cert to your browser", looks to me
like a slam dunk. And the credibility of PKI in mozilla would
promptly go to zero. (I'm not sure that all participants in this
discussion think that's an undesirable outcome).
Yes it would be. But we wouldn't care *IFF* the
CA's logo was on the chrome.
And if Mozilla were to refuse ..... they would simply
perform their chinese engineering tricks on the user
and we'd be left trying to debug a scenario over which
we had no control.
Better actually, perhaps and debatably, to draw them
into the circle and then show the users who they are.
> But fundamentally, if the
user *knows* what is going on, and agrees to carry
on anyway, that's no longer a threat.
If the user KNOWS. I have to agree with that.
Right. Let's tell the user. Better yet, let's have
the browser tell the user.
No, I'm saying these are difficult questions. If the
CA has indicated to its users what it is up to, then
that covers the policy. If it has hidden this from
the users, then that's another issue - that's like
lying, or in legal terms it is a material non-disclosure.
In the US, companies lie to their customers all the time. They get
their customers to sign agreements (contracts) that give them full
power to lie at will. For example, in the agreement, the customer
agrees to give up the right to sue the company, the company disclaims
every advertised promise, feature or capability, and the user agrees
not to hold the company to its word about any of those advertised claims.
Result, no truth-in-advertising suits, despite ongoing false advertising.
For many users, the choices are (a) agree to this, or (b) get no
broadband service from their region's monopoly BB service provider.
Sure. The user is on her own. Can't trust the
company. Can't trust the certs. Can't trust the
CAs? Can she trust the browser?
When it comes down to it, we are not responsible
for protecting the user from her own life. If
she lives in that area, we can only deliver the
tools. Some users are going to be slaughtered.
We shouldn't let that distract us from presenting
the best security tool for the widest majority.
Now part of this issue gets at the definition of a CA. Is every company
that issues certs and has a root CA cert a CA? Even if the owners of the
servers whose DNS names appear in its certs have never heard of it, and
have never asked it to issue them a cert? If they approach mozilla to
have their CA cert added to the root list, what in mozilla policy excludes
it? Let's see ... apparently not webtrust, perhaps not ETSI, hmmm.
Right. Your scenario is correct. If I make a root
and issue certs I am a CA. Any other definition
means we need a judge. And I'm afraid that mozilla
will make a really easy judge to bypass, once it
becomes attractive. Really easy in the worst
possible way, because the enemies you are scared
with can all get webtrusts. The good guys are
people like CACert who have ways of innoculating
themselves from the threats we are afraid of.
It seems to me that a reasonable CA policy would CLEARLY and UNAMBIGUOUSLY
keep such issuers of certs, whose existence is unknown to the servers that
their certs appear to represent, out of the root CA list.
Today Draft 11 does not.
Draft 11 does not. It reflects the claim - disputed
and debatable - that Mozilla does not have the tools,
the smarts, and the money to judge who is a good CA
and who is a bad CA. And a bad CA has the tools, has
the smarts and money, and is quite prepared to lie
about it. Very uneven battle.
Consider this: if the Chinese government came and
instituted the process, they would be accepted. Your
claim is that because they use proxies they shouldn't
be let in.
But, if you didn't know they were using proxies, then
you'd be sunk. That's not a foundation for a policy.
We cannot measure and standardise "are you using
proxies on your customers" as any sort of barrier to
stop bad or good CAs from getting into the root list.
(Recall, the Chinese government has no difficulty in
lying to you. And, same same with an American company
that has decided to also mine its users. No different.)
Although, I recognise that the Chinese government as
a CA is a "potential threat" - it's not one that Mozilla
can reasonably determine objectively as being deniable,
unless we have inside information as to what they are
doing. But we cannot have inside information.
Which is why some people say ... don't trust any CA!
Then, the phisher has to fight a) the fact the cert
will force him to enter into the business loop, and
b) the only easy certs come from some other CA, so
the brand changes on the user's chrome, and c) if
it is a valuable relationship, she may well have
named it specially and locally.
Legit sites who buy certs had better pick wisely on the first try,
because with this scheme, they're never going to be able to change
their CA after their first purchase.
That's an issue. But it's a secondary issue. They
can manage their customers over this changeover.
(Security is the goal...)
Right, exactly. That's what the policy was aiming
at all along - WebTrust or even its equivalents is
not sufficient to conquer this beast; we need some
other stuff.
We need policy that sets a floor on acceptable behavior.
If mozilla doesn't know what is an acceptable floor, what chance do Mom
and Dad mozilla user have of correctly determining what certs to trust?
They'll find help. It will be costly. But they'll
figure it out, everyone knows someone who knows a
little about computers.
What we have to recognise is that Mozilla cannot be the
all-protecting guardian that the original architects
thought it could be. Mozilla cannot detect these bad
behaviours, and it cannot write a policy to stop it.
So Mozilla has to change its own view as to how to
protect users. I say let the users protect themselves,
coz we sure can't protect them, and there ain't no
other guardian angel out there.
And, while that other stuff is coming along, there
isn't much point in holding back the policy in the
vein hope that some silver bullet will come along.
There have been numerous suggestions.
We've batted this around for the last two weeks,
and I haven't seen any objective way of tying user
security to policy.
Forbidding CAs that issue certs without the knowledge of the parties
identified in the certs. Objective. Policy protects user security.
So CA lies "I'd never do that." End of objective test.
Even if you had that test, and a CA was caught, what
are you going to do? Suggest that a CA be kicked out?
Think about it for a moment ... in all practicality,
a CA would have to be run by a joint venture of the
Bush administraion and the El Qaeda before it would
seriously run the danger of being kicked out.
Just wanna make that clear.
Sure! Well, this has been going on for ages. But
what I'm not clear on is why you think the proposals
of branding of the CA logo don't address this?
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
