Antibozo comments
From Cmcl
Having tested out the extension and reviewed some of the extension and server source code I can say a few more things about the system.
The default behavior is to consult Perspectives for certs that cannot be validated. You can set it to test all certs, however. This clarifies a question I posted earlier.
There are some architectural and code quality issues I would challenge the developers to consider further:
1. The notary services can be used to conduct port scans. 2. Once there are a lot of notaries, it's possible the services could be used to conduct a denial-of-service attack. 3. The transport is UDP, and messages contain no nonce, so notary replies are replayable. 4. The notary forks a separate process for each request which then execs a separate binary to do the actual key probe, with a limit on the number of concurrent requests. Thus it should be fairly easy to DoS a notary. An attacker can fire off a continuous stream of bogus requests to keep notaries too busy to do any useful work. 5. The interprocess message formats are sloppily defined. Some but not all messages require internal null termination; some messages have different maximum sizes than others. 6. The code has a lot of statically defined buffers and corresponding code that restates buffer sizes numerically rather than using sizeof(). This makes code error-prone; when someone changes a buffer size, they have to find all of the places the size was explicitly stated and change those to match. 7. The code contains complete copies of openssl and openssh that have been modified in place, rather than simply relying on an external build of these tools. The changes are not provided as diffs. This makes it difficult to maintain these underlying codebases as new releases address vulnerabilities. 8. Notary queries each leak two bytes of heap memory because sig_len is uninitialized. 9. Notary replies could leak notary stack data because messages are assumed to contain null termination. 10. It is not clear that internationalized domain names are handled properly. 11. Notaries sign MD5 digests in replies, and use MD5 fingerprints for keys. MD5 is no longer considered safe. 12. There are insufficient checks on notary replies. A compromised notary can crash clients, or possibly compromise them. 13. Replies could eventually exceed UDP maximum datagram size as key info data structures grow.
A few suggestions I would make to the developers:
A. Add a nonce to the messages. B. Redefine the message encoding scheme. Consider using ASN.1 to encode messages. Or consider using DNS to encode and transport messages. C. Use TCP transport, preferably over HTTP, so that firewalls don't get in the way. Consider simply using HTTPS with preloaded certificates instead of the existing transport and signature scheme. D. Encrypt requests, and remove service ids from replies (use a secure transaction id instead). A notary eavesdropper can observe each SSL service someone connects to, both host and port; this is more exposure than DNS creates. If someone is using the Perspectives-enabled SSH, an eavesdropper can observe what SSH services that person connects to. E. Add complete integrity checks on all sizes in messages. F. Make the scanner functions shared libraries and dl_open them in the main scanner process. You can then use either threads or a simple fork (with no exec overhead) to fire off each probe. G. Make your SSL scanner a separate program (or shared library entry point) that simply builds and links against the openssl libraries. Don't include a modified version of a possibly out-of-date copy of openssl with your server code. H. Ditto for openssh (openssh builds a libssh.a; have builder do an openssh build from current source to provide this). I. Specify the signature and fingerprint digest algorithms in replies, and allow multiple digests. Use SHA256 by default, and be ready for the next digest algorithm.
