Hello dear Tincers! I recently developed an extension to tinc 1.0.x protocol which introduces automatic and decentralized hosts update subsystem. The idea is to provide stable protocol extension to tinc which will do all the dirty work of spreading information about new hosts in network across all nodes by powers of tinc itself. If you're interested, you can take a look at the diff made for tinc 1.0.16 here: https://github.com/siblynx/tinc-1.0.16_hostupd/commit/6a6cc34d6d80696ea525956375de59c7f752fa42 The code introduces two request types, and uses RSA signatures to prevent tampering. It also introduces some sort of privileges: who can and who cannot spread updates. Each node which has child connections forwards update requests. Users can decide to whom to trust, and can turn off updates for their own node. They also can setup completely trustful network in which everyone will be permitted to update the whole network. Please see source file src/protocol_hostsupdate.c, it contains more information about the extension implementation and how to configure each node for it. In future I probably will move it to a README.hostupd file. This is a motivation from the lesson I learned recently when my central update service crashed inside my network with huge disk failures, and that node's key became unrecoverable (yeah, I lost it, no backups, it was a cheap "PC" router), resulting in unmanaged network for a few weeks. It served updates centrally via http, and it's URL was the only one which was recorded in update scripts and binaries for windows everywhere. Even when I started using tinc, I seen that it misses something important when I was forced to update hosts by hand for some time. This work is still experimental, I even test it now, and if you will want to merge it into current or future versions of Tinc, you will probably need to trim it of my extensions for my network. It probably _contains_ bugs I still did not found, and I am not a pro in cryptography (albeit having some experience with in past). This work is currently (my own code) is licensed under GPLv2 only. I will happily unlicense it (making it public domain) if it will go into any versions of Tinc, just with mentioning my contribution in THANKS file. If not, it will stay as is. With best wishes! P.S. I found Tinc a great code inside when I developed extension for it. I was able to quickly understand configuration and requests subsystem, and the rest was no a problem. It's a shame that Tinc still gets little attention in VPN area! -- http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code
That sounds pretty amazing. Excellent work and thanks for contributing, I hope this gets implemented. On 16 Oct 2015 11:02, "????" <lynx at lynxlynx.tk> wrote:> Hello dear Tincers! > > I recently developed an extension to tinc 1.0.x protocol which > introduces automatic and decentralized hosts update subsystem. > > The idea is to provide stable protocol extension to tinc which will do > all the dirty work of spreading information about new hosts in network > across all nodes by powers of tinc itself. > > If you're interested, you can take a look at the diff made for tinc > 1.0.16 here: > > https://github.com/siblynx/tinc-1.0.16_hostupd/commit/6a6cc34d6d80696ea525956375de59c7f752fa42 > > The code introduces two request types, and uses RSA signatures to > prevent tampering. It also introduces some sort of privileges: who can > and who cannot spread updates. Each node which has child connections > forwards update requests. > > Users can decide to whom to trust, and can turn off updates for their > own node. They also can setup completely trustful network in which > everyone will be permitted to update the whole network. > > Please see source file src/protocol_hostsupdate.c, it contains more > information about the extension implementation and how to configure > each node for it. In future I probably will move it to a README.hostupd > file. > > This is a motivation from the lesson I learned recently when my central > update service crashed inside my network with huge disk failures, and > that node's key became unrecoverable (yeah, I lost it, no backups, it > was a cheap "PC" router), resulting in unmanaged network for a few > weeks. It served updates centrally via http, and it's URL was the only > one which was recorded in update scripts and binaries for windows > everywhere. > > Even when I started using tinc, I seen that it misses something > important when I was forced to update hosts by hand for some time. > > This work is still experimental, I even test it now, and if you will > want to merge it into current or future versions of Tinc, you will > probably need to trim it of my extensions for my network. It probably > _contains_ bugs I still did not found, and I am not a pro in > cryptography (albeit having some experience with in past). > > This work is currently (my own code) is licensed under GPLv2 only. I > will happily unlicense it (making it public domain) if it will go into > any versions of Tinc, just with mentioning my contribution in THANKS > file. If not, it will stay as is. > > With best wishes! > > P.S. I found Tinc a great code inside when I developed extension for > it. I was able to quickly understand configuration and requests > subsystem, and the rest was no a problem. It's a shame that Tinc still > gets little attention in VPN area! > > -- > http://lynxlynx.tk/ > Power electronics made simple > Unix and simple KISS C code > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20151016/5795a729/attachment.html>
Thanks for your warm words about this! If anyone is planning to introduce it into mainline Tinc then one should see more commits since 6a6cc34d6d80696ea525956375de59c7f752fa42, some more bughunting was performed since then. In my environment, this patched Tinc already passed all tests and I hope this protocol extension is stable. With best wishes! On Fri, 16 Oct 2015 12:07:27 +0800 Benjamin <zorlin at gmail.com> wrote:> That sounds pretty amazing. Excellent work and thanks for > contributing, I hope this gets implemented. > On 16 Oct 2015 11:02, "????" <lynx at lynxlynx.tk> wrote: > > > Hello dear Tincers! > > > > I recently developed an extension to tinc 1.0.x protocol which > > introduces automatic and decentralized hosts update subsystem. > > > > The idea is to provide stable protocol extension to tinc which will > > do all the dirty work of spreading information about new hosts in > > network across all nodes by powers of tinc itself. > > > > If you're interested, you can take a look at the diff made for tinc > > 1.0.16 here: > > > > https://github.com/siblynx/tinc-1.0.16_hostupd/commit/6a6cc34d6d80696ea525956375de59c7f752fa42 > > > > The code introduces two request types, and uses RSA signatures to > > prevent tampering. It also introduces some sort of privileges: who > > can and who cannot spread updates. Each node which has child > > connections forwards update requests. > > > > Users can decide to whom to trust, and can turn off updates for > > their own node. They also can setup completely trustful network in > > which everyone will be permitted to update the whole network. > > > > Please see source file src/protocol_hostsupdate.c, it contains more > > information about the extension implementation and how to configure > > each node for it. In future I probably will move it to a > > README.hostupd file. > > > > This is a motivation from the lesson I learned recently when my > > central update service crashed inside my network with huge disk > > failures, and that node's key became unrecoverable (yeah, I lost > > it, no backups, it was a cheap "PC" router), resulting in unmanaged > > network for a few weeks. It served updates centrally via http, and > > it's URL was the only one which was recorded in update scripts and > > binaries for windows everywhere. > > > > Even when I started using tinc, I seen that it misses something > > important when I was forced to update hosts by hand for some time. > > > > This work is still experimental, I even test it now, and if you will > > want to merge it into current or future versions of Tinc, you will > > probably need to trim it of my extensions for my network. It > > probably _contains_ bugs I still did not found, and I am not a pro > > in cryptography (albeit having some experience with in past). > > > > This work is currently (my own code) is licensed under GPLv2 only. I > > will happily unlicense it (making it public domain) if it will go > > into any versions of Tinc, just with mentioning my contribution in > > THANKS file. If not, it will stay as is. > > > > With best wishes! > > > > P.S. I found Tinc a great code inside when I developed extension for > > it. I was able to quickly understand configuration and requests > > subsystem, and the rest was no a problem. It's a shame that Tinc > > still gets little attention in VPN area! > > > > -- > > http://lynxlynx.tk/ > > Power electronics made simple > > Unix and simple KISS C code > > _______________________________________________ > > tinc mailing list > > tinc at tinc-vpn.org > > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > >-- http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code