On Tuesday, 20 June 2017 10:43:37 UTC+1, Nick Lamb wrote: > On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman wrote: > > The right balance is probably revoking when misuse is shown. > > Plus education. Robin has stated that there _are_ suitable CA products for > this use case in existence today, but if I didn't know it stands to reason > that at least some of the engineers at Cisco didn't know either. > > Knowing what the Right Thing is makes it easier to push back when somebody > proposes (as they clearly did here) the Wrong Thing. If, at the end of the > day, Cisco management signs off on the additional risk from doing the Wrong > Thing because it's cheaper, or faster, or whatever, that's on them. But if > nobody in their engineering teams is even aware of the alternative it becomes > a certainty.
I'm aware of another instance of this pattern in widely deployed software, discovered through security testing 3rd party applications (Thanks to Hanno discussing related issue on twitter). The pattern "Using a certificate with DNS resolving to 127.0.0.1 to allow a browser page to communicate with a local web server". Although it was done in an insecure fashion (not yet fully resolved, so disclosure would be unhelpful), I don't see a good alternative model for this vendor's use case. I also looked when I first found the encrypted P12 file (and password hardcoded into the application), and found nothing useful online discussing this pattern, or alternatives. I only found that you could no longer register certificates for 127.0.0.1 (the world only needs one such). The mass issuance of certificates described above doesn't seem any better, since there still needs to be a trust relationship with an unprotected appliance or application. Or is there some aspect of the certificates issuance that bind them to a particular implementation (I thought all such binding were basically broken in most TLS implementations). What is the recommended practice here? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
