[SSL Observatory] Fresh observatory data ? Survey other ports/protocols ?

[Andy Isaacson]

On Wed, Apr 27, 2011 at 04:53:27PM -0700, Brian Smith wrote:
> Chris Palmer wrote:
> > > When will the tls/ssl observatory data be refreshed from a new scan?
> > > (just curious :)
> > 
> > The distributed scanning effort will be underway soon, like in a week
> > or two.
> > 
> > I want us to also do a fresh centralized scan. Also, anyone can start
> > one up, by simply using our code. Many people should!
> 
> Are you interested in publishing data about SSL characteristics that
> aren't certificate related (e.g. which servers support the TLS
> renegotiation extension, which servers support SNI, which servers
> refuse TLS 1.2 handshakes)?

Speaking just for myself, there are obviously other opinions out there
and various people with different interests:


Yes, I'm interested in adding more data; also in data about ports other
than 443.

> Would you accept tri-licensed MPL/LGPL/GPL C/C++ contributions? I

I'd prefer to keep the licensing "as simple as possible, but no
simpler";  for my sslobservatory-ui projects, I'm currently licensed
under AGPL v3.  I'm open to being convinced that there's a better
choice, though.

> think it would be very cool if the scanner actually parsed and
> validated the certificates using exactly the same code that Mozilla
> products use. I could reorganize our certificate path validation code
> to facilitate easier integration into your tools, if it would be
> helpful.

That would be useful as a data validation test, for sure!  I'd love to
see that as one of many parsing options.  Currently the Observatory
projects use openssl(1) as the parser, and I'm adding a pyasn1 backend
to sslobservatory-api as an alternative.

Perhaps adding a CLI tool to the Mozilla tree so that we can check it
out and build it, or something like that?

If we were to just copy stuff out of Mozilla's tree, it'll diverge from
their code over time.  That would be sad, I think.


> For my work, the most useful piece of information on a day-to-day
> basis is the list of <host>:<port> combinations that I pull from this
> dataset and SSL Labs' dataset, which I feed to my own scanner. A flat
> file of just this information would be a very useful deliverable.

It's pretty easy for you to parse that out of the Observatory datasets,
isn't it?  And it costs something like 50 cents to spin up an EC2 node
for one hour to run that query (or any other query you'd like).

Since it's so cheap and fairly easy, I'm not personally inclined to add
custom querys as deliverables on the projects I'm building; I'd rather
make it easy for people to do their own queries -- possibly up to and
including a read-only SQL query interface.

-andy