Re: Symantec Response R
My understanding is that the QuickInvite system doesn't distinguish the reseller from their customer in terms of access to the order. It's not very clear from Symantec's documentation, and Tarah never got back to me in the thread about it, but I think a reseller absolutely can wait for their customer to validate control over example.com successfully and then simply substitute the CSR for one created by the reseller, to get a certificate for example.com with their chosen keys. Unlike scenarios where a web host or DNS provider obtains and installs certificates autonomously on behalf of their customer, using their existing control over the customer's domain to validate, giving a reseller this access feels like an overstep to me, and if I'm right about it I'd like to see Symantec correct this. But I suspect it doesn't breach the BRs as they're written even if it would surprise customers. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response R
On Mon, Apr 10, 2017 at 02:57:41PM +, Steve Medin via dev-security-policy wrote: > 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. What validation level were these certificates issued at? DV, OV, or EV? Was any of the information provided by the reseller used in the issued certificate? I ask this specifically because you state: > 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. However there is no mention of whether a certificate could be issued without proper validation of other information that may be present in a certificate. If these were DV certs, that's all fine and dandy, but there's no indication in your statement as to what validation level certificates issued via the Quick Invite program used. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response R
On Monday, 10 April 2017 20:28:53 UTC+1, michael...@gmail.com wrote: > 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? "certificates that included private keys" would presumably mean PKCS#12 files which consist of one or more certificates plus the private key corresponding to the public key in the leaf certificate. PKCS#12 is a convenient choice for some TLS server software because everything is bundled together. It is not very helpful for end users because it's difficult to reason about it correctly, the certificates are public documents but the private key mustn't be revealed to anyone. >From Symantec's point of view this is a trivial mechanical difference from >delivering just the private key, it's the same data in a different format. So >if they say they never even have private keys I think we shouldn't keep >badgering them about that unless we have evidence to the contrary. The X.509 certificate itself can't include a private key, if that's what Mr Byrne meant then he simply knows nothing about the technology and we should discount his opinion anywhere it goes beyond the presented evidence. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec Response R
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
Re: Symantec Response R
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 < dev-security-policy@lists.mozilla.org> 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Symantec Response R
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
