Re: CT2 log signing key compromise

[Alex Cohn via dev-security-policy]

Thank you for the clarification. This would appear to introduce a new
requirement for clients verifying SCTs from CT2: a get-proof-by-hash call
to the log server (or a mirror) is now required to know if a SCT from
before May 2 is valid. Do CT-enforcing clients do this in practice today?
(I suspect the answer is "no" but don't know off the top of my head)

Alex



On Sun, May 3, 2020 at 6:27 PM Jeremy Rowley 
wrote:

> They would already appear in a previous tree where the head was signed by
> us.
>
>
>
> *From:* Alex Cohn 
> *Sent:* Sunday, May 3, 2020 5:22 PM
> *To:* Jeremy Rowley 
> *Cc:* Mozilla 
> *Subject:* Re: CT2 log signing key compromise
>
>
>
> The timestamp on a SCT is fully controlled by the signer, so why should
> SCTs bearing a timestamp before May 2 still be considered trusted?
>
>
>
> Alex
>
>
>
> On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> Hey all,
>
> The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm
> through the Salt root bug. The remaining logs remain uncompromised and run
> on separate infrastructure.  We discovered the compromise today and are
> working to turn that log into read only mode so that no new SCTs are
> issued. We doubt the key was used to sign anything as you'd need to know
> the CT build to do so. However, as a precaution, we ask that you consider
> all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd .
> Please let me know what questions you have.
>
> Jeremy
> ___
> 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: CT2 log signing key compromise

[Alex Cohn via dev-security-policy]

The timestamp on a SCT is fully controlled by the signer, so why should
SCTs bearing a timestamp before May 2 still be considered trusted?

Alex

On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey all,
>
> The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm
> through the Salt root bug. The remaining logs remain uncompromised and run
> on separate infrastructure.  We discovered the compromise today and are
> working to turn that log into read only mode so that no new SCTs are
> issued. We doubt the key was used to sign anything as you'd need to know
> the CT build to do so. However, as a precaution, we ask that you consider
> all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd .
> Please let me know what questions you have.
>
> Jeremy
> ___
> 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: Certificate OU= fields with missing O= field

[Alex Cohn via dev-security-policy]

On Fri, Nov 1, 2019 at 5:14 AM Kurt Roeckx via dev-security-policy
 wrote:
>
> On Fri, Nov 01, 2019 at 11:08:23AM +0100, Matthias van de Meent via 
> dev-security-policy wrote:
> > Hi,
> >
> > I recently noticed that a lot of leaf certificates [0] have
> > organizationalUnitName specified without other organizational
> > information such as organizationName. Many times this field is used
> > for branding purposes, e.g. "issued through "
> > or "SomeBrand SSL".
> >
> > BR v1.6.6 § 7.1.4.2.2i has guidance on usage of the OU field: "The CA
> > SHALL implement a process that prevents an OU attribute from including
> > a name, DBA, tradename, trademark, address, location, or other text
> > that refers to a specific natural person or Legal Entity unless the CA
> > has verified this information in accordance with Section 3.2 and the
> > Certificate also contains subject:organizationName, ,
> > subject:givenName, subject:surname, subject:localityName, and
> > subject:countryName attributes, also verified in accordance with
> > Section 3.2.2.1."
> >
> > As the organizationName and other related attributes are not set in
> > many of those certificates, even though e.g. "COMODO SSL Unified
> > Communications" is a very strong reference to Sectigo's ssl branding &
> > business, I believe the referenced certificate is not issued in line
> > with the BR.
> >
> > Is the above interpretation of BR section 7.1.4.2.2i correct?
>
> That OU clearly doesn't have anything to do with the subject that
> was validated, so I also consider that a misissue.
>
>
> Kurt

A roughly-equivalent Censys.io query, excluding a couple other
unambiguous "domain validated" OU values: "not _exists_:
parsed.subject.organization and _exists_:
parsed.subject.organizational_unit and not
parsed.subject.organizational_unit: "Domain Control Validated" and not
parsed.subject.organizational_unit: "Domain Validated Only" and not
parsed.subject.organizational_unit: "Domain Validated" and
validation.nss.valid: true" returns 17k hits.

IMO the "Hosted by .Com" certs fail 7.1.4.2.2i - the URL of a web
host is definitely "text that refers to a specific ... Legal Entity".

> Certificate also contains subject:organizationName, , subject:givenName,
> subject:surname, subject:localityName, and subject:countryName
> attributes, also verified in accordance with Section 3.2.2.1.

I'm pretty sure this isn't what the BRs intended, but this appears to
forbid issuance with a meaningful subject:organizationalUnitName
unless all of the above attributes are populated. EVG §9.2.9 forbids
including those attributes in the first place. Am I reading this
wrong, or was this an oversight in the BRs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Alex Cohn via dev-security-policy]

