Application question (noob)

I was referred here from the ownCloud forum…

We are looking to create a community Wi-Fi mesh network for emergency applications (California US, think earthquakes).

Since the network must be able to survive loss of nodes, it is a requirement that any important data be stored across the network. The specific need looks like a number of small SBC (Single Board Computers, RPi, etc.), with typically one SBC per network node. There will be no “clients” for the SBCs as all services will run directly on the SBC. So, if I understand the terminology correctly, each SBC will be its own client and server. (all applications will be terminal or browser based.) We would then like to connect all the SBCs together in a federated network. This would allow any node to drop off the network and still maintain a copy of the last data state, and then re-synch when the network can be joined again.

The data requirements are low. Mostly text files and relatively lo-res photos. There would be somewhere between 12 and 32 nodes in the network.

There is one important additional requirement: This network will run under FCC part.97 rules (Amateur Radio). As such encryption is not allowed. So, it must be possible to disable any encryption in the file sharing software.

My questions: Is Syncthing an appropriate technology for this application? If not, can you point me to some other package that might do the job? Have others done something like this and, if so, do you have any pointers to those projects?

Thanks,

Richard

Based on your requirements, Syncthing appears to be appropriate.

The “no encryption” requirement needs some clarification. If your files are stored in an un-encrypted state on each device, they will be synced in that same state to all other devices in your cluster. However, they will be transmitted over the network using TLS encryption.

Thanks for the info. The no encryption requirement is for the data that crosses the network. It is part of the FCC requirements for Ham radio transmissions. It was originally intended to apply to voice communications, but has been carried forward as amateur radio has moved into wireless data networking. So, the use of TLS would definitely be an issue. Is there any way to disable it?

The default communication is https (TLS). However there is an advanced setting in the webGUI to switch off TLS.

This should enable unencrypted http if all devices in your cluster are similarly configured. I don’t know if that removes all encryption to comply with your regulations - perhaps one of the developers will jump in to answer that.

Check the docs for details about Syncthing TLS.

The encrypted data transfer cannot be disabled and as far as I know there is no plans to change that at the moment.

If a transmission(voice communication) uses a compression algorithm which is not widely used (or devised just for that application) will this be considered encryption under that law? Since it is not plain data…

Compression is allowed. What is not allowed is intentionaly obscuring communications to hide them from others.

I believe I gave you incorrect information earlier, and the input from @wweich was correct. Turning off TLS in the advanced settings allows http access to the webGUI - where the default is https.

However, and more significant for you, peer-to-peer TLS transmission can not be turned off.

Sorry for the confusion.

That sounds like an awesome project and technically Syncthing could have fit very well, but no the encryption doesn’t turn off. It’s not just a matter of not wanting to - the entire authentication method (any authentication method, really) is based on crypto. Without authentication, it wouldn’t be Syncthing any more.

It sounds like you could get away with each device running an http server, and periodically running a script to check all other peers for newer copies of files. It could be ten lines around “curl” or something like that.

Actually, the authentication is not an issue, there is an exception for passwords.

It is the actual content of the synchronization. However, I believe openSSL has an option for cipher suites that do not include encryption: eNONE and aNONE. If I have openSSL configured for a nuke cipher suite, would syncThing work over that?

Syncthing does not use OpenSSL. In theory you can fork Go standard lib and add a None ciphersuite. But then again, as calmh said, you can probably write 10 lines of bash to achieve the same which muss less effort.

Thanks for all the ideas. Yeah, I guess curl’ing the files is probably the way to go. I can probably setup a central node list and then let each node update their idea off the network from that.

Again, thanks. enjoy your turkey, tofu or whatever.

It looks like this is something like that? ztls package - github.com/zmap/zgrab/ztools/ztls - Go Packages at least the constants look like it is supported…

So far our testing with Synching has been quite favorable. So, it is looking like it may be worth our time to look into the suggestions about implementing a null cipher suite - especially if @Alex’s suggestion works out. Does anyone else have any more information on that?

Search the forums, I had fairly accurate steps how to do that a while ago.

I can’t find it, but basically you have to modify this part:

And add a cipher from this list: http://www.iana.org/assignments/tls-parameters/tls-parameters.xml

Probably TLS_RSA_WITH_NULL_MD5, adding a md5 mac, and leaving other fields as nil.

You will also need to patch syncthing to generate RSA keys rather than ECDSA essentially reverting https://github.com/syncthing/syncthing/commit/6d11006b5496e5fb4282f4c02473829d25e82abb

So this approach implies that device IDs will remain secure&unique but the data sent over the wire is unencrypted, right?

Yes.

Many thanks. That should keep me busy for a while. I will report back.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.