There's more than just a clue in the name drmlocal.cisco.com , if one looks up this address in the DNS it returns the loopback IP 127.0.0.1 . http://dnstools.ws/tools/lookup.php?host=drmlocal.cisco.com&type=A This can only mean that this address is fully intended to be referred to only by one's own machine that the NowTV software is running on. There's probably an architectural reason why a publicly trusted certificate is used. But the way it's been implemented clearly does mean that the private key ends up being shipped, which, even if it didn't break the Baseline Requirements, it goes against the very principle of PKI cryptography. Therefore the newly re-issued certificate *will* end up with it's private key compromised *again*, no matter how well it may be obfuscated in the application, it is still against the very principle. Is a publicly-trusted certificate even needed here? Another this could have been done is what anti-virus programs often resort to doing: installing a self-signed root into the OS (and other browser stores) as part of the client installation process and generating certificates on-the-fly directly off of it. But then that would mean that if anyone compromised the key for that, it could potentially put many users whom use NowTV at risk unless that self-signed root was constrained in some way. *However* this would mean at least, it no longer breaks the Baseline Requirements as it would no longer be within it's scope. I'm no expert here at all, and I do dislike the idea of this kind of behaviour completely (and I could be completely wrong about why drmlocal.cisco.com is used). NowTV might want to consider their options here, but shipping a private key and trusted certificate with an application, really isn't the way. In summary: I believe a compromise will happen again as it is clear drmlocal.cisco.com is deliberately intended to refer to one's own machine. Sam
On Mon, Jun 19, 2017 at 1:50 PM, Nick Lamb via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com wrote: >> The compromised certificate for drmlocal.cisco.com serial number >> 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate >> is being reissued to drmlocal.cisco.com and we will work with the developers >> of the YES video player to ensure that the issue does not happen again. > > Troy, the name makes me suspicious, what - other than this trick which isn't > a permissible use - was the drmlocal.cisco.com name ever for in the first > place? If it doesn't have any legitimate use, there was no purpose in seeking > a re-issue of the certificate. > > The right way to approach this problem will be to issue unique keys and > certificates to individual instances of the system, this both satisfies the > BRs and (which is why) achieves the actual security goal of partitioning each > customer so that they can't MitM each other. > > It is a little surprising to me that (at least so far as I know) no > manufacturer has an arrangement with a CA to issue them large volumes of > per-device certificates in this way. I expect that Comodo (to name one which > definitely has business issuing very large volumes) would be able to > accommodate a deal to issue say, a million certificates per year with an > agreed suffix (say, .nowtv.cisco.com) for a fixed fee. The first time it's > attempted there would be some engineering work to be done in production and > software for the system, but nothing truly novel and that work is re-usable > for future products. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
