A couple points of clarification please: 1) Mr. Byrne clarified his post to note that the flaws in the Symantec API would allow: retrieval of certificates that included private keys, not the private keys alone. Was this possible?
2) You say, "it's not technically feasible", which implies present tense. However, Mr. Byrne noted the issues were with the third-party API which was shut down in Nov. 2016. Did you check those old APIs for the flaws he noted? On Monday, April 10, 2017 at 10:59:43 AM UTC-4, Steve Medin wrote: > Issue R: Insecure Issuance API (2013 or earlier - November 2016) > > In April 2015, security consultant Chris Byrne responsibly disclosed two > potential vulnerabilities related to our Quick Invite feature, which enables > a reseller to invite pre-selected customers to enroll for certificates, via > customized emails to the customer that contain deep links for enrollment, > specific to the invitee. Consistent with Symantec's commitment to taking > action when issues arise, Symantec promptly commenced an investigation > following this April 2015 disclosure. As a result, both issues identified in > this disclosure were remediated by May 20, 2015. > > As there currently seems to be some confusion around this disclosure, we want > to provide clarification. First, it is inaccurate to conflate the April 2015 > disclosure and the recent RA topic [Mozilla Issue T]. The Quick Invite > feature is not an issuance API, and is unrelated to the RA delegated > authentication capabilities. > > Second, third-party reporting on Mr. Byrne's March 24, 2017 post has > suggested that private keys were potentially accessible. Not only is this > inaccurate, it's technically not feasible. This is because Symantec does not > have access to our customers' TLS server private keys. > > The first issue identified in this disclosure only occurred in the case that > an invite deep link was intentionally exposed or an attacker had control over > a victim's email account, allowing the attacker to click on that link and > enable submission of a CSR to the reseller as if they were the legitimate > invitee. Even in this scenario, proper domain vetting still happened and the > attacker would have still needed to have ownership or control of the domain > in the attacker's requested cert before the cert would be issued. > Importantly, we do not believe that there was any danger of a cert being > issued without proper demonstration of ownership or control of the domain. > Nevertheless, as a result of this April 2015 disclosure, and consistent with > our effort to continually improve our processes, policies and controls, we > now require manual approval in cases where data reuse rules would have > previously enabled us to issue based on prior approvals. > > The second April 2015 issue was related to the TTL (Time-To-Live) of deep > links associated with certificate lifecycle management for our resellers' > customers. In this case, if the deep link was somehow exposed or the email > account was compromised, an attacker could perform lifecycle operations on > that certificate. While our resellers control the TTL of the Quick Invite > deep link, which can be set to as little as one day, Symantec controls the > TTL of the certificate lifecycle management deep links, which are only sent > to the email address associated with the certificate. We proactively changed > the TTL of these deep links from five days to two hours in order to reduce > the window of exposure in the event the deep links are inappropriately > exposed. In both situations, Symantec responded quickly and decisively to > remediate the issues at hand and to enhance our overall security measures. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