Neil's interpretation of my poorly-worded question was correct - thank you
and apologies for the confusion.

On Thu, Sep 12, 2019 at 5:39 PM Ryan Sleevi  wrote:

>
> On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Should a CA using a precertificate signing certificate be required to
>> provide OCSP services for their precertificates? Or is it on the relying
>> party to calculate the proper OCSP request for the final certificate and
>> send that instead? In other words, should we expect a CT-naïve OCSP
>> checker
>> to work normally when presented, e.g., with https://crt.sh/?id=1868433277
>> ?
>>
>
> I think this may be the wrong framing. The issue is not about ensuring "a
> CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring
> that, from the point of view of a user agent that views a pre-certificate
> as evidence that an equivalent certificate exists, even if it's not known
> (or even if it was not actually issued), can they verify that OCSP services
> exist and are configured for that equivalent certificate?
>

Fair point. The only relying parties likely to come across
precertificates in practice are CT log clients, and it's reasonable to
assume those will be prepared to handle edge cases like this. (How many
actually handle this correctly? crt.sh doesn't, as far as I can tell - OCSP
checks for the precert I posted earlier return "unauthorized", despite the
final certificate being good)


> In this scenario, because RFC 6962 establishes that, even when using a
> Precertificate Signing Certificate, it will have been directly issued by
> the CA Certificate that will ultimately issue the "final" certificate (...
> or would be treated as if it had), then we have the (name-hash, key-hash)
> that Neil was referring to, and we can easily verify using that, for the
> serial number indicated in the pre-certificate, that the OCSP response can
> be verified using the issuer of the Precertificate Signing Certificate.
>

That technique was what I was attempting to hint at with "on the relying
party to calculate the proper OCSP request for the final certificate".


> Have I overlooked some ambiguity?
>

Not that I can think of on further reflection. Just some
unanticipated-by-me edge cases :)

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Alex Cohn via dev-security-policy]

On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as
> if corresponding certificate exists and (ii) a CA must be able to revoke a
> pre-certificate if revocation of the certificate is required under the
> Mozilla policy and the corresponding certificate doesn't actually exist and
> therefore cannot be revoked.
>

Should a CA using a precertificate signing certificate be required to
provide OCSP services for their precertificates? Or is it on the relying
party to calculate the proper OCSP request for the final certificate and
send that instead? In other words, should we expect a CT-naïve OCSP checker
to work normally when presented, e.g., with https://crt.sh/?id=1868433277?

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Alex Cohn via dev-security-policy]

