Sadly, I worry this scenario may not be all that unique. While I have no first had experience or confirmation, some tech notes on WebSense's site indicate they ship with a default root.
See http://www.websense.com/content/support/library/web/v76/wcg_help/c_int_rt.aspxwhich states; "Important The default internal Root CA included with SSL Manager is not unique and should not be used in a production environment. Replace the default Root CA with your organization's existing Root CA or create a new one. See the sections that follow." While they recommend creating a unique root, it's interesting that they ship with a default in the first place rather than generating on install/first boot, or requiring user configuration. I can't be sure (don't have access to Websense gear, and haven't had luck getting a trial), but from this note I suspect that Websense implementations which aren't carefully managed are likely to share a common root. On Tue, Jul 3, 2012 at 5:09 AM, Ben Laurie <[email protected]> wrote: > I thought this might interest the list: > > > Vulnerability in Cyberoam DPI devices [30 Jun 2012] (CVE-2012-3372) > =================================================================== > > Cyberoam make a range of DPI devices (http://www.cyberoamworks.com/) > which are capable of intercepting SSL connections. > > In common with all such devices, in order to intercept these > connections without causing certificate warnings, the devices require > that a certificate must be issued for the intercepted site by a CA > browsers trust. > > There are two ways to achieve this - one is to persaude an existing > trusted CA to issue a certificate for the site to be intecepted, or an > intermediate CA that can then be used to generate new certificates on > the fly. This latter behaviour recently got Trustwave in trouble. > > The second method is to have each willing victim[1] install a new > trusted CA in their browser, and have that CA issue the fake > certificates. This is, of course, the only legitimate way to use these > devices and we are pleased to see that this is the approach Cyberoam > reveal to the public. > > However, it is a little surprising that the Cyberoam devices appear to > all use exactly the same CA. This can be seen to be so by looking at > the support page describing how to avoid warnings: > http://docs.cyberoam.com/default.asp?id=300. Examination of a > certificate chain generated by a Cyberoam device shows that this CA is > not used to sign an intermediate which is then used by the device, and > so therefore 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, 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. > > [1] In the corporate setting, willing victims are often known as > "employees". Unwilling victims should not, of course, install the CA > certificate, nor should they click through certificate warnings. > > Mitigation > ========== > > Victims should uninstall the Cyberoam CA certificate from their > browsers and decline to complete any connection which gives a > certificate warning. > > Credit > ====== > > This issue was discovered and analysed by Runa A. Sandvik of the Tor > Project and Ben Laurie. > _______________________________________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
