Bug #11152

Have SSL on our rsync communications with mirrors

Added by sajolida 2016-02-21 18:45:07 . Updated 2020-01-25 17:13:22 .

Status:
Confirmed
Priority:
Low
Assignee:
Category:
Infrastructure
Target version:
Start date:
2016-02-21
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
1
Affected tool:
Deliverable for:

Description

The days of unauthenticated, cleartext communication on Internet are over. Currently the communication between our primary rsync server and all our mirrors is cleartext and unauthenticated. We should use TLS.

The Puppet code that manages our primary rsync server is linked from https://tails.boum.org/contribute/working_together/roles/sysadmins/#rsync. How one can get a Let’s Encrypt certificate for rsyncd is left to be researched. Once we support TLS on our side, we need to have all mirror operators adjust their cronjob to have their rsync client use TLS.

We could do something like:

$ cat /etc/xinetd.d/rsync-syncproxy-ssl
service rsync-ssl
{
        bind            = W.X.Y.Z
        type            = UNLISTED
        port            = 1873
        id              = rsync-syncproxy-ssl

        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/bin/stunnel4
        server_args     = /etc/rsyncd-syncproxy-stunnel.conf
        nice            = 10
        instances       = 200
        per_source      = 3
        cps             = 0 0
}

$ cat /etc/rsyncd-syncproxy-stunnel.conf
cert = /etc/ssl/OUR_CERTIFICATE_CHAIN
key = /etc/ssl/OUR_KEY

debug = notice

client = no
socket = a:SO_LINGER=1:60
socket = a:SO_KEEPALIVE=1

exec = /usr/bin/rsync
execargs = rsync --daemon --config=/etc/rsyncd-syncproxy.conf

Subtasks

Related issues

Related to Tails - Feature #8437: Test whether we could use curl for all HTTP requests in check-mirrors Confirmed 2014-12-14
Blocked by Tails - Bug #15162: Remove rsync.torproject.org from the mirrors synchronization chain Resolved 2018-01-10

History

#1 Updated by intrigeri 2016-02-23 11:58:14

  • Assignee set to sajolida
  • QA Check set to Info Needed

Is this about the connectivity between our primary rsync server and Tor project’s one, between Tor project’s one and all our mirrors, or both?

#2 Updated by sajolida 2016-02-24 10:08:30

  • Description updated

I would say both. If we want to tell our users their downloads are protected with SSL we need to have SSL on the whole chain:

rm → rsync.tails.boum.org → rsync.torproject.org → mirror → user

#3 Updated by sajolida 2016-02-24 16:08:05

  • Assignee deleted (sajolida)
  • QA Check deleted (Info Needed)

#4 Updated by intrigeri 2016-02-26 23:40:11

  • Assignee set to intrigeri
  • Target version set to Tails_2.6

> I would say both. If we want to tell our users their downloads are protected with SSL we need to have SSL on the whole chain:

Got it. I’m interested in helping hardening this part, so I’ll try to have a look.

#5 Updated by BitingBird 2016-07-01 14:16:15

  • Status changed from New to Confirmed

#6 Updated by intrigeri 2016-08-27 02:38:41

  • Target version changed from Tails_2.6 to Tails_2.7

Might be addressed as part of a sysadmin sprint in September. Otherwise it’ll have to wait.

#7 Updated by intrigeri 2016-11-05 13:59:36

  • Target version changed from Tails_2.7 to 284

#8 Updated by anonym 2016-11-25 10:57:05

  • Target version changed from 284 to Tails 2.10

#9 Updated by intrigeri 2016-12-18 12:41:36

  • Target version changed from Tails 2.10 to Tails_2.11

(I had to take over a bunch of more urgent sysadmin tasks so I’ll postpone this one.)