On Mon, Sep 2, 2019 at 1:36 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 02/09/2019 20:13, Alex Cohn wrote:
> > On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > Waiting until CT submission of the final certificate is complete to
> return
> > "good" OCSP responses is definitely wrong. OCSP should return "good" at
> the
> > moment the final certificate is issued, which means in practice that
> there
> > might be a "good" OCSP response that doesn't contain SCTs yet.
> >
> > I don't know if any log does this, but RFC6962 allows logs to check for
> > certificate revocation before issuing a SCT; if the OCSP responder
> doesn't
> > return "good" the CA might never get the needed SCTs?
> >
>
> This seems to be an unfortunate aspect of the CT spec that wasn't
> thought through properly.  In particular, it should cause unnecessary
> delay if a CA updates its OCSP servers using "eventual consistency"
> principles.  Maybe it should be fixed in the next update of the spec.
>
> The BRs have the following requirements that are best satisfied by
> delayed update of OCSP servers:
>
> BR4.10.2 The OCSP servers must be up 24x7 .  Thus rolling out updates to
> different servers at different times would be a typical best practice.
>
> BR4.9.10 The OCSP servers only need to be updated twice a week (4 days)
> ..  This could only satisfy the CT requirement if issued certificates
> were somehow withheld from the subscriber for up to 4 days.
>

Withholding certificates for four days would be a huge competitive
disadvantage for a CA. If I were a CA relying on OCSP delivery of SCTs, I
would try to make absolutely sure my OCSP responders could be updated with
SCTs in a timely manner after initial issuance. Since this SCT delivery
method relies on OCSP stapling to work, I could even tell my customers to
configure their web servers with a special OCSP server URL (using, e.g.,
nginx's ssl_stapling_responder directive) that would block until a response
with embedded SCTs could be created.


> > RFC6960 section 2.2 documents a technique for indicating "unknown serial,
> > may issue in future" that involves returning "revoked" with a revocation
> > date of 1970-1-1 and a reason of certificateHold. I don't know if this
> > technique is used anywhere in practice - IIRC it requires the OCSP
> signing
> > key to be online and able to sign responses for arbitrary serial numbers
> in
> > real time.
> >
>
> The question was if this technique would be in violation of the BRs, as
> those generally prohibit the use of "certificateHold" .
>

Where is this prohibition in the BRs? The only relevant section I could
find is 4.9.13, which prohibits suspension of certificates. This isn't
suspension of a certificate; the certificate doesn't exist.

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Alex Cohn via dev-security-policy]

On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> If an OCSP server supports returning (or always returns) properties of
> the actual cert, such as the CT proofs, then it really cannot do its
> usual "good" responses until the process of retrieving CT proofs and
> creating the final TBScertificate (and possibly signing it) has been
> completed.
>
> Thus as a practical matter, treating a sign-CT-sign-CT in-process state
> as "unknown serial, may issue in future" may often be the only practical
> solution.
>

Waiting until CT submission of the final certificate is complete to return
"good" OCSP responses is definitely wrong. OCSP should return "good" at the
moment the final certificate is issued, which means in practice that there
might be a "good" OCSP response that doesn't contain SCTs yet.

I don't know if any log does this, but RFC6962 allows logs to check for
certificate revocation before issuing a SCT; if the OCSP responder doesn't
return "good" the CA might never get the needed SCTs?

Also, if a CA is signing a precert, getting SCTs for that precert, then
embedding the SCTs in the final cert, they are already satisfying the
browsers' CT requirements. It would not be necessary for them to
additionally embed SCTs for the final cert in their OCSP responses.

Now depending on interpretations, I am unsure if returning "revoked" for
> the general case of "unknown serial, may issue in future" would violate
> the ban on unrevoking certificates.
>

RFC6960 section 2.2 documents a technique for indicating "unknown serial,
may issue in future" that involves returning "revoked" with a revocation
date of 1970-1-1 and a reason of certificateHold. I don't know if this
technique is used anywhere in practice - IIRC it requires the OCSP signing
key to be online and able to sign responses for arbitrary serial numbers in
real time.

(Are any CAs even using the OCSP SCT delivery option? I haven't come across
this technique in the wild)

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates

[Alex Cohn via dev-security-policy]

