Hi Steve, Tiny nit-picky follow up question. You said: "it's technically not feasible. This is because Symantec does not have access to our customers' TLS server private keys.".
X.509 certificates can of course be used for things besides TLS, when you say "TLS server private keys", is that meant to indicate a contrast with other customer private keys, which Symantec does have access to? Or is it accurate to say that "Symantec does not have access to our customers' private keys"? Thanks, Alex On Mon, Apr 10, 2017 at 10:57 AM, Steve Medin via dev-security-policy < [email protected]> 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
