[SSL Observatory] [Notary] Passive certificate notarization by an IDS; divergent query protocols

[Matthias Vallentin]

> Before I sit down and pound out a bunch of code, I was wondering if
> anyone has already written something that does this (ideally for Bro,
> but we could talk about other IDSes as well).

Since recently the master branch of Bro contains a script "notary.bro"
[1] that does exactly what you are looking for: it SHA-hashes X.509
certificates flying by and asks the ICSI notary via DNS whether (i)
the notary deems a certificate valid, (ii) when it has been seen the
first time, (iii) the last time, (iv) and how many days in between.
This extra information then goes into the ssl.log file that you may
already know. This relatively new script has only gone through basic
unit testing, so any feedback would be highly appreciated.

> I also noticed that Convergence, Perspectives, and the ICSI notary seem
> to implement three different query protocols (two HTTP-based, one DNS-based);
> this seems like an unfortunate divergence to me, and so I am also wondering if
> there is any plan to document and standardize how notaries are queried.

Convergence actually supports also a DNS backend, which was originally
designed to operate with Google's now defunct SSL Certificate
Catalogue. I submitted a pull request a while ago that removes the
hardcoded Catalogue URL and supports arbitrary DNS backends [2]. We
have been using this slightly tweaked version of Convergence
successfully, but stopped running the node due to the lack of use.

In the context of real-time monitoring of a large number of
certificates, we needed to resort to a decentralized and scalable
protocol, for which DNS fits perfectly well. We did not want to
reinvent a custom distribution layer because DNS with its caching
abilities provides all we need. Moreover, DNS provides querying
clients with anonymity with respect to the resolver: at our ends we
only see the resolver address, and privacy-concerned clients can
switch to open DNS resolvers for full anonymity. (Here, "full" means
only concealing the client system, obviously we see the certificate
hash which reveals some sort of information.)
The end-to-end semantics of TCP and HTTP would require some sort of
proxying to achieve anonymity, plus there is an initial setup cost for
the TCP handshake that incurs a performance penalty. For real-time
applications like live certificate monitoring, we hence decided that
DNS is the best fit. In the future, we also plan on offering a DNSSEC
interface. Convergence, on the other hand, rolls its own caching
implementation and uses a "bouncing" mechanism for anonymity.

That said, I don't see directly how to unify these fundamentally
different technologies.

   Matthias

[1] https://github.com/bro/bro/blob/master/scripts/policy/protocols/ssl/notary.bro
[2] https://github.com/moxie0/Convergence/pull/163