> 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
