6o8Vnscc5hZJGQITIWVB5UhFc8

Yep, reverse proxy with SSL and a good WAF like mod_security is strictly necessary. There are tons of how-tos out there about 'setting up your own dropbox' with a linux server and btsync. And I cringe every time I see one because I've never seen one mention this. You know there are people out there who just copy/paste the commands without understanding what they're doing and assume it's safe, but it's not. Not reverse proxying (or disabling) the btsync webui is foolish and anyone advocating it is putting people at risk. Sending 'secrets' in plaintext over an untrusted network means they are no longer secrets. This should be plastered in big, bold letters all over any instructional copy regarding btsync and it's not. I could (almost) forgive them for not including this functionality because of the messiness of dealing with SSL certs and not wanting to reinvent the wheel (a good web server), but omitting a prominent warning of a gaping security hole is inexcusable. The fact that everyone seems to want to stick their heads in the sand and pretend this isn't a real issue is very disconcerting and makes me wonder what other security issues are being ignored inside the black box of closed source code. It sure doesn't inspire confidence.

Is there really no way to enable/force the webui of the linux btsync to use https/ssl? This is a gaping security hole for a software trying to take pride in security and privacy. That might be fine for communication over a private, trusted network but it's wholly unacceptable for communication over the public internet. I have a remote server I've been using for offsite backup and I've now realized that the credentials to the webui and all my 'secrets' have been transmitted in plaintext on the open internet. Great. As a workaround I can change all my secrets, disable the webui, and exclusively do remote configuration on a config file via ssh, but still... wtf?