I have two questions about the security in Synchting.
How to change AES-128 to AES-256?
Each instance of Synchting opens several ports. Could there be potential security problems with these open ports in a private LAN that might include untrusted parties or even active attackers? I don’t know how Synchting handles open ports.
Would opening SSH port 22, routing Synchting traffic from there and closing other ports be a better option (OpenSSH takes care of ports rather than Synchting).
The TLS cipher suite is auto-negotiated by the library and while it’s probably theoretically possible to change this by fiddling with the source code, I don’t think there’s a method without recompiling stuff. I personally also don’t think it’s necessary.
Every application doing network activity “opens ports” in some way. This includes your operating system, your browser and many other applications.
Syncthing’s “sync-traffic” is entirely over TLS, with both sides cryptographically authenticated. Syncthing also has a webserver (for the inbuild GUI), which is by default only accessible to the local machine. If the GUI is set to be accessible from the outside, a GUI user + password should be set for security (and HTTPS).
You can tunnel syncthing over SSH. In most setups I don’t see a major security gain through this (apart from defense in depth), but if you prefer this - yes, it’s possible.
I see, so it’s TLS library. As you probabl know, AES-128 has 64 bits security with quantum computers. But it’s good to know TLS does the same for all apps.
So, can an attacker “get into” my Synchting server using Synchting open ports? What software accepts only Synchting traffic and rejects anything else? Because the firewall shows that the ports are fully open. I suppose traffic arriving at ports 27017 and others is filtered internally by Synchting?
I want to anticipate potential attack vectors, and if there are potentials, introduce additional security measures. The data on the server must absolutely be secure.
I agree. I see Dropbox etc also have opened ports in my firewall. I just want to know more about “application firewall”.
So with SSH, there is TLS over SSH? Or TLS is disabled, since SSH already does encryption?
Thanks!
Syncthing uses tls for mutual auth, so the fact you can connect to a port means nothing, unless you can prove you’re a trusted device (and have the private key to prove it).
Web ui is non-mutual, but we highly recomment setting up authentication there.
If you don’t trust TLS (given you want to wrap it in SSH), you should probably disconnect your internet cable as most things on the internet use TLS nowadays.
OK thanks.
So basically, ignoring the TLS part and focusing on the Synchting networking, I can ping port 27017 sending a packet, but if the packet header does not contain the authorized public key, the connection is refused.
The software that handles authentication is TLS or Syncthing? Like Synchting will pass the public keys to the TLS and TLS does the authentication.
How can I disable the GUI? I don’t see any option in the Setting or Advance. The GUI address is localhost:8384. I suppose a remote GUI is possible only if the GUI address is somehow a public address (somebody’s website or such).
I see the option “Use TLS” in the GUI section. Does that mean, if I un-check it, the data will be transferred without TLS? Or this TLS is only for the settings in the GUI?
I don’t consider us to be post-quantum yet. Thruth is, TLS is not designed to withstand quantum computers. Even if you increase your block cipher to 256 bit, an attacker could break ECDSA signatures or ECDHE using Shor’s Algorithm, thus simply calculating the AES key in use - doesn’t matter if it’s 128 or 256. The AES keys in TLS are short lived and not designed to hold post-quantum.
This is pretty much a problem that is yet to solve, as the entire web currently relies on TLS for transport security. Simply adding in AES256 in the mix won’t fix the problem.
Syncthing performs authentication after the initial handshake. Any device not passing authentication get’s automatically disconnected. So no, anyone who is not listed in “Your Devices” cannot connect.
Syncthing never disables TLS. You’re simply talking TLS on top of SSH.
This setting only refers to the GUI. The GUI talks HTTP by default, but can be switched to HTTPS. This is useful if allowing the GUI to be accessible from the outside. By default it’s listening on localhost, which means that it’s not accessible from the network.
Killing of the GUI entirely would mean that you can no longer change or see settings, or monitor the sync.
A bit of both, the crypto stuff is mostly done in Go’s TLS stack, but the syncthing application decides whether a certificate/public key is allowed to connect.
That port sounds like local discovery (altough the actual port should be 21027/UDP). On that port syncthing only announces it’s presence to the LAN. No sensitive information is send over that port. The default sync port is 22000.
Thank you very much! It’s clear now!
Quick question on Synchting over SSH.
In this case, the authentication is based on the SSH protocol performed by the OpenSSH. Suppose that a key is leaked, or is weak (due to a bad random number generator or various other problems) and is broken. In the case of SSH, the SSH provides a shell and the packets go to the shell. In the case of Syncting, what would be the fate of a packet that passes the authentication?
It seems that Synchting provides a more restricted environment post-authentication than the SSH. It seems that from the perspective of the Synchting, authentication by an attacker would only provide access to the data in the folders synced by the Syncthing) and nothing more (in other words, data in other folders is still safe and commands cannot be executed). Or could the authenticated packets be diverted to get a shell in the user space?
This could be an important advantage for Synchting. It also means that, running Synchting in an isolated environment like Docker provides no additional safety, since it’s already isolated in some sense?
By the way, I fully agree with you that the asymmetric crypto is the bottleneck here. Going to AES-256 would be questionable (replacing rsa/ed25519 with ed448 helps). That’s why some agencies save the TLS traffic.
It basically means pretty much any data communicated is poorly protected (protected only for a limited time).
We use standard go TLS stack, so if there is some exploit in authentication it would probably mean every go application is vunlnerable.
There is a small part of certificate checking we do ourselves, but it’s small enough to make it easy to reason about.
I can’t say much about protocol abuse to get a remote shell (this is post authentication), obviously we’re security conscious people that do our best not implement crazy stuff that would permit that, but we can’t provide guarantees. The code has not been audited as far as I know.
Running in docker does provide a layer of isolation, but even docker is not perfect.
Thank you!
Fully understood!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.