Opened 6 years ago

Last modified 3 years ago

#5412 new Enhancement

Add option to connect over SSL to Qt client

Reported by: kreed Owned by: jordan
Priority: Normal Milestone: None Set
Component: Qt Client Version: 2.80
Severity: Normal Keywords: patch
Cc: nekit1234007+TransmissionTrac@…

Description

transmission-remote already supports SSL. It would be useful if the Qt client did too. A patch which adds a check box to the session dialog is attached.

However, there is one issue. Currently the client fails silently for untrusted certificates. This should probably be addressed, as surely a number of people will want to connect to personal servers using self-signed certificates. I see two ways to handle this:

  1. Add an option to disable certificate verification. Trivial, but insecure.
  2. Display a dialog when an untrusted certificate is encountered allowing the certificate to be accepted. Ideally the certificate's fingerprint would be saved for future sessions.

I prefer option 2, but it would require a non-trivial amount of code. I'm willing to work on either (or any other option), but I'd like some feedback before I proceed.

Attachments (2)

qt-ssl-checkbox.patch (4.9 KB) - added by kreed 6 years ago.
qt-ssl-checkbox-v2.patch (4.9 KB) - added by kreed 6 years ago.

Download all attachments as: .zip

Change History (8)

Changed 6 years ago by kreed

comment:1 follow-up: Changed 6 years ago by rb07

You have a mistake in the code, the order and position must be the same in quark.[ch], you have "username"/"use-ssl" in different order.

A 3rd option for the way to handle no certificate, or invalid certificate, would be just like transmission remote: show an error "SSL connect error".

The documentation(*) needs to address the what/where/how of the certificate. I haven't "played" with this, but on some servers I have a cert for the Web server, and a different one for the mail server, both are for the same domain. In this case, is the domain important? do you have to have a domain? can you use a personal cert? (which is installed on the Web browser, and is another cert, one people could get for free).

(*) I don't know where the documentation is.

Changed 6 years ago by kreed

comment:2 in reply to: ↑ 1 Changed 6 years ago by kreed

Replying to rb07:

You have a mistake in the code, the order and position must be the same in quark.[ch], you have "username"/"use-ssl" in different order.

Oops. Thought I fixed that. I'll upload the correct patch.

A 3rd option for the way to handle no certificate, or invalid certificate, would be just like transmission remote: show an error "SSL connect error".

Actually, transmission-remote just doesn't do any certificate verification and succeeds without error. Far from ideal.

The documentation(*) needs to address the what/where/how of the certificate. I haven't "played" with this, but on some servers I have a cert for the Web server, and a different one for the mail server, both are for the same domain. In this case, is the domain important? do you have to have a domain? can you use a personal cert? (which is installed on the Web browser, and is another cert, one people could get for free).

(*) I don't know where the documentation is.

Well, right now transmission-daemon doesn't support SSL out of the box. You have to set up an SSL-capable reverse proxy such as nginx or stunnel to talk to transmission. The client will get whichever certificate the proxy is set up with.

You need a domain to get ahold of a CA-signed certificate. If you don't have one then your best bet is just to have the client bypass verification (when we add that ability). But your other option is to create your own CA certificate, import it into your OS's trust store, and sign your server's certificate with it.

comment:3 Changed 6 years ago by rb07

transmission-remote just doesn't do any certificate verification and succeeds without error.

Is transmission-remote accepting no certificate, and invalid certs?

That would be a 4th option on how to handle it, one that is very easy for the end user, but with no security other than the one already in place. The end user would get encrypted communication, which is probably the main point.

right now transmission-daemon doesn't support SSL out of the box. You have to set up an SSL-capable reverse proxy

You should have stated that clearly in the description. i.e. the option is for having access to transmission-daemon through a reverse proxy.

There's another ticket with the request to use https for the Web client (no reverse proxy required), pending a new version of libevent which will handle that part (current version's release notes say it already does).

Last edited 6 years ago by rb07 (previous) (diff)

comment:4 Changed 6 years ago by rb07

What about adding a tool tip?

    cb->setToolTip( tr("Currently intended for use with a reverse proxy.") );

or something clear.

comment:5 Changed 4 years ago by Nekit

  • Cc nekit1234007+TransmissionTrac@… added

comment:6 Changed 3 years ago by mike.dld

Closed #6105 as duplicate of this ticket.

Note: See TracTickets for help on using tickets.