On Fri, Aug 30, 2019 at 10:26 AM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Is our answer right though? I wasn't sure. I said "Good" because "a
> promise to issue a cert" could be considered the same issued. In that case
> the BRs say you must respond good. However, if "a promise to issue a
> certificate" is not the same as issuance, the BRs don't apply to the OCSP
> until the certificate issues and the correct response is "Revoked" per the
> RFC.
>
> The BRs apply for sure to the contents, but do they apply to the OCSP
> responses in the time period between when the pre-cert is logged and the
> cert is signed.
>

It seems reasonable to me to assume that if the contents of a
precertificate are in-scope for the BRs, the OCSP responses would be
likewise in-scope.


> Seems like a nice simple rule is that the promise to issue is issuance
> regardless of what the BRs say and that you should respond good. This was
> our logic and why we decided on "Good".


I agree. A CA cannot prove they didn't issue the final certificate. Given
existence of a pre-certificate, it is reasonable for a relying party to
assume that the final certificate exists and therefore that OCSP services
will be functional. I personally would view arguments such as "we didn't
actually issue that, so we don't need to provide sane OCSP responses" with
a great deal of skepticism, especially from CAs that do not automatically
CT log their final certificates (nudge nudge DigiCert, Amazon, Entrust).

However, a very strict reading of the RFC and BR interaction means you need
> to respond "Revoked" until the cert issues. I don't like that outcome
> because it's complicated and leads to confusion.


Looking at sections 2.2 of RFC6960 and 4.9.10 of the BRs, I don't see the
requirement to respond "revoked" for unknown or non-issued certificates -
can you explain further? 4.9.10 forbids replying "good" for non-issued
certificates, but I don't see any stipulations surrounding replying
"unknown." The certificateHold + 1970-1-1 revocation date method of
indicating a non-issued certificate in 6960 2.2 might be forbidden by an
especially strict reading of BRs 4.9.13, but it's not mandated by 6960. In
the absence of a precertificate signing certificate, OCSP queries for
precertificate and certificate are identical, so it could be argued that
the precertificate itself means it's not a "non-issued" certificate?

>From a RP's perspective, I can easily envision problems resulting from an
OCSP response for a given serial number transitioning from revoked to good,
especially if the response is cached by the relying party or a proxy.

It also occurred to me that CAs using a precertificate signing certificate
(e.g. Trustwave or NetLock) would be able to differentiate OCSP requests
for precertificates from final certificates. How do these CAs handle OCSP
for precertificates? Trustwave appears to always answer "unauthorized
" and NetLock "malformed
", which is...curious.

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with subject stateOrProvinceName "Some-State"

[Alex Cohn via dev-security-policy]

Inspired by Nick Lamb's comment a week or so ago on m.d.s.p about "Default
City" being an OpenSSL default value in CSRs, I ran some more searches on
the OpenSSL defaults and found almost 100 certificates with a
stateOrProvinceName of "Some-State". BR section 7.1.4.2.2(f) requires this
field to be verified if present in a certificate.

Affected CAs are Sectigo, DigiCert, SwissSign, Government of Turkey,
T-Systems, Telia, SecureTrust, and certSIGN.

Here's the batch: https://misissued.com/batch/53/

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with subject locality "Default City"

[Alex Cohn via dev-security-policy]

On Thu, May 2, 2019 at 3:45 PM Nick Lamb  wrote:
> Alex, you say you "came across" these certificates, do you think it is
> likely that there are many more, or was that in practice a fairly
> thorough search?


I've been adding certificates found in Censys scans to CT logs, and
happened to spot one of the kumamoto-u.ac.jp certs while reviewing my
logger's error logs. I then searched on Censys for certificates with
"Default City" as the locality, filtered out untrusted and expired
certificates, and deduplicated precertificates. There may well be
additional certificates out there (compiling the misissued.com batch
was a manual process, and I make mistakes) but I'd be surprised if
there were more than a handful.

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificates with subject locality "Default City"

[Alex Cohn via dev-security-policy]

Hi all,

