Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cyberoam Packet Inspection Devices Open Traffic To Third Parties

Unknown Lamer posted more than 2 years ago | from the security-through-oh-screw-it dept.

Networking 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."

Sorry! There are no comments related to the filter you selected.

Why should they be competent (3)

Coeurderoy (717228) | more than 2 years ago | (#40542787)

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 (4, Funny)

Coeurderoy (717228) | more than 2 years ago | (#40542799)

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:Why should they be competent (1)

houstonbofh (602064) | more than 2 years ago | (#40542835)

First time I have seen 3 posts before a "Frist Psots!!!"

Re:Why should they be competent (4, Interesting)

Jeremiah Cornelius (137) | more than 2 years ago | (#40542897)

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:Why should they be competent (0)

Anonymous Coward | more than 2 years ago | (#40550209)

I see no evidence that this was an attempt to compromise a TOR node. It sounds more like a TOR (and HTTPS-Everywhere???) user in Jordan noticed, due to browser-plugin reported SSL certificate anomalies and with assistance of the TOR team, that his ISP was using Cyberoam devices to intercept SSL traffic. I imagine this ISP monitor the SSL connections of all its users, not just the TOR using ones.

So the situation is more likely that Jordan monitors the communication of its citizens. Not a nice thing, but it is a well known fact.

Re:Why should they be competent (1)

russotto (537200) | more than 2 years ago | (#40543685)

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....

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:Why should they be competent (1)

fluffy99 (870997) | more than 2 years ago | (#40545155)

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:Why should they be competent (1)

Coeurderoy (717228) | more than 2 years ago | (#40545621)

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 "ZTCK s.r.l Switerland" ...

And unless you are quite IT competent it is close to useless...

Re:Why should they be competent (1)

fluffy99 (870997) | more than 2 years ago | (#40545909)

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? (4, Insightful)

houstonbofh (602064) | more than 2 years ago | (#40542813)

People are surprised that a device that hacks it's way in to ssl communication is insecure? Contrary to popular belief, people that specialise in tearing down walls are not the best wall builders.

Re:This is suprising? (1)

PIBM (588930) | more than 2 years ago | (#40542825)

Why aren't browsers warning against certificates signed by this bad keychain ? They should all ban them.

Re:This is suprising? (3, Informative)

houstonbofh (602064) | more than 2 years ago | (#40542845)

It is part of a egress filter. If you do not accept the cert, you just do not get out...

Re:This is suprising? (0)

Anonymous Coward | more than 2 years ago | (#40543137)

I was wondering about this too. It seems like... if you add this "egress certificate", then by definition they can snoop on you. You know you don't have a private channel as soon as you add it.

There are ways to establish a private channel over a non-private channel, of course, but that won't generally be possible with any random web site.

Re:This is suprising? (0)

Anonymous Coward | more than 2 years ago | (#40542875)

I didn't rtfa but I think you have to import the fake ca into your browser before it will work.

Companies will just preinstall the ca on desktops.

Re:This is suprising? (0)

Anonymous Coward | more than 2 years ago | (#40543569)

The browser normally does warn you. I have been seeing invalid certs for a month now. In fact I just got a bad cert for torproject.org when clicking on the first link.

I predict some kind of attack in the next six months.

Derp! (4, Insightful)

girlintraining (1395911) | more than 2 years ago | (#40542935)

This just in: End to end encryption which does not form trust via a third party (like a certificate authority) still the best way of securing communications. The certificate authority system has been flawed from day one. IPSEC is still the way to go, along with secure DNS, but as you will note... companies and governments have been dragging their feet on it. A good indication that something is secure is that laws are passed against its use.

Re:Derp! (1)

Alimony Pakhdan (1855364) | more than 2 years ago | (#40546699)

>IPSEC is still the way to go
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 (3, Informative)

Animats (122034) | more than 2 years ago | (#40542997)

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.

Re:They have to inject the cert first (0)

Anonymous Coward | more than 2 years ago | (#40543485)

That's quite beside the point. These are devices that are used on managed networks, where the admins add the certificate to all computers and browsers, so that the traffic between "their network" and the whole wide world can be intercepted without disallowing encryption. The problem is that all these interception boxes use the same certificate. So now anyone who has access to one of these boxes can use this certificate to decrypt any data which is sent to/from networks where the admins installed one too. This is entirely unnecessary, since the certificate is self-signed anyway and could be different for every company. The interception box doesn't need to (and shouldn't) come preinstalled with a certificate at all. The way to get a certificate on these things should be that the admin presses a button to generate a new one or load one from a USB stick.

Dual SSL certification anyone? (1)

stanlyb (1839382) | more than 2 years ago | (#40543003)

I fail to see how this device would intercept my dual certificate handshaking, but also WHY no everyone out there thinks that one-way SSL certification makes your connection secure!!!

Re:Dual SSL certification anyone? (1)

stanlyb (1839382) | more than 2 years ago | (#40543101)

Or if i want to make myself clear, here is one sample:
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:
socat stdio openssl-connect:server.domain.org:4433,cert=$HOME/etc/client.pem,cafile=$HOME/etc/server.crt

SERVER SIDE:
socat openssl-listen:4433,reuseaddr,cert=$HOME/etc/server.pem,cafile=$HOME/etc/client.crt echo


VOILA. Now i would give anyone 2 cents if he manages to sniff my connection with this little tiny device...

Re:Dual SSL certification anyone? (1)

durdur (252098) | more than 2 years ago | (#40543647)

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.

Re:Dual SSL certification anyone? (0)

Anonymous Coward | more than 2 years ago | (#40554669)

I fail to see how this device would intercept my dual certificate handshaking, but also WHY no everyone out there thinks that one-way SSL certification makes your connection secure!!!

Because not everyone is a fucking nerd with no life outside of their computer.

dude i got hella diarrea (0)

Anonymous Coward | more than 2 years ago | (#40543019)

also: fuck verizon

NetVCR (0)

Anonymous Coward | more than 2 years ago | (#40543039)

The flaws in Niksuns NetVCR/NetDLive are worse!

How do you protect against SSL MITM attacks? (0)

Anonymous Coward | more than 2 years ago | (#40543083)

How do you protect yourself against rogue CAs that issue "legit" certs that raise no warnings in browsers? Most people have no way of knowing who the issuer of their bank's cert is. Same goes for email... some rogue CA can issue a mail.google.com cert and someone can perform a MITM attack.

Is there a way to protect yourself against this?

CA trust injection via Active Directory (1)

ei4anb (625481) | more than 2 years ago | (#40543633)

Most companies that do this type of SSL inspection at their Internet gateways can get Internet Explorer (and such companies often standardize on IE) on the user's PCs to trust the fake certificate by pushing the fake Certificate Authority Root Cert through their Active Directory.

Re:CA trust injection via Active Directory (1)

DarkOx (621550) | more than 2 years ago | (#40544471)

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.

vanchuyenquocte.com (-1, Troll)

lienbien (2677419) | more than 2 years ago | (#40548965)

van chuyen hang di My, Uc, chau Au, Phap, Anh, Duc, Nhat, Canada, Han Quoc, Sin gia re Marilink Logistics chuyen giao nhan hang hoa Quoc Te, van chuyen quoc te, van tai quoc te bang Duong Bien va Hang Khong den cac quoc gia tren the gioi voi gia ca canh tranh nhat. Lien he: www.vanchuyenquocte.com
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?