Security vulnerability found in Cyberoam DPI devices (CVE-2012-3372)
Last week, a user in Jordan reported seeing a fake certificate for torproject.org. The user did not report any errors when browsing to sites such as Gmail, Facebook, and Twitter, which suggests that this was a targeted attack. The certificate was issued by a company called Cyberoam. We first believed that this incident was similar to that of Comodo and DigiNotar, and that Cyberoam had been tricked to issue a fake certificate for our website.
After a bit of research, we learned that Cyberoam make a range of devices used for Deep Packet Inspection (DPI). The user was not just seeing a fake certificate for torproject.org, his connection was actually being intercepted by one of their devices. While investigating this further, Ben Laurie and I found a security vulnerability affecting all Cyberoam DPI devices.
Examination of a certificate chain generated by a Cyberoam DPI device shows that all such devices share the same CA certificate and hence the same private key. It is therefore possible to intercept traffic from any victim of a Cyberoam device with any other Cyberoam device - or to extract the key from the device and import it into other DPI devices, and use those for interception.
Ben and I wrote a security advisory and notified Cyberoam of this vulnerability at 17:00 UTC on Saturday, June 30. We made it clear that we intended to publish this blog post and the security advisory on Tuesday, July 3, and encouraged them to respond promptly if they had any comments. At the same time, we notified browser vendors and asked that they blacklist the Cyberoam CA certificate in their browsers.
Cyberoam have not yet commented on this issue, apart from acknowledging our first email and saying that they are looking into it. The Cyberoam CA certificate is not trusted, and so browsers will show users a warning (unless someone has already installed the certificate). Users with the Tor Browser Bundle are not affected.
To check if this CA is installed in your browser, see the following instructions for Internet Explorer, Firefox, Chrome, and Safari. The instructions mention DigiNotar, but they are still valid. If you have more information about this issue, please email email@example.com.
As I understand it, DNSSEC doesn't protect the confidentiality of data being transmitted between a Web browser and its intended destination, DNSSEC merely ensures that DNS isn't being tainted or otherwise modified. It's SSL, or TLS as it's often ascribed, which does it; but SSL uses a MAC to ensure that the integrity of transmitted data remains intact or unaltered as it is. But it doesn't prevent these devices from does as they're intended; neither will DNSSEC if I'm not otherwise mistaken. It should be said that SSL itself isn't at fault. But should I trust CAs anymore? Or if I create a CA myself, should I trust myself any more than I trust a CA?
The DANE part was the important one... http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/
I thought that I'd confused myself, at least I now know that I've confused myself. Thank you; I'll browse it whenever I've an opportunity to! But I presume that SSL does use a MAC nonetheless? Or is it TCP/IP which ensures integrity of data either transmitted or received?