RE: AlwaysOnSSL web security issues
Here's the article we published on this subject a while ago: https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practices/ -Tim > -Original Message- > From: dev-security-policy > On Behalf Of Jeremy Rowley via dev-security-policy > Sent: Thursday, January 10, 2019 4:47 PM > To: Wayne Thayer > Cc: Alex Cohn ; Alex Gaynor ; > mozilla-dev-security-pol...@lists.mozilla.org; Buschart, Rufus > ; Hanno Böck > Subject: RE: AlwaysOnSSL web security issues > > Yes – we will do so. We’ve encouraged all customers to not generate key > pairs for TLS certs on behalf of third parties in the past. A reminder would > be > useful. > > From: Wayne Thayer > Sent: Thursday, January 10, 2019 1:18 PM > To: Jeremy Rowley > Cc: Alex Gaynor ; Buschart, Rufus > ; Alex Cohn ; Hanno > Böck ; mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: AlwaysOnSSL web security issues > > Thanks Jeremy. The fact that CertCenter is just a reseller and not an RA was > not obvious to me. To your point, building an insecure website on top of a > CA's API does not strike me as something that we should be terribly worried > about. > > I would encourage DigiCert to ask CertCenter to discontinue the practice of > generating private keys for their customers. > > - Wayne > > On Thu, Jan 10, 2019 at 11:00 AM Jeremy Rowley via dev-security-policy > mailto:dev-security- > pol...@lists.mozilla.org>> wrote: > A couple of thoughts: > 1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted > and operated by DigiCert. All validation, issuance, and linting is performed > by > DigiCert prior to issuance. > 2) Lots of cert customers have insecure websites. This indicates CAs should > scan websites for vulnerabilities. If that's the case, there will be lots of > revocations and that needs to be built into the Mozilla policy if required. > 3) The only way we know that CertCenter is a reseller is by > self-identification. > They use the same issuance and validation system as all other customers. If > they didn't self-identify as a reseller, they could do the same thing and look > like an enterprise. > 4) I think they took their website down once the vulnerability was reported. > We've asked them to fix the site because it's high profile. However, if the > customer was something like Mozilla or Google, would we demand > revocation of their certificates? Granted, they wouldn't have the same > vulnerabilities, but I'm having a hard time differentiating from the CA > perspective. > 5) Generating private keys for third parties is definitely NOT encouraged by > DigiCert. > > Anyway, I'm not sure what do here as it seems like the main difference > between this and any other insecure website is how they self-identify. > > Jeremy > > -Original Message- > From: dev-security-policy boun...@lists.mozilla.org<mailto:dev-security-policy- > boun...@lists.mozilla.org>> On Behalf Of Alex Gaynor via dev-security- > policy > Sent: Thursday, January 10, 2019 7:10 AM > To: Buschart, Rufus > mailto:rufus.busch...@siemens.com>> > Cc: Alex Cohn mailto:a...@alexcohn.com>>; mozilla- > dev-security-policy@lists.mozilla.org<mailto:mozilla-dev-security- > pol...@lists.mozilla.org>; Hanno Böck > mailto:ha...@hboeck.de>> > Subject: Re: AlwaysOnSSL web security issues > > The Mozilla policy does not prohibit backdating, except when it's used to > evade time-based policy controls. > > Backdating certs by a few hours is a relatively common practice to minimize > breakages for consumers with busted clocks. > > Alex > > On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy < > dev-security-policy@lists.mozilla.org<mailto:dev-security- > pol...@lists.mozilla.org>> wrote: > > > The certificate [1] seems also to be 'back-dated' by about 18 hours. > > What is Mozillas opinion about this in the light of > > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdat > > ing_the_notBefore_Date > > ? > > > > > It appears AlwaysOnSSL is not completely disabled - if we trust CT > > > as a > > timestamping service, [1] was issued after Hanno's email. > > [...] > > > [1] https://crt.sh/?id=1097197338 > > [...] > > > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy < > > dev-security-policy@lists.mozilla.org<mailto:dev-security- > pol...@lists.mozilla.org>> wrote: > > > > > > > > Hi, > > > > > > > > AlwaysOnSSL was a free certificate authority operated by CertCenter. > > > > I recently noticed that their
RE: AlwaysOnSSL web security issues
Yes – we will do so. We’ve encouraged all customers to not generate key pairs for TLS certs on behalf of third parties in the past. A reminder would be useful. From: Wayne Thayer Sent: Thursday, January 10, 2019 1:18 PM To: Jeremy Rowley Cc: Alex Gaynor ; Buschart, Rufus ; Alex Cohn ; Hanno Böck ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: AlwaysOnSSL web security issues Thanks Jeremy. The fact that CertCenter is just a reseller and not an RA was not obvious to me. To your point, building an insecure website on top of a CA's API does not strike me as something that we should be terribly worried about. I would encourage DigiCert to ask CertCenter to discontinue the practice of generating private keys for their customers. - Wayne On Thu, Jan 10, 2019 at 11:00 AM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: A couple of thoughts: 1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted and operated by DigiCert. All validation, issuance, and linting is performed by DigiCert prior to issuance. 2) Lots of cert customers have insecure websites. This indicates CAs should scan websites for vulnerabilities. If that's the case, there will be lots of revocations and that needs to be built into the Mozilla policy if required. 3) The only way we know that CertCenter is a reseller is by self-identification. They use the same issuance and validation system as all other customers. If they didn't self-identify as a reseller, they could do the same thing and look like an enterprise. 4) I think they took their website down once the vulnerability was reported. We've asked them to fix the site because it's high profile. However, if the customer was something like Mozilla or Google, would we demand revocation of their certificates? Granted, they wouldn't have the same vulnerabilities, but I'm having a hard time differentiating from the CA perspective. 5) Generating private keys for third parties is definitely NOT encouraged by DigiCert. Anyway, I'm not sure what do here as it seems like the main difference between this and any other insecure website is how they self-identify. Jeremy -Original Message- From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org>> On Behalf Of Alex Gaynor via dev-security-policy Sent: Thursday, January 10, 2019 7:10 AM To: Buschart, Rufus mailto:rufus.busch...@siemens.com>> Cc: Alex Cohn mailto:a...@alexcohn.com>>; mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>; Hanno Böck mailto:ha...@hboeck.de>> Subject: Re: AlwaysOnSSL web security issues The Mozilla policy does not prohibit backdating, except when it's used to evade time-based policy controls. Backdating certs by a few hours is a relatively common practice to minimize breakages for consumers with busted clocks. Alex On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: > The certificate [1] seems also to be 'back-dated' by about 18 hours. > What is Mozillas opinion about this in the light of > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdat > ing_the_notBefore_Date > ? > > > It appears AlwaysOnSSL is not completely disabled - if we trust CT > > as a > timestamping service, [1] was issued after Hanno's email. > [...] > > [1] https://crt.sh/?id=1097197338 > [...] > > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy < > dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> > wrote: > > > > > > Hi, > > > > > > AlwaysOnSSL was a free certificate authority operated by CertCenter. > > > I recently noticed that their main webpage was gone, but pieces of > > > the service were still online. > > > I immediately found a few web security issues. I reported those to > > > certcenter and digicert (which is the root CA their intermediate > > > chains to). > [...] > > > In response to this the service was completely disabled. > [...] > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org<mailto: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<mailto: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<mailto: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
Re: AlwaysOnSSL web security issues
Thanks Jeremy. The fact that CertCenter is just a reseller and not an RA was not obvious to me. To your point, building an insecure website on top of a CA's API does not strike me as something that we should be terribly worried about. I would encourage DigiCert to ask CertCenter to discontinue the practice of generating private keys for their customers. - Wayne On Thu, Jan 10, 2019 at 11:00 AM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A couple of thoughts: > 1) CertCenter is not a CA or RA. They have a custom named ICA that is > hosted and operated by DigiCert. All validation, issuance, and linting is > performed by DigiCert prior to issuance. > 2) Lots of cert customers have insecure websites. This indicates CAs > should scan websites for vulnerabilities. If that's the case, there will be > lots of revocations and that needs to be built into the Mozilla policy if > required. > 3) The only way we know that CertCenter is a reseller is by > self-identification. They use the same issuance and validation system as > all other customers. If they didn't self-identify as a reseller, they could > do the same thing and look like an enterprise. > 4) I think they took their website down once the vulnerability was > reported. We've asked them to fix the site because it's high profile. > However, if the customer was something like Mozilla or Google, would we > demand revocation of their certificates? Granted, they wouldn't have the > same vulnerabilities, but I'm having a hard time differentiating from the > CA perspective. > 5) Generating private keys for third parties is definitely NOT encouraged > by DigiCert. > > Anyway, I'm not sure what do here as it seems like the main difference > between this and any other insecure website is how they self-identify. > > Jeremy > > -Original Message- > From: dev-security-policy > On Behalf Of Alex Gaynor via dev-security-policy > Sent: Thursday, January 10, 2019 7:10 AM > To: Buschart, Rufus > Cc: Alex Cohn ; > mozilla-dev-security-pol...@lists.mozilla.org; Hanno Böck > > Subject: Re: AlwaysOnSSL web security issues > > The Mozilla policy does not prohibit backdating, except when it's used to > evade time-based policy controls. > > Backdating certs by a few hours is a relatively common practice to > minimize breakages for consumers with busted clocks. > > Alex > > On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > The certificate [1] seems also to be 'back-dated' by about 18 hours. > > What is Mozillas opinion about this in the light of > > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdat > > ing_the_notBefore_Date > > ? > > > > > It appears AlwaysOnSSL is not completely disabled - if we trust CT > > > as a > > timestamping service, [1] was issued after Hanno's email. > > [...] > > > [1] https://crt.sh/?id=1097197338 > > [...] > > > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > > Hi, > > > > > > > > AlwaysOnSSL was a free certificate authority operated by CertCenter. > > > > I recently noticed that their main webpage was gone, but pieces of > > > > the service were still online. > > > > I immediately found a few web security issues. I reported those to > > > > certcenter and digicert (which is the root CA their intermediate > > > > chains to). > > [...] > > > > In response to this the service was completely disabled. > > [...] > > ___ > > 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 > ___ > 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
Re: AlwaysOnSSL web security issues
On 10/01/2019 19:00, Jeremy Rowley wrote: > A couple of thoughts: > 1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted > and operated by DigiCert. All validation, issuance, and linting is performed > by DigiCert prior to issuance. > 2) Lots of cert customers have insecure websites. This indicates CAs should > scan websites for vulnerabilities. If that's the case, there will be lots of > revocations and that needs to be built into the Mozilla policy if required. > 3) The only way we know that CertCenter is a reseller is by > self-identification. They use the same issuance and validation system as all > other customers. If they didn't self-identify as a reseller, they could do > the same thing and look like an enterprise. > 4) I think they took their website down once the vulnerability was reported. > We've asked them to fix the site because it's high profile. However, if the > customer was something like Mozilla or Google, would we demand revocation of > their certificates? Granted, they wouldn't have the same vulnerabilities, but > I'm having a hard time differentiating from the CA perspective. > 5) Generating private keys for third parties is definitely NOT encouraged by > DigiCert. > > Anyway, I'm not sure what do here as it seems like the main difference > between this and any other insecure website is how they self-identify. > There's also the CA observable fact that they use their SubCA to issue for other organizations. This presumably involves different contract terms from an Enterprise SubCA only licensed for internal use in that Enterprise. Admittedly, an Enterprise-licensed SubCA "owner" could cheat and issue DV certificates that carry the Enterprise name in the DN even though the domains are unrelated 3rd parties. That could be difficult to detect, but would presumably be a contract violation. Another case that would be hard for a CA to distinguish would be a hosting provider SubCA controlled by someone like Amazon or Google, as those would actually generate the keys (for use on their own servers to serve customer domains). Here contract terms would be the only clear distinction, short of an audit of issued certificates versus who hosts the IP addresses using those certs. Of cause I don't know if Digicert makes those distinctions in their SubCA contract terms, or if you made those distinctions when CertCenter signed up. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: AlwaysOnSSL web security issues
A couple of thoughts: 1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted and operated by DigiCert. All validation, issuance, and linting is performed by DigiCert prior to issuance. 2) Lots of cert customers have insecure websites. This indicates CAs should scan websites for vulnerabilities. If that's the case, there will be lots of revocations and that needs to be built into the Mozilla policy if required. 3) The only way we know that CertCenter is a reseller is by self-identification. They use the same issuance and validation system as all other customers. If they didn't self-identify as a reseller, they could do the same thing and look like an enterprise. 4) I think they took their website down once the vulnerability was reported. We've asked them to fix the site because it's high profile. However, if the customer was something like Mozilla or Google, would we demand revocation of their certificates? Granted, they wouldn't have the same vulnerabilities, but I'm having a hard time differentiating from the CA perspective. 5) Generating private keys for third parties is definitely NOT encouraged by DigiCert. Anyway, I'm not sure what do here as it seems like the main difference between this and any other insecure website is how they self-identify. Jeremy -Original Message- From: dev-security-policy On Behalf Of Alex Gaynor via dev-security-policy Sent: Thursday, January 10, 2019 7:10 AM To: Buschart, Rufus Cc: Alex Cohn ; mozilla-dev-security-pol...@lists.mozilla.org; Hanno Böck Subject: Re: AlwaysOnSSL web security issues The Mozilla policy does not prohibit backdating, except when it's used to evade time-based policy controls. Backdating certs by a few hours is a relatively common practice to minimize breakages for consumers with busted clocks. Alex On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The certificate [1] seems also to be 'back-dated' by about 18 hours. > What is Mozillas opinion about this in the light of > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdat > ing_the_notBefore_Date > ? > > > It appears AlwaysOnSSL is not completely disabled - if we trust CT > > as a > timestamping service, [1] was issued after Hanno's email. > [...] > > [1] https://crt.sh/?id=1097197338 > [...] > > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > > Hi, > > > > > > AlwaysOnSSL was a free certificate authority operated by CertCenter. > > > I recently noticed that their main webpage was gone, but pieces of > > > the service were still online. > > > I immediately found a few web security issues. I reported those to > > > certcenter and digicert (which is the root CA their intermediate > > > chains to). > [...] > > > In response to this the service was completely disabled. > [...] > ___ > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AlwaysOnSSL web security issues
The Mozilla policy does not prohibit backdating, except when it's used to evade time-based policy controls. Backdating certs by a few hours is a relatively common practice to minimize breakages for consumers with busted clocks. Alex On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The certificate [1] seems also to be 'back-dated' by about 18 hours. What > is Mozillas opinion about this in the light of > https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date > ? > > > It appears AlwaysOnSSL is not completely disabled - if we trust CT as a > timestamping service, [1] was issued after Hanno's email. > [...] > > [1] https://crt.sh/?id=1097197338 > [...] > > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > > Hi, > > > > > > AlwaysOnSSL was a free certificate authority operated by CertCenter. > > > I recently noticed that their main webpage was gone, but pieces of the > > > service were still online. > > > I immediately found a few web security issues. I reported those to > > > certcenter and digicert (which is the root CA their intermediate > > > chains to). > [...] > > > In response to this the service was completely disabled. > [...] > ___ > 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
AW: AlwaysOnSSL web security issues
The certificate [1] seems also to be 'back-dated' by about 18 hours. What is Mozillas opinion about this in the light of https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date ? > It appears AlwaysOnSSL is not completely disabled - if we trust CT as a > timestamping service, [1] was issued after Hanno's email. [...] > [1] https://crt.sh/?id=1097197338 [...] > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy > wrote: > > > > Hi, > > > > AlwaysOnSSL was a free certificate authority operated by CertCenter. > > I recently noticed that their main webpage was gone, but pieces of the > > service were still online. > > I immediately found a few web security issues. I reported those to > > certcenter and digicert (which is the root CA their intermediate > > chains to). [...] > > In response to this the service was completely disabled. [...] ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: AlwaysOnSSL web security issues
Hi, It appears AlwaysOnSSL is not completely disabled - if we trust CT as a timestamping service, [1] was issued after Hanno's email. I believe AlwaysOnSSL has at least two separate paths to issuance - in addition to the website, there's also an API on CertCenter's website. [2] While reading the API docs, I noticed a "generatePrivateKey" option; a quick read of their client API example code indicates CertCenter is generating keys server-side for their customers. I had hoped that after the Trustico debacle resellers would have discontinued this practice. While I welcome the availability of free and low-cost certificates, I share Hanno's concern about CertCenter/AlwaysOnSSL. Alex [1] https://crt.sh/?id=1097197338 [2] https://api.certcenter.help/docs/tutorial-integrate-alwaysonssl On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy wrote: > > Hi, > > AlwaysOnSSL was a free certificate authority operated by CertCenter. > I recently noticed that their main webpage was gone, but pieces of the > service were still online. > I immediately found a few web security issues. I reported those to > certcenter and digicert (which is the root CA their intermediate chains > to). > > This is what I reported: > > Partly disfuctional > === > > The service seems to be partly disfunctional. The start page is just > showing an empty document. > > However when directly calling subpages, e.g. > https://alwaysonssl.com/issue.php > there still seems to be an operational service. > > This looks to me like AlwaysOnSSL is not actively maintained. > > XSS > === > > The certificate issuance form has a trivial injection issue. Simply > putting something like ">test will inject HTML. CSP+XSS Auditor > prevent this from being a simple XSS, but I'm pretty sure this can be > bypassed with enough effort. > > CSRF > > > The forms don't seem to contain any CSRF tokens. I haven't analyzed > this in detail, but I believe this likely means an attacker can > interfere with the issuance process and may be able to inject his own > CSR and forge a certificate. > > Account management > == > > I have an existing account for alwaysonssl.com from previous tests. > There seems to be no way of either deleting the account or changing the > password. I consider not offering a password changing option a security > problem as well. > > > I believe all of these issues show that alwaysonssl.com is an > unmaintained, partly broken service with a total lack of secure coding > practice, yet it's able to issue valid certificates that chain down to > a digicert root. > > - > > > In response to this the service was completely disabled. > > In one of the response mails CertCenter wrote me: > "Among other things, we operate a web application firewall that > prevent requests when it detects dangerous data. An XSS request like > the one you carried out apparently did not consider the WAF to be > relevant." > > This IMHO shows a serious lack of knowledge about web security basics > and an undeserved trust in WAFs. (The WAF filter was easily bypassable, > they also had a CSP which I believe was bypassable, too, but they > switched the service off before I could show that.) > > Given the service is switched off now I think there's nothing > particularly to do, but maybe it's a reminder to have a closer look at > the security of CA issuance web systems. > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > ___ > 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
AlwaysOnSSL web security issues
Hi, AlwaysOnSSL was a free certificate authority operated by CertCenter. I recently noticed that their main webpage was gone, but pieces of the service were still online. I immediately found a few web security issues. I reported those to certcenter and digicert (which is the root CA their intermediate chains to). This is what I reported: Partly disfuctional === The service seems to be partly disfunctional. The start page is just showing an empty document. However when directly calling subpages, e.g. https://alwaysonssl.com/issue.php there still seems to be an operational service. This looks to me like AlwaysOnSSL is not actively maintained. XSS === The certificate issuance form has a trivial injection issue. Simply putting something like ">test will inject HTML. CSP+XSS Auditor prevent this from being a simple XSS, but I'm pretty sure this can be bypassed with enough effort. CSRF The forms don't seem to contain any CSRF tokens. I haven't analyzed this in detail, but I believe this likely means an attacker can interfere with the issuance process and may be able to inject his own CSR and forge a certificate. Account management == I have an existing account for alwaysonssl.com from previous tests. There seems to be no way of either deleting the account or changing the password. I consider not offering a password changing option a security problem as well. I believe all of these issues show that alwaysonssl.com is an unmaintained, partly broken service with a total lack of secure coding practice, yet it's able to issue valid certificates that chain down to a digicert root. - In response to this the service was completely disabled. In one of the response mails CertCenter wrote me: "Among other things, we operate a web application firewall that prevent requests when it detects dangerous data. An XSS request like the one you carried out apparently did not consider the WAF to be relevant." This IMHO shows a serious lack of knowledge about web security basics and an undeserved trust in WAFs. (The WAF filter was easily bypassable, they also had a CSP which I believe was bypassable, too, but they switched the service off before I could show that.) Given the service is switched off now I think there's nothing particularly to do, but maybe it's a reminder to have a closer look at the security of CA issuance web systems. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
