Project

General

Profile

Bug #11152

Have SSL on our rsync communications with mirrors

Added by sajolida over 3 years ago. Updated 9 months ago.

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

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Yes
Affected tool:

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

Related issues

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

History

#1 Updated by intrigeri over 3 years ago

  • 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 over 3 years ago

  • Description updated (diff)

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 over 3 years ago

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

#4 Updated by intrigeri over 3 years ago

  • 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 about 3 years ago

  • Status changed from New to Confirmed

#6 Updated by intrigeri almost 3 years ago

  • 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 over 2 years ago

  • Target version changed from Tails_2.7 to 284

#8 Updated by anonym over 2 years ago

  • Target version changed from 284 to Tails 2.10

#9 Updated by intrigeri over 2 years ago

  • 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 over 2 years ago

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

This is orthogonal to the main reasons we have to switch to HTTPS mirrors (#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 over 2 years ago

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

#12 Updated by intrigeri over 1 year ago

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

#13 Updated by u over 1 year ago

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

#14 Updated by intrigeri about 1 year ago

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

#15 Updated by intrigeri about 1 year ago

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

#16 Updated by intrigeri about 1 year ago

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 u 11 months ago

  • 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 11 months ago

  • Assignee changed from intrigeri to u

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 u 11 months ago

  • Assignee deleted (u)
  • 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 9 months ago

  • Description updated (diff)

#21 Updated by intrigeri 9 months ago

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.

Also available in: Atom PDF