Happy Friday everyone,
This is my last status report for the Summer of Privacy program, but I think I can end my reports on a good note. * At the suggestion of several people, I rewrote the networking infrastructure. Before, OnioNS-client and OnioNS-HS contacted the servers over Tor circuits, and OnioNS-server sent messages to each other over unencrypted TCP/IP links P2P-style. Now, the servers bind to localhost and are powered by hidden services, so all server-server communication occurs Ricochet-style. This is superior because it provides a significant increase to network attacks, works around the problem of distributing another TCP port in the consensus, and allows Tor relay administrators to run OnioNS servers without having to punch yet another hole in their firewall. I don't need anonymity for server P2P communication, so I will certainly be using the single onion service infrastructure when it becomes available. * All OnioNS servers now manage Ed25519 keypairs. In my design, authoritative Quorum servers will use their key for authenticated denial-of-existence and to prevent regular name servers from forging responses, but this infrastructure is not fully in place yet. When OnioNS merges into Tor, this keypair would be each router's signing key or at least a keypair signed by the signing key. * Servers now save newly-received Records to disk to prevent them. The cache file is loaded when the server starts up. * OnioNS-HS now saves newly-validated Records to disk before attempting to upload them. This is incredibly handy to prevent having to re-preform all the proof-of-work if the upload fails. * OnioNS-HS no longer has a dependency on little-t-tor. As s7r wisely points out, some people may have installed tor from git. I also added a flag to specify the number of worker threads, which can help reduce the system requirements if the HS is hosted on a VM with minimal system resources. * OnioNS-client no longer logs all Tor Browser activity. I used this for debugging, but it's no longer worth compromising user privacy. The software also correctly shuts down when the Tor Browser closes; in the process of fixing this I also discovered that it's not a good idea to misinterpret the documentation and run an application containing "kill(0, SIGTERM);". The result was quite unexpected. * In addition to intercepting all *.tor domains, OnioNS-client now rewrites "check.torproject.org" to another domain that shows that OnioNS is enabled in the browser. Before, users had to visit "example.tor" to confirm that the OnioNS software is running, but this was problematic because if OnioNS wasn't running, they get an error message because their exit node cannot resolve "example.tor" on the Internet DNS. Now these failures no longer leak. * I've stopped packaging my own build of jsoncpp, so I added a dependency for a system installation. Fortunately, Ubuntu/Mint, Debian, and Fedora all have that library in their repositories. * Logs now include the date and time, which is quite handy. * Numerous bugfixes, most notably I fixed the bug where the recipient would fail to understand a message longer than 500 bytes. To summarize the state of the project at the end of the SoP program: * All of the infrastructure for OnioNS is in place. There are still a few protocols left to finish off, but all big tasks are complete. The client-side and HS-side software is pretty reliable and stable at this point. * Although the software lacks in-line documentation, I have gone to great lengths to increase its readability and overall organization. * OnioNS runs just fine on Debian, Ubuntu, Mint, and Fedora, although I do not have any support for Windows or OS X. I'm asking for help from any Windows developer to help port the client software over there, please talk to me about that. * I have full intentions of continuing to maintain the OnioNS project. Please keep an eye on https://github.com/Jesse-V?tab=repositories and I will post here when I push out releases. I'm very close to the next beta test. * Once the OnioNS software is fully ready, no modifications to Tor should be necessary to merge OnioNS into the Tor network. Thanks everyone for the help, it's been a great summer project! Jesse V.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
