Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The Barracuda device doesn't allow you to do anything you couldn't already do with other tools.

However, if an organization were able to get a widely-trusted MitM cert (such as this one http://www.theregister.co.uk/2012/02/09/tustwave_disavows_mi... or this one http://ssl.entrust.net/blog/?p=1696 ) and deployed it on their Barracuda, it could likely be extracted by someone with root-level access.

It wouldn't surprise me to see some "loose nukes" arise out of Barracuda's utterly irresponsible behavior here.



A lot of companies do org-wide MITM CA keys, so just hitting one Barracuda box, stealing the CA key, etc. lets you attack all of that organization's users everywhere.

Generally if you're targeting a specific organization, that's what you care about, anyway. You're not hacking into random companies to build a botnet; you're going after a specific organization to gain some economic or intelligence/military benefit.

I don't know what important organizations use Barracuda, though. It's generally SME-focused. Might be some interesting law firms and other organizations with sensitive data belonging to larger organizations, though.


If one were to get a widely-used SSL-cert, that could be used to MitM any domain ? Or would it only work for specific domains like, this one works for Google and Yahoo, but this one would work for Microsoft?


There are two types of sub-CAs that we could see leak from interception devices that chain to a widely-trusted root:

1. Unconstrained, like the Trustwave and Turktrust examples. These can be used to MitM any domain, with a very few exceptions like Chrome talking to Gmail. This is the normal kind of subCA.

2. Name-constrained sub-CAs such as described here https://groups.google.com/forum/?fromgroups=#!topic/mozilla.... These are very new. They aresupposed to be for organizations (say example.com) that want to issue their certs for www.example.com, intranet.corp.example.com, and so on without using a wildcard cert or paying extra for every single cert.

Neverheless, these private keys can sign MitM certs for any domain, however, whether or not it's valid is in the mind of the client application. Recent versions of the the three major browsers should in theory only accept them for names that sub-CA is approved for. But few if any non-browser SSL/TLS clients recognize these name constraints, so it represents full MitM capable attacker to those clients. Of course, there are a lot of TLS clients that don't validate or even check the subject name on the server cert at all, so many of these apps are pwned anyway.


If you have a signing cert that browsers trust, you can forge a cert for any site (unless your browser has previous knowledge and pinned the right cert for a site).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: