Re: Discovering unlogged certificates in internet-wide scans

[Tim Smith via dev-security-policy]

Hi Stephen,

Thank you for the correction; I regret the error.

On Tue, Apr 10, 2018 at 8:12 AM Stephen Davidson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> These certificates are compliant with the BR and contain the required
> extKeyUsage values for both id-kp-serverAuth or id-kp-clientAuth.  It
> appears that zLint "w_sub_cert_eku_extra_values" provides an incomplete
> message relating to the BR 7.1.2.3:
>

I opened a pull request against zlint to fix the error message for the
extra_values lint: https://github.com/zmap/zlint/pull/218

I'll update the blog post momentarily.

Tim
___
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

[Tim Smith via dev-security-policy]

On Sat, Mar 31, 2018 at 6:28 PM, Michael Casadevall via
dev-security-policy  wrote:
> Pretty interesting read, and always happy to see more information go
> into CT. One thing I couldn't divine from your data was how did you look
> for non-HTTPS services? Did you port scan and do service discovery, or
> did you simply knock on well known ports that either are SSL by default
> or support a STARTTLS equivalent?
>
> If so, which well known ports were knocked on?

Thanks for taking a look. My understanding of Rapid7's methodology [1,
2] is that they knock on well-known ports. The services they emit data
for are pop3/s (110, 995), nntps (563), mqtt (8833), ftps (990),
smtp/s (25, 465, 587), and imap/s (143, 990).

I consumed their published data set and didn't perform any scanning myself.

> When you say roots included to Mozilla trust store, how was this used
> exactly? I see you used X509Validator, but did you just throw all the
> NSS PEMs or did you remove the ones that are technically constrained?

I used the certifi distribution [3], which is aware of "included but
distrusted" [4]. The certificates were "validated" naively without
considering e.g. path length or name constraints; certificates failing
those constraints would certainly be interesting but hopefully rare.

> I'd also be interested in see or graph that shows how many
> certificates chain up to a given root.

Sure; would you like to see that because it would help sanity-check
the data, or because it might reveal differences vs. certificates used
for HTTPS, or some other reason?

Thanks,
Tim

[1] https://github.com/rapid7/sonar/wiki/More-SSL-Certificates
[2] https://scans.io/study/sonar.moressl
[3] https://certifiio.readthedocs.io/en/latest/
[4] https://github.com/certifi/extract-nss-root-certs
___
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

[Tim Smith via dev-security-policy]

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

Discovering unlogged certificates in internet-wide scans

[Tim Smith via dev-security-policy]

Hi MDSP,

I went looking for corpuses of certificates that may not have been
previously logged to CT and found some in the Rapid7 "More SSL" dataset,
which captures certificates from their scans of non-HTTPS ports for
TLS-speaking services.

I wrote up some findings at
http://blog.tim-smith.us/2018/03/moressl-spelunking/.

A few highlights include:
- of the ~10 million certificates in the corpus, about 20% had valid
signatures and chained to roots included in the Mozilla trust store
- about 50,000 of the 2 million trusted certificates had not previously
been logged
- about half of the novel certificates were unexpired

There were interesting examples of unexpired, non-compliant, trusted
certificates chaining to issuers including GoDaddy, NetLock, Logius, and
Entrust. (I have not taken any action to inform issuers of these findings,
other than this message and by publishing the certificates to CT logs.)

I welcome any feedback or questions about the value of the approach and the
findings.

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

Re: Public trust of VISA's CA

[Tim Smith via dev-security-policy]

On Wednesday, February 14, 2018 at 8:43:19 AM UTC-8, Wayne Thayer wrote:
> In this particular case, my conclusion is that the existing Mozilla
> process is working. We have documented a number of issues that when
> considered in aggregate warrant an investigation.

Hi Wayne,

Forgive me if I'm overinterpreting your comment, but: does this mean that an 
investigation is ongoing, or that Mozilla anticipates opening an investigation? 
If there is or will be an investigation, do you have a general sense of when to 
expect a result, and what that might look like?

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