Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys
> > Yeah OK, I got a few things wrong on my blog post, I can fix that shortly. > It's no big deal. At least I'm informing people about security - claiming > that we're just "looking for hits" is ridiculous. Most people pay no > attention to security, I can't speak for others but I'm trying to inform. > So sorry, but I don't know what you're referring to. Did you tweet me a link to a blog post? Blame Jack if so; all of us are dealing with hugely problematic threading today due to the Twitter @ changes. If you reply here with what you are talking about, I can take a look, though unfortunately I might not be able to get to it today. I always like hearing opposing viewpoints. I feel like Jakob basically covered every other point. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys
> Yep, but there must have been an API (at some level) for generating or > processing the QuickInvite URL. That was what I was suggesting might > have been the issue. So, it's hard for me to answer this question because I didn't see any POC, but 1) it's not physically possible for private keys to be revealed in the interface as described to me and in which I've spent the last few days completely submerged, and 2) there's still the validation process which isn't simply bypassed with this URL. I have to be cautious here in a couple of my answers, and I hope you appreciate why: as soon as I found out Symantec wasn't affected any more by this reseller, I found out who was. I have to responsibly disclose that information first and get a confirmation from them. I've already notified everyone I had contact info for there, and I'll stay on them. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys
On Friday, March 31, 2017 at 9:51:03 AM UTC-7, Jakob Bohm wrote: > Dear Tarah, > > Below some friendly speculation as to what the parts that some bloggers > claimed was included (if those claims were somehow true) might have > been (i.e. where *you* might look for it in internal Symantec > systems/records). > > Thank you. > > Did Symantec ever offer Symantec-generated private keys (e.g. PKCS#12 > files) via that or a similar mechanism? That would explain the > "private key" claim without an additional PoC. That was available for 1 or 2 customers, but it was not via the QuickInvite interface . It took a downloaded Java app (dear lord) to make that happen, and my belief is that this practice ended around the same time as this initial report but was not related to this issue. I don't think anyone can do this anymore, and I'll follow up on that too, but even in that case, we would never have seen their private keys. Resellers should never have had the ability to generate key pairs and CSRs and if they said they did to Chris, I'm furious. > Could this be about some other URLs in the (now hopefully closed) RA > interface? Such as an interface for requesting the QuickInvite URL for > later forwarding to the subscriber? > > Perhaps an interface that takes only "known/guessable" parameters, such > as subscriber e-mail or order number? This would explain the claim > that an URL sent to one subscriber by an incompetent RA could be > edited to retrieve the data for another subscriber. > Nope. That QuickInvite URL was/is hashed and salted. I have personally seen the code for generating it. Just editing stuff in that URL without being able to crack it wouldn't give any useful information or lead anywhere. Although now I'm kinda wanting to create a specific error page for people who try. Nah. It'd be funny to me and anyone trying to hack those but the customers wouldn't get my jokes, likely. Brute forcing the URL would take too long, which is why I agree with the original decision to decrease the URL validity timespan. It helps prevent brute force attacks too. Also, just was chatting with Chris. I just found out that the reseller in question was dropped from our Symantec a while back. Details to follow, but suffice to say that they are no longer a problem for us. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Notice of Intent to Deprecate and Remove: Trust in Symantec-issued Certificates
On Thursday, March 23, 2017 at 12:09:23 PM UTC-4, Ryan Sleevi wrote: > (Posting in a Google Capacity) > > I just wanted to notify the members of this Forum that we have started an > Intent to Deprecate and Remove, consistent with our Blink process, related to > certain certificates issued by Symantec Corporation. > > This is a proposed plan, not a final commitment, and we welcome all feedback > from members of this Forum to understand the risks and challenges. To > understand the goals of this process, you can find more details at > https://www.chromium.org/blink > > You can participate in this discussion at > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs What will be the process for critical infrastructure such as medical devices and payment systems when they're affected by this? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
