Ian Grigg wrote:
We've been in the SSL business for 10 years now, as a community (I don't mean me, as such). Billions or Trillions of events have occurred. Once we get to a certain number, we get enough stats to be able to say things with a fair degree of certainty. We know that the major threats are: spam, viruses, hacking, and soon, phishing. We know that the "didn't happen" threats are eavesdropping and MITM.
No, we know that eavesdropping and MITM have not been widely and publicly reported. We definitely do NOT know they "didn't happen".
Occams razor would suggest they are not happening.
What is it that suggests that they *do* happen?
Here's one I got yesterday:
“Security forces in the US discovered an illegally installed fiber eavesdropping device in Verizon’s optical network. It was placed at a mutual fund company…..shortly before the release of their quarterly numbers” Wolf Report March, 2003
(The securities industry relies primarily on private telco lines for its security.)
Now relate that back to the scientific analysis of the risk of eavesdropping, and how it should be dealt with by Mozilla. Result: 40 bit RC4 with ADH would have defeated that attack.
Anything better would be a bonus, and the MF concerned would be one company that *should* have bought a CA-signed cert and employed SSL to protect its links. And, I'll bet the reason they didn't do *any* of that was because it was too hard.
Believe it or not, MITM is not a defined crime in the USA.
? Thank heavens for that. How would one write a law that said MITM was a crime, but running TCP was not? Phishing is an MITM at one level, but it's a perfectly innocent email at another.
The law actually already has a framework for comparitive frauds, it's called invoice fraud. As long as an invoice fraud includes the words "this is not an invoice" somewhere, then it's not "against the law."
(Space doesn't permit much of an analysis of that, and IANAL anyway, and I'm working from rumour here :) Also, I'm not sure of the US situation, but it is European law, or at least, so I was proudly told by a boastful invoice fraudster once upon a time.)
Think of MITM law as being somewhat harder to write than spam law. Probably not worth doing, IMHO.
If a service provider (ISP, mail service provider, proxy server provider, etc.) has an agreement with all its users that allows it (perhaps in very vague language) to observe and take note of all the traffic that passes through it, then it probably can legally do MITM; AND anyone who would accuse it of wrong doing could be VERY liable for doing so, even if they could prove it. Indeed, I have seen user agreements where the user agrees to hold the service provider harmless from damages arising from the provider's use of the user's data. (!)
Of course. It all makes sense, if one is an ISP. One of course has to do MITMs in order to conduct customer support.
When trying to estimate MITM, don't think of kids doing it, think big time.
I think we can agree on that: MITM is conducted when the target value is large. (So, it is well outside the credit card domain.) That's because it is costly: active, tricky, and leaves tracks.
Also, MITM is generally conducted when the attacker does not care so much if he gets caught. That is, he can avoid any undue costs caused by the loss of secrecy. (If he cared, he wouldn't do an MITM, due to the high risk of being detected.)
That implies (but does not guaruntee) that the attacker is very powerful, and has a whole lot of tools with with to attack. (Or, that the target is very high value, much higher again than the cost of being caught.)
> When your ISP tells you that you must download
and install some software to use their service, well, it would be a good idea to look at your CA lists (IE's and mozilla's) before and after doing so.
There are numerous programs available that claim to observe all the changes an installer program makes to your system, and show them to you or even undo them. I haven't yet seen any that capture root CA list additions.
Occams razor, again.
There's probably a piece missing in this
conversation. Frankly, revocation is considered
to be a highly dubious feature, and not one that
"makes or breaks the system."
I'm sure that that's how consumers and PGP users see it.
I was more thinking of cryptographers and computer scientists.
That's not AT ALL how most enterprise or government IT departments see it.
OK. See my other post - does this rule consideration of revocation outside of today's MF policy question?
Revocation may be a very demanded feature by those institutional customers. But if we can make Frank's workload and the workload of the evaluators to come a bit lighter, that might be helpful!
iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
