On Sat, Mar 31, 2018 at 6:28 PM, Michael Casadevall via dev-security-policy <dev-security-policy@lists.mozilla.org> 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