I came across a number of certificates issued by Sectigo, SECOM, and
DigiCert that list "Default City" as the subject's locality. Unless there
are actually localities named "Default City" that I'm unaware of, it seems
to me this is a violation of the BRs, sections 3.2.2.1 and 7.1.4.2.2.e.

I created a batch on misissued.com for these:
https://misissued.com/batch/51/

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: AlwaysOnSSL web security issues

[Alex Cohn via dev-security-policy]

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

Re: CA Communication: Underscores in dNSNames

[Alex Cohn via dev-security-policy]

On Sat, Dec 8, 2018 at 5:01 AM Richard Moore via dev-security-policy
 wrote:
>
> > the scope of the main project if ~120 certs across a similar number of 
> > vendors. One of the home grown applications also hardcode the name of the 
> > certificate into the application and will require not only certificate 
> > update in coordination with the vendors but code changes on 120 certs in 12 
> > days.
>
> It seems likely to me that these applications won't actually support OCSP and 
> updating any CRLs in use may well be a manual process too. So, if the 
> certificates were revoked, would your applications actually notice at all? 
> It's quite different from them expiring which is coded into the certificate 
> itself.

Even if these apps support revocation checking, their root stores
might contain one or more ancient roots that are no longer needed by
any WebPKI certificate, and could therefore be removed from BR scope
and continue issuing underscore-containing certificates.

When SHA1 was deprecated, Sectigo (née Comodo) requested root stores
remove one of their roots [1], taking it out of scope for the BRs, and
continued issuing "legacy" SHA1 certificates off of that root. Sectigo
has also published a list of certificates containing underscores they
will be revoking [2]; conspicuously absent from that list are four of
these legacy SHA1 certificates [3].

Perhaps pilgrim's company (Verizon?) could convince a CA to do
something similar here?

Best,
Alex

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1208461
[2]: https://misissued.com/batch/41/
[3]: https://crt.sh/?id=701056092, https://crt.sh/?id=700688392,
https://crt.sh/?id=701055930, https://crt.sh/?id=700688392
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: localhost.megasyncloopback.mega.nz private key in client

[Alex Cohn via dev-security-policy]

On Wed, Aug 8, 2018 at 9:17 AM Hanno Böck  wrote:

>
> As of today this is still unrevoked:
> https://crt.sh/?id=630835231=ocsp
>
> Given Comodo's abuse contact was CCed in this mail I assume they knew
> about this since Sunday. Thus we're way past the 24 hour in which they
> should revoke it.
>
> --
> Hanno Böck
> https://hboeck.de/


As Hanno has no doubt learned, the ssl_ab...@comodoca.com address bounces.
I got that address off of Comodo CA's website at
https://www.comodoca.com/en-us/support/report-abuse/.

I later found the address "sslab...@comodo.com" in Comodo's latest CPS, and
forwarded my last message to it on 2018-08-05 at 20:32 CDT (UTC-5). I
received an automated confirmation immediately afterward, so I assume
Comodo has now known about this issue for ~70 hours now.

crt.sh lists sslab...@comodoca.com as the "problem reporting" address for
the cert in question. I have not tried this address.

Comodo publishes at least three different problem reporting email
addresses, and at least one of them is nonfunctional. I think similar
issues have come up before - there's often not a clear way to identify how
to contact a CA. Should we revisit the topic?

Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: localhost.megasyncloopback.mega.nz private key in client

[Alex Cohn via dev-security-policy]

The certificate [1] in the GitHub link you posted was issued by Comodo, not
by GeoTrust. The two share a private key, though, so both the Comodo and
GeoTrust certs should be considered compromised at this point. I've added
the Comodo-issued cert to several CT logs for tracking, and I'm CCing
ssl_ab...@comodoca.com for followup.

I've also found the final GeoTrust cert [2] in the git revision history and
logged it (you had linked to the precertificate). According to OCSP,
DigiCert has revoked the GeoTrust certificate as of 2018-08-04 07:13:32 UTC.

Alex

[1]:
https://censys.io/certificates/04db0e79f2aa22d91f66fdea2b03193b04d1987b5ae5f3b5ce326e9539bde550
[2]:
https://censys.io/certificates/de549fa946e0564e4d50f21ced16035f1dc25be26099a7add70d55efb39d5811



On Thu, Aug 2, 2018 at 11:07 PM summern1538--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello Ben,
>
> Thanks for your fast response and help.
>
> After a bit research I also found the source with the key:
>
> https://github.com/meganz/MEGAsync/blob/master/src/MEGASync/control/Preferences.cpp
>
> As it is public I think it should not be problem to post it here.
>
> Best Regards
> Norbert
> ___
> 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: Discovering unlogged certificates in internet-wide scans

[Alex Cohn via dev-security-policy]

I'm currently grabbing certs from Censys's BigQuery extracts and
submitting them to the Argon logs (and Daedalus/Rocketeer for certs
that fall before/after Argon's not-after range).

There's a fair bit of latency in the process; I'm only running this
script weekly (it costs about $4 a pop in BigQuery usage alone) and
Censys only updates BigQuery every couple days. But there are only a
handful of certs in the Censys corpus as of a couple weeks ago that
are not also in CT. [1]

I've talked with Censys about them doing this directly, and my
impression was that it's something they're in support of but not
something they have the bandwidth to do themselves right now.

Alex

[1] 
https://censys.io/certificates?q=metadata.added_at%3A%5B*+TO+2018-03-15%5D+and+not+tags.raw%3Act+and+validation.google_ct_primary.valid%3A+true

On Sat, Mar 31, 2018 at 7:41 PM, Tim Smith via dev-security-policy
 wrote:
> On Sat, Mar 31, 2018 at 3:26 PM, Kurt Roeckx  wrote:
>> Have you done the for their other scans?
>
> I haven't. The Rapid7 HTTPS corpus is much larger; I'm not sure my
> approach will scale that far and I imagine the new discovery rate will
> be lower.
>
> Censys has been interested in submitting new certificates to CT in the
> past [1]; I wonder if they've resumed.
>
> Tim
>
> [1] 
> https://groups.google.com/a/censys.io/d/msg/discussion/nrbN70xegEs/dmbunh7jAgAJ
> ___
> 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: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Alex Cohn via dev-security-policy]

Thanks, Jeremy.

I also found a certificate [1] with both 16-character.onion and
56-character.onion addresses [2] listed in the SAN. The v3 address is
not included in the 2.23.140.1.31 extension, which seems to violate
the same rule as below. However, v3 addresses include the service's
entire public key in the address itself, so there's nothing to be
gained by embedding a hash of that key in a certificate.

I'm not sure what, if anything, needs to happen in this case. Thoughts?

Alex

[1] https://crt.sh/?id=351449246
[2] https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt

On Mon, Mar 12, 2018 at 7:28 PM, Jeremy Rowley via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
> Thanks Alex. Sorry for the delayed response. I've been traveling today.
> We're reaching out to each of the customers and getting their cert replaced.
>
>
> Looking into this, we did not correctly implement the ballot:
> 1. We didn't add a check to our backend system too verify the cert included
> a descriptor prior to issuance.
> 2. On the front end, we missed requiring a Tor descriptor prior to
> processing the order.
> 3. The validation team received insufficient training on the Tor descriptor
> requirement.
>
> In reality, the issue was too much reliance on the human component of
> asserting the Tor descriptors instead of having a technical control in
> place. We're working on putting those technical controls in place.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy
> <dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org>
> On Behalf Of Alex Cohn via dev-security-policy
> Sent: Sunday, March 11, 2018 9:37 PM
> To: dev-security-policy@lists.mozilla.org
> Subject: DigiCert .onion certificates without Tor Service Descriptor Hash
> extension
>
> In the EV Guidelines [1], Appendix F states "The CA MUST include the CAB
> Forum Tor Service Descriptor Hash extension in the TBSCertificate convey
> hashes of keys related to .onion addresses." This language was added in
> Ballot 201 [2], which had an effective date of 8 July 2017.
>
> The following certificates (and precertificates if the corresponding
> certificate is not in a public CT log) were issued by DigiCert after 8 July
> for .onion domains, but lack the necessary extension:
> https://crt.sh/?q=240277340 (revoked 26 October 2017)
> https://crt.sh/?q=261570255
> https://crt.sh/?q=261570338
> https://crt.sh/?q=261570380
> https://crt.sh/?q=261570384
> https://crt.sh/?q=261579788
> https://crt.sh/?q=261601212
> https://crt.sh/?q=261601280
> https://crt.sh/?q=261601281
> https://crt.sh/?q=261601284
> https://crt.sh/?q=261988060
> https://crt.sh/?q=326491168
> https://crt.sh/?q=326830043
> https://crt.sh/?q=328308725
> https://crt.sh/?q=328961187
> https://crt.sh/?q=329559222
> https://crt.sh/?q=330180704
> https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email to
> DigiCert)
>
> This was previously discussed on m.d.s.p about a year ago [3].
>
> [1]
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.
> 8.pdf
> [2] https://cabforum.org/2017/06/08/2427/
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/ZtNI
> D_xfAgAJ
> ___
> 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

DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Alex Cohn via dev-security-policy]

In the EV Guidelines [1], Appendix F states "The CA MUST include the
CAB Forum Tor Service Descriptor Hash extension in the TBSCertificate
convey hashes of keys related to .onion addresses." This language was
added in Ballot 201 [2], which had an effective date of 8 July 2017.

The following certificates (and precertificates if the corresponding
certificate is not in a public CT log) were issued by DigiCert after 8
July for .onion domains, but lack the necessary extension:
https://crt.sh/?q=240277340 (revoked 26 October 2017)
https://crt.sh/?q=261570255
https://crt.sh/?q=261570338
https://crt.sh/?q=261570380
https://crt.sh/?q=261570384
https://crt.sh/?q=261579788
https://crt.sh/?q=261601212
https://crt.sh/?q=261601280
https://crt.sh/?q=261601281
https://crt.sh/?q=261601284
https://crt.sh/?q=261988060
https://crt.sh/?q=326491168
https://crt.sh/?q=326830043
https://crt.sh/?q=328308725
https://crt.sh/?q=328961187
https://crt.sh/?q=329559222
https://crt.sh/?q=330180704
https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email
to DigiCert)

This was previously discussed on m.d.s.p about a year ago [3].

[1] 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.8.pdf
[2] https://cabforum.org/2017/06/08/2427/
[3] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/ZtNID_xfAgAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

[Alex Cohn via dev-security-policy]

I logged two of those five certificates (https://crt.sh/?id=308392091
and https://crt.sh/?id=307753186) to Argon, as part of a project to
log every certificate in the censys.io database to a public CT log. I
believe Censys found them by scanning all of IPv4 and grabbing the
default (i.e. no SNI) certificate presented on port 443.

Given that this method will not uncover every certificate ever issued,
and that Certum isn't or wasn't checking for weak keys and isn't
logging certificates to CT, should Mozilla ask Certum to scan every
currently-valid certificate they have issued for weak keys?

Alex

On Mon, Feb 5, 2018 at 2:56 PM, Hanno Böck via dev-security-policy
 wrote:
> On Mon, 5 Feb 2018 12:07:06 -0500
> Eric Mill via dev-security-policy
>  wrote:
>
>> WoSign and StartCom are untrusted, but Certum is still trusted, right?
>
> Yes.
>
> In case that was unclear: The sentence "As we all know these are no
> longer trusted by Mozilla, ..." was referring to the chapter above,
> i.e. the three Startcom+Wosign certs, not the whole mail.
>
> --
> 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