#10 Updated by intrigeri 2017-02-27 10:09:23

  • Description updated
  • Assignee deleted (intrigeri)
  • Priority changed from Normal to Low
  • Target version deleted (Tails_2.11)
  • Parent task deleted (Feature #9796)
  • Starter set to Yes

This is orthogonal to the main reasons we have to switch to HTTPS mirrors (Feature #9796#note-10), so unparenting, dropping from my plate and lowering priority. But it’s now documented well enough to flag it as Easy :)

#11 Updated by intrigeri 2017-03-08 20:22:35

Removing Tor’s rsync server from the loop could simplify this task a lot.

#12 Updated by intrigeri 2018-01-10 11:26:36

  • related to Bug #15162: Remove rsync.torproject.org from the mirrors synchronization chain added

#13 Updated by Anonymous 2018-01-19 15:19:57

  • related to Feature #8437: Test whether we could use curl for all HTTP requests in check-mirrors added

#14 Updated by intrigeri 2018-06-27 08:17:14

  • related to deleted (Bug #15162: Remove rsync.torproject.org from the mirrors synchronization chain)

#15 Updated by intrigeri 2018-06-27 08:17:19

  • blocked by Bug #15162: Remove rsync.torproject.org from the mirrors synchronization chain added

#16 Updated by intrigeri 2018-06-27 08:18:04

intrigeri wrote:
> Removing Tor’s rsync server from the loop could simplify this task a lot.

… and this happened: we now have full control over the rsync server mirrors sync’ from.

#17 Updated by Anonymous 2018-08-17 16:42:43

  • Assignee set to intrigeri
  • QA Check set to Info Needed

Ok, so the current state of things seems to be that mirror operators now all directly sync from mirrors.rsync.tails.boum.org. The TLS cert of which is not correct as it is for deb.tails.boum.org. We should change that.

I’m reassigning this to intrigeri to know what to do about it. Is this part of sysadmin’s work?

#18 Updated by intrigeri 2018-08-17 17:46:33

  • Assignee deleted (intrigeri)

u wrote:
> Ok, so the current state of things seems to be that mirror operators now all directly sync from mirrors.rsync.tails.boum.org. The TLS cert of which is not correct as it is for deb.tails.boum.org. We should change that.

I don’t quite follow. Does our rsyncd already support SSL? I’d be surprised if it had access to the certificate for deb.tails.boum.org. Maybe you checked over HTTPS, which lands on a different machine?

> I’m reassigning this to intrigeri to know what to do about it. Is this part of sysadmin’s work?

It’s sysadmin work but so far it did not make it on our roadmap. Would be nice to have, like so many things. So once you’ve clarified the above, please unassign back :)

#19 Updated by Anonymous 2018-08-17 19:24:32

  • Assignee deleted ()
  • QA Check deleted (Info Needed)

intrigeri wrote:
> u wrote:
> > Ok, so the current state of things seems to be that mirror operators now all directly sync from mirrors.rsync.tails.boum.org. The TLS cert of which is not correct as it is for deb.tails.boum.org. We should change that.
>
> I don’t quite follow. Does our rsyncd already support SSL? I’d be surprised if it had access to the certificate for deb.tails.boum.org. Maybe you checked over HTTPS, which lands on a different machine?

I checked it only over HTTPS indeed.

> > I’m reassigning this to intrigeri to know what to do about it. Is this part of sysadmin’s work?
>
> It’s sysadmin work but so far it did not make it on our roadmap. Would be nice to have, like so many things. So once you’ve clarified the above, please unassign back :)

Ack. Thanks for clarifying that.

#20 Updated by intrigeri 2018-10-17 10:27:22

  • Description updated

#21 Updated by intrigeri 2018-10-17 10:32:06

Note that the proposed solution requires mirror operators to use stunnel or similar to wrap the rsync client connection. If it’s doable in a way that can be documented very simply on https://tails.boum.org/contribute/how/mirror/, fine; if not, I think we need to think out of the box a little bit.

#22 Updated by mpfrs 2020-01-18 19:11:15

intrigeri wrote:
> Note that the proposed solution requires mirror operators to use stunnel or similar to wrap the rsync client connection. If it’s doable in a way that can be documented very simply on https://tails.boum.org/contribute/how/mirror/, fine; if not, I think we need to think out of the box a little bit.

I’m a sysadmin wannabe and only know some basic Python, but I need a difficult task that makes me sweat, if not I’m not really motivated! :-)
This is my very first intervention so please tell me if there is something that I’m missing, in terms of code of conduct speaking. I’d like to research and resolve this issue even if I may need some mentorship. I do not have sufficient Internet connection speed to really set up a mirror, but I could ‘simulate’ an rsyncd on localhost, for testing purposes.
The research I’ve done already;
0) So you don’t want a solution that implies typical use of ssh here, by letting ssh establish the tunnel, or have I missed something in your comment? Using this solution would make the use of TLS Certificates rather unnecessary, taking into account that PubKey authentication over an encrypted tunnel does the job quite well.
1) TLS-Certificate-based system.
Is it possible to have certificates for rsync protocol?

https://letsencrypt.org/docs/faq/
[QUOTE]Does Let’s Encrypt issue certificates for anything other than SSL/TLS for websites?
Let’s Encrypt certificates are standard Domain Validation certificates, so you can use them for any server that uses a domain name, like web servers, mail servers, FTP servers, and many more. [END OF QUOTE].

