Cyberoam Packet Inspection Devices Open Traffic To Third Parties 29
New submitter jetcityorange tipped us to a nasty security flaw in Cyberoam packet inspection devices. The devices are used by employers and despotic governments alike to intercept communications; in the case of employers probably for relatively mundane purposes (no torrenting at work). However, the CA key used to issue fake certificates so that the device can intercept SSL traffic is the same on every device, allowing every Cyberoam device to intercept traffic that passed through any other one. But that's not all: "It is therefore possible to intercept traffic from any victim of a
Cyberoam device with any other Cyberoam device - or, indeed, to
extract the key from the device and import it into other DPI devices,
and use those for interception. Perhaps ones from more competent
vendors."
Why should they be competent (Score:4)
after all their clients are either incompetent or evil....
What would be really interesting would be a simple consumer level tool to detect DPI with crypto interception...
So at least you know how much your ISP loves you....
Re:Why should they be competent (Score:5, Funny)
I do apologize, I should have written something real useful like "first post", but it is the first time it happens to me, so I forgot :)
Re: (Score:2)
Re:Why should they be competent (Score:5, Interesting)
The most interesting aspect of this story, NOT HIGHLIGHTED IN THE SUMMARY, is that this was discovered by volunteers on the TOR project - and was being used as a compromise of a TOR node.
Re: (Score:2)
Just use a browser. Theoretically your ISP could intercept all the ways you could acquire a browser over their network and install their cert in each, but you could use a browser acquired elsewhere. Then go to any secure site and if you get a certificate warning, be suspicious.
Re: (Score:2)
after all their clients are either incompetent or evil....
What would be really interesting would be a simple consumer level tool to detect DPI with crypto interception...
So at least you know how much your ISP loves you....
Well the fake certificates will only work if you trust the certificate the box is using to generate the fakes. Seems rather trivial to check your root/trusted certificates, eh?
Re: (Score:2)
well the typical consumer has clicked: yes, yes, yes, yes ... a couple of month ago...
And does not understand how any of this works...
So a tools that tells him or her ... "I see a spy siting about ==> here" sniffing your youtube/facebook/etc... transaction would be :
more helpful than being satisfied that you can
If you use firefox do Edit/Preferences/Advanced/View certificate and see if any seems suspicious, btw it could probably even be called something like "Best Verisign for Trust in Your Region" or "Z
Re: (Score:2)
If you're using IE, just click the little padlock and see who signed the certificate. In firefox, you click to the left of the URL. Of course it's a few more clicks to see the actual chain. FF also shows you the intermediate cert and not the root like IE.
You're probably right though, that some quick utility to make it idiot proof would be helpful.
This is suprising? (Score:5, Insightful)
Re: (Score:2)
Why aren't browsers warning against certificates signed by this bad keychain ? They should all ban them.
Re:This is suprising? (Score:4, Informative)
Derp! (Score:5, Insightful)
Re: (Score:1)
As long as you really know who you are communicating with. And as long as the whole network supports all the weird NAT out there. And as long as you really have it configured right. Oh never mind.
>A good indication that something is secure is that laws are passed against its use.
Thats some mighty secure methamphetamine you got there...
They have to inject the cert first (Score:4, Informative)
I don't think this is a cert issuer trusted by major browsers. Unless some "toolbar" or a corporate installation has managed to put this cert into your browser (which happens), this attack may be ineffective against browsers.
Dual SSL certification anyone? (Score:2)
Re: (Score:2)
FILENAME=server
openssl genrsa -out $FILENAME.key 1024
openssl req -new -key $FILENAME.key -x509 -days 3653 -out $FILENAME.crt
cat $FILENAME.key $FILENAME.crt >$FILENAME.pem
chmod 600 $FILENAME.key $FILENAME.pem
FILENAME=client
openssl genrsa -out $FILENAME.key 1024
openssl req -new -key $FILENAME.key -x509 -days 3653 -out $FILENAME.crt
cat $FILENAME.key $FILENAME.crt >$FILENAME.pem
chmod 600 $FILENAME.key $FILENAME.pem
CLIENT SIDE
Re: (Score:2)
Only a very tiny percentage of traffic on the web uses client authentication. Yes, it is secure. But if you have a lot of clients then certificate management becomes a major issue.
CA trust injection via Active Directory (Score:2)
Re: (Score:2)
Yes, but you push your own root certificate form your own CA. Then you generate the remote server certificates using that or a subordinate CA. What you don't do is use some certificate that came on your SSL intercept box, because if you do the private key is um, not private. If your SSL intercept solution does not allow you to setup your own trusted root find a new one.
This is whole problem is one born of simple incompetence.