Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
AlwaysOnSSL web security issues
523 views
Skip to first unread message
Hanno Böck
Jan 9, 2019, 9:59:55 AM1/9/19
to mozilla-dev-s...@lists.mozilla.org
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<h1> 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
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<h1> 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
Alex Cohn
Jan 9, 2019, 11:52:21 PM1/9/19
to Hanno Böck, mozilla-dev-s...@lists.mozilla.org
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
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
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
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Buschart, Rufus
Jan 10, 2019, 4:43:27 AM1/10/19
to Alex Cohn, Hanno Böck, mozilla-dev-s...@lists.mozilla.org
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
[...]
> 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-secur...@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).
[...]
> >
> > 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.
[...]
Alex Gaynor
Jan 10, 2019, 9:10:42 AM1/10/19
to Buschart, Rufus, Alex Cohn, Hanno Böck, mozilla-dev-s...@lists.mozilla.org
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
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
Jeremy Rowley
Jan 10, 2019, 1:00:29 PM1/10/19
to Alex Gaynor, Buschart, Rufus, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Hanno Böck
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
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
Jakob Bohm
Jan 10, 2019, 1:16:49 PM1/10/19
to mozilla-dev-s...@lists.mozilla.org
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
> 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.
>
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
Wayne Thayer
Jan 10, 2019, 3:18:10 PM1/10/19
to Jeremy Rowley, Alex Gaynor, Buschart, Rufus, Alex Cohn, Hanno Böck, mozilla-dev-s...@lists.mozilla.org
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-secur...@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.
>
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-secur...@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 Rowley
Jan 10, 2019, 4:47:15 PM1/10/19
to Wayne Thayer, Alex Gaynor, Buschart, Rufus, Alex Cohn, Hanno Böck, mozilla-dev-s...@lists.mozilla.org
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 <wth...@mozilla.com>
Sent: Thursday, January 10, 2019 1:18 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Alex Gaynor <aga...@mozilla.com>; Buschart, Rufus <rufus.b...@siemens.com>; Alex Cohn <al...@alexcohn.com>; Hanno Böck <ha...@hboeck.de>; mozilla-dev-s...@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
> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
From: Wayne Thayer <wth...@mozilla.com>
Sent: Thursday, January 10, 2019 1:18 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Alex Gaynor <aga...@mozilla.com>; Buschart, Rufus <rufus.b...@siemens.com>; Alex Cohn <al...@alexcohn.com>; Hanno Böck <ha...@hboeck.de>; mozilla-dev-s...@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 <dev-secur...@lists.mozilla.org<mailto:dev-secur...@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 <dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, January 10, 2019 7:10 AM
To: Buschart, Rufus <rufus.b...@siemens.com<mailto:rufus.b...@siemens.com>>
Cc: Alex Cohn <al...@alexcohn.com<mailto:al...@alexcohn.com>>; mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>; Hanno Böck <ha...@hboeck.de<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
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 <dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, January 10, 2019 7:10 AM
To: Buschart, Rufus <rufus.b...@siemens.com<mailto:rufus.b...@siemens.com>>
Cc: Alex Cohn <al...@alexcohn.com<mailto:al...@alexcohn.com>>; mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>; Hanno Böck <ha...@hboeck.de<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
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
>
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
Tim Hollebeek
Jan 16, 2019, 5:18:26 PM1/16/19
to Jeremy Rowley, Wayne Thayer, Alex Cohn, Alex Gaynor, mozilla-dev-s...@lists.mozilla.org, Buschart, Rufus, Hanno Böck
Here's the article we published on this subject a while ago:
https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practices/
-Tim
> <dev-secur...@lists.mozilla.org<mailto:dev-security-
> dev-secur...@lists.mozilla.org<mailto:mozilla-dev-security-
> pol...@lists.mozilla.org>; Hanno Böck
> pol...@lists.mozilla.org>
> pol...@lists.mozilla.org>
https://www.digicert.com/blog/keeping-subscribers-safe-partner-best-practices/
-Tim
> pol...@lists.mozilla.org>; Hanno Böck
> <ha...@hboeck.de<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-secur...@lists.mozilla.org<mailto:dev-security-
> 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 <
> 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-secur...@lists.mozilla.org<mailto:dev-security-
>
> > 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 <
> pol...@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-secur...@lists.mozilla.org<mailto:dev-security-policy@lists
> > > >
> > > > 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
> > .mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
> >
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org<mailto:dev-security-
> >
> _______________________________________________
> dev-security-policy mailing list
> pol...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org<mailto:dev-security-
> _______________________________________________
> dev-security-policy mailing list
> pol...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
0 new messages