The problem here is that there is no “application service standard” (unlike https, imaps, pops, and others) so there isn’t a ‘rsyncs’ protocol and no standardized port.
Using the SubjectAlternativeName (SAN) of x509 infrastructure system one can use the certificate issued for the fully qualified domain where rsyncd is hosted, by inserting/registering (application service) subdomains as rsync.example.org as SubjectAltName.and making clients (all mirror operators) generate the correspondent client certificates. Do I miss something up to here? I’m not sure about whether, having not yet been defined a service application spec for rsync protocol (URI= rsync://) secured by TLS, it would be technically feasible at all Just introducing URI-ID rsync://.in the certificate? I have to research that a bit more. Also the mentioned stunnel solution,

TIA

mpfrs
Well, that’s positively too verbose. Sorry for that.

#23 Updated by mpfrs 2020-01-20 10:38:38

Hi,
I have done some research on the different possibilities to achieve secure communications between rsyncd on tails server and the rsync (mirror) clients. But first of all, a general question?
As they are all software or web developers, maintainers, sysadmins operating the mirrors and have all GPG keys, why not 1) use gpg keys for authentication purposes via WebOfTrust/Monkeysphere? Alternatives: 2. rsync over ssh tunnel and ssh-ca, 3. rsync over stunnel with pre-shared key and/or TLS x509 certs pkix infrastructure.
Any feedback on that from your side?

TIA

#24 Updated by mpfrs 2020-01-21 13:03:06

Here is the reference for a solution using rsync over an stunnel and TLS x509 certificates.
This solution talks explicitly about rsync (in Chapter 5.1.2.1 ff) so you can use it straight away.
As I guess that I do not have write access to the given “contribute/how/mirror” page, I post the link (1) here.

I cloned the puppet-tails repo from your git and will now reach out for the impossible, i.e. adapting the server side puppet-tails code in ../../manifests/rsync.pp. If I have any further questions I’ll come back to here.

TIA

(1) https://etutorials.org/Linux+systems/secure+linux-based+servers/Chapter+5.+Tunneling/Section+5.1.+Stunnel+and+OpenSSL+Concepts/

#25 Updated by intrigeri 2020-01-25 17:10:51

Hi!

> I’m a sysadmin wannabe and only know some basic Python, but I need a difficult task that makes me sweat, if not I’m not really motivated! :-)
> This is my very first intervention so please tell me if there is something that I’m missing, in terms of code of conduct speaking. I’d like to research and resolve this issue even if I may need some mentorship.

Welcome aboard!

If you did not read it yet, see https://tails.boum.org/contribute/how/sysadmin/ :)

> 0) So you don’t want a solution that implies typical use of ssh here

I’m personally worried about the security implications of granting random mirror operators any kind of SSH access to our infra.

> 1) TLS-Certificate-based system.
> Is it possible to have certificates for rsync protocol?
>
> https://letsencrypt.org/docs/faq/
> [QUOTE]Does Let’s Encrypt issue certificates for anything other than SSL/TLS for websites?
> Let’s Encrypt certificates are standard Domain Validation certificates, so you can use them for any server that uses a domain name, like web servers, mail servers, FTP servers, and many more. [END OF QUOTE].
>
> The problem here is that there is no “application service standard” (unlike https, imaps, pops, and others) so there isn’t a ‘rsyncs’ protocol and no standardized port.
> Using the SubjectAlternativeName (SAN) of x509 infrastructure system one can use the certificate issued for the fully qualified domain where rsyncd is hosted, by inserting/registering (application service) subdomains as rsync.example.org as SubjectAltName.and making clients (all mirror operators) generate the correspondent client certificates. Do I miss something up to here? I’m not sure about whether, having not yet been defined a service application spec for rsync protocol (URI= rsync://) secured by TLS, it would be technically feasible at all Just introducing URI-ID rsync://.in the certificate? I have to research that a bit more. Also the mentioned stunnel solution,

I’m a bit lost and I did not dive into the whole topic, so I’d like to first clarify two points to see if we’re on the same page:

  1. If the solution involves any kind of TLS tunneling software such as stunnel on the client side, then I understand what matters is: how is that tunneling software going to validate the certificate presented by our server. Right?
  2. Our mirrors currently connect anonymously to our rsync server. IMO, a solution that requires every mirror operator to generate client-side certificates is going to raise the bar too high for them (making us lose some existing mirrors and blocking new ones from joining). Also, better avoid our sysadmin or mirror teams having to maintain a CA and sign CSRs.

#26 Updated by intrigeri 2020-01-25 17:13:22

> As they are all software or web developers, maintainers, sysadmins operating the mirrors and have all GPG keys,

Actually, this assumption is not correct in practice: not all our mirror operators have OpenPGP keys (or succeed at maintaining them). But anyway:

> why not 1) use gpg keys for authentication purposes via WebOfTrust/Monkeysphere?

Do you mean for the server to authenticate clients, or the opposite?
IMO the server should not have to authenticate clients at all.