I recently successfully installed Syncthing on my NAS using this guide which, although old, was useful and my first scan and sync completed fine.
Today, for reasons I am now regretting, I went into the GUI settings and checked the box to connect to Syncthing on my NAS via HTTPS. Now Firefox refuses to connect and displays the error
I have been searching to find a solution and am wondering if it is possible for me to SSH into my NAS to edit a file to switch the HTTPS option off to get back to where I was before with everything working.
Is that possible or do I have any other options to fix this? Many thanks.
I managed to login in to the GUI using Safari and de-selected the Use HTTPS for GUI option, now able to access via Firefox.
A few questions:
- should I have been able to access my Syncthing GUI via HTTPS on Firefox?
- what was different about using Safari which worked?
- if I am accessing Syncthing on my own LAN, is using HTTPS even necessary or simply overkill? Note that I have a GUI username & p/w setup.
I realise the first two questions may depend on several factors or courses of action unique to my machine and me. Thanks.
Yes. No idea what went wrong, maybe some caches or incorrect port settings? The url should’ve been https://[your-ip]:8384 if you’re running on the default port. What Firefox version have you used?
Since Syncthing uses a self-signed certificate by default, a browser warning will be displayed regarding the certificate. This is expected, but your error message is unrelated to the certificate.
The message you were seeing
SSL_ERROR_RX_RECORD_TOO_LONG usually means that the website Firefox was talking to spoke HTTP instead of HTTPS, which is very strange if you configured syncthing to use https. Maybe some caching?
As above, no idea.
If you access the web gui remotely over http, anyone sitting inside the connection will be able to sniff the password (and username) you’re using for the login.
If this connection is a local network, this applies for anyone inside the network. For pure ethernet cables that generally means physical access to the cables/ports, for WiFi this means either knowing the password (or bruteforce…) or attacking the network from a closer (< 200m) proximity (e.g KRACK attack). Note that such attacks require quite a bit of effort.
It mainly depends on how much security you want - if you trust your own network, you don’t really need HTTPS [for local connections]. If you want to protect yourself from attackers inside your network (defense-in-depth) an additional encryption layer (HTTPS) is ideal.
Security education note: HTTPS/TLS is only truly useful if the certificates are validated. Normally the browser does this automatically, but it can’t do it for self-signed certs. That’s why there is a warning. If you blindly click on accept/continue/whatever without verifying the cert, you loose all protection against an active (MITM) attacker. (Manual) verification of a certificate means to crosscheck the public key/fingerprint with a known value.
Thanks for your reply.
I set up Syncthing on my ReadyNAS using this guide:
How to install SyncThing on ReadyNas and Autostart
and in Step 6 you are required to open up
config.xml and edit the address setting to
<address>0.0.0.0:8080</address> which I suspect may have something to with it.
My connection to my NAS is a wired ethernet cable so perhaps my concerns with regards to nefarious actors are over egged .
I don’t want to spread paranoia, but as a network security guy I feel the need to clarify one thing:
If your network is both accessible over ethernet and WiFi, an attacker may be able to attack the ethernet connection over WiFi, utilizing attacks such as ARP spoofing (assuming your network is not specifially guarded against such attacks). The weakest part is what defines the security level and for many home networks that is the WiFi connection (weak passwords etc).
That would change the URL to
https://[NAS-IP]:8080 but it should still work. Maybe restart Syncthing and Firefox after enabling https?
By the way, I’ve glanced at the guide and it seems extremly outdated. Also, I’ve a feeling that a number of actions - including setting the listen port to 8080 - are useless, because I can’t imagine why listening on 8384 is impossible when 8080 works fine. I have a feeling that the user who wrote the guide simply preferred that port for his setup, as 8080 is a common port for secondary webservers.
Also running the service as root is not awesome (already discussed in your other thread) and I’m guessing that it would be totally possible to run the service as another user that is not root. But that might require some fiddling with permissions, as all syncthing-created directories will now be owned by root, which must/should be changed before migrating to a different user account. Generally the guide you linked doesn’t really seem to care about what is considered best-practice.
That guide is indeed quite old. Like, prehistoric. Back in 2015 I think we did use port 8080 by default so that wasn’t a change at the time.
Yep. It shows Syncthing v0.10 and we changed the port to 8384 for v0.11 because 8080 is too common and often taken.
jb@kvin:~/d/s/syncthing $ git describe 960c0cbd
jb@kvin:~/d/s/syncthing $ git show 960c0cbd
Author: Lode Hoste <zillode@->
Date: Thu Mar 26 21:36:06 2015 +0100
Change (default) GUI port from 8080 to 8384 ('ST' in ascii values)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.