A Tor hidden service for update metadata would have significant advantages over the current system:
It would be nice to have this by 2020/01/31
We can look into this... I suspect it would be painfully slow. :(
Requests are already pretty anonomyous... users reach mirrors.fedoraproject.org and get a metalink, then contact one or more mirrors from that metalink.
I already download all updates over Tor, and many other users of QubesOS do as well. It isn’t the default, but turning it on only requires uncommenting two lines of code. Personally, I consider the advantages to be well worth the slow downloads.
To be clear, I am only referring to the metalink server, not the actual metadata files. The metalink server has a SHA256 hash of the metadata files, so there is no loss of security.
I trust mirrors.fedoraproject.org far more than I do the mirrors, to be honest. One major advantage of a hidden service is that it guarantees that even if someone gets a rogue cert for mirrors.fedoraproject.org, they still can’t send a malicious metadata file. Since we don’t have signed metadata, that is a significant win.
mirrors.fedoraproject.org
Metadata Update from @zlopez: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: high-trouble, low-gain, ops
I do not understand the request, is it install a HS on mirrors.fedoraproject.org and advertise the url ? Or have it by default for everybody ?
I see what is needed on server side (installing a tor hiddenservice is not hard and do not requires much maintenance, for non HA case, and I guess not much for a basic HA setup) for the 1st, but the 2nd requires more work on the client side part (so likely start a discussion on -devel), and would need some work regarding scaling (e.g. is the tor network able to scale for getting millions of people at once, are we able to support the charge with HS)
I do not understand the request, is it install a HS on mirrors.fedorapr= oject.org and advertise the url ? Or have it by default for everybody ?
Install a v3 hidden service on mirrors.fedoraproject.org and include it (= off by default) in the .repo files. Optionally, it can be turned on by d= efault for users who have the Tor package installed, provided that this d= oes not expose local privilege escalation attacks (such as a user pretend= ing to be the Tor daemon).
I see what is needed on server side (installing a tor hiddenservice is = not hard and do not requires much maintenance, for non HA case, and I gue= ss not much for a basic HA setup) for the 1st, but the 2nd requires more = work on the client side part (so likely start a discussion on -devel), an= d would need some work regarding scaling (e.g. is the tor network able to= scale for getting millions of people at once, are we able to support the= charge with HS)
The main purpose of this is as an interim stand-in for certificate pinnin= g on the client side. Therefore, only the metalink files need to be avai= lable from it, but they need to have the same integrity guarantees as mir= rors.fedoraproject.org has.
Metadata Update from @zlopez: - Issue assigned to eddiejennings
@eddiejennings Are you still interested in this ticket?
@eddiejennings and I will look into this after our deep dive into Tor for the April 14th learning topic.
Time is allowing me to get back to researching this. I'm currently figuring out exactly how traffic flows normally, so I can then figure out how adding a Tor hidden service will affect things.
@demiobenour
How are you envisioning the traffic flow if you were to put mirrors.fedoraproject.org behind a Tor hidden service? We would have most of our users sending traffic to mirrors.fedoraproject.org as they have always done, as well as users in this scenario sending traffic to the .onion address for mirrors.fedoraproject.org. How can we account for this?
I'll be the first to say, I am no master of Tor hidden services. After trying to set something up in my lab to simulate how something behind a Tor hidden service would respond to just "normal" HTTP traffic, I have a hard time seeing how this idea would work.
Discussed about this during our weekly meeting and we are closing because we didnt receive feedback. Feel free to reopen if needed
Metadata Update from @phsmoura: - Issue close_status updated to: Will Not/Can Not fix - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.