On 03/31/2018 09:53 PM, Tim Smith wrote: > On Sat, Mar 31, 2018 at 6:28 PM, Michael Casadevall via > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > 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. >
Ah, I misread, I thought you had done the scanning directly. Still, it was good to take a look at this, and I'm looking through Rapid7's docs on how to play with the data set 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. > Hrm, I might have a weekend project here. I've always been curious to what extent technical constraints actually affected things. I may need to download their data set and play with it somewhat. >> 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? > Partially for non-HTTPS usage, but I also wanted to see the cross-section of how much "diversity" there was in how much of the internet chains of a specific root certificate. Michael _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
