On Tuesday, June 20, 2017 at 2:27:10 PM UTC-4, mfi...@fortmesa.com wrote: > On Tuesday, June 20, 2017 at 2:06:00 PM UTC-4, Jonathan Rudenberg wrote: > > > On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy > > > <dev-security-policy@lists.mozilla.org> wrote: > > > > > > On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote: > > >> On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via > > >> dev-security-policy wrote: > > >>> If you should find such an issue again in a Cisco owned domain, please > > >>> report it to ps...@cisco.com and we will ensure that prompt and proper > > >>> actions are taken. > > >> > > >> I don't know, this way seems to have worked Just Fine. > > >> > > >> - Matt > > > > > > Does no-one else see the lack of responsible disclosure in this thread > > > distressing? > > > > > > Yes, the cert was revoked, and for all you know during the race that was > > > this public disclosure there could have been compromise. There are APT > > > actors watching this thread right now looking for opportunities. > > > > The disclosure looks responsible to me. > > > > The domain resolves to 127.0.0.1, which means that the private key can only > > be effectively leveraged by a privileged attacker that can forge DNS > > responses. An attacker that can do this can almost certainly also block > > online OCSP/CRL checks, preventing the revocation from being seen by > > clients. In general, revocation will not have any meaningful impact against > > misuse unless the certificate is included in OneCRL/CRLSets (for > > Firefox/Chrome). > > > > Jonathan > > Koen, > Cheers on the find and thanks for your contribution. > > Jonathan, > > Is your argument that TLS checking on session key disclosure is not > necessary because man in the middle is game over? > > You're right there are only very limited ways this sort of thing can be > used (and maybe it can't be used at all). But it would be difficult to argue > effectively that: > > a) It can't be used under specific circumstances to weaken security and > possibly combine with other attacks. > > b) That someone who recognized this for what it was did not reasonably > believe it _shouldn't_ be public knowledge. > > c) I acknowledge your point about the effectiveness of revocation. > > My issue is not in fact with the disclosure at all, but the fact that noone > else on this thread pointed out that it is not the ideal disclosure > methodology (at least in order of events). It's now been said. > > Both Cisco and the CA maintain infosec incident handling teams that are paid > specifically to handle these situations. Yes its true corporate infosec fails > a lot too, but a head start is ethical. > > The culture of our industry needs to think hard about the power it wields so > it is not taken from us and wrapped up in ineffective and burdensome state > oversight.
ps, it was noted previously that if other cisco properties are a bit free wheeling with their cookie security it would be possible to leak. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
