Opened 9 years ago
Last modified 5 years ago
#4670 new Enhancement
HTTPS Support in Web Client
Reported by: | John Clay | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | None Set |
Component: | Web Client | Version: | 2.42 |
Severity: | Normal | Keywords: | ssl https web client |
Cc: | flo@…, contact@… |
Description
HTTPS support in the web client would be nice.
Ideally, you would be able to generate a self-signed certificate, or use a properly signed certificate.
Change History (6)
comment:1 Changed 9 years ago by fijam
comment:2 Changed 9 years ago by Flow
- Cc flo@… added
Currently the user credentials of transmission can easily be sniffed, when using for example Chrome's "Remote Torrent Adder" from an unsecured public WiFi? network. Allowing easy hijacking of the users transmission installation.
Sure, one could go the way with an preceding proxy to enable encryption. But SSL support should be a standard feature of every remote controllable service, given the fact that this is an important security feature. Twitter and Facebook had to learn it the hard way, why make the same mistake?
comment:3 Changed 8 years ago by jordan
This won't happen until after libevent 2.1 switches to https://github.com/ellzey/libevhtp, which supports ssl
comment:4 Changed 7 years ago by Rudloff
- Cc contact@… added
comment:5 Changed 7 years ago by alesnav
Hello! Any news about this enhancement? Is there a date scheduled for this improvement?
Thanks
comment:6 Changed 6 years ago by bthusby
Yes, we need this! I want to secure all the web interfaces on my Synology NAS. Transmission is the only one left unencrypted... Please :)
Oh I dunno. It's fairly trivial to set up e.g. nginx as a https proxy. Here is an example configuration file with the added benefit of basic auth: http://pastebin.com/NQticLcq . On the transmission side: rpc-bind-address: 127.0.0.1