[contact.ng0@cryptolab.net: Re: [security-discuss] gnuradio project DoS attacks GNU wget users]

[contact.ng0@cryptolab.net: Re: [security-discuss] gnuradio project DoS attacks GNU wget users]

[ng0]

Hi,

I don't like repeating myself when I have written the content before.
So going by the message below, I'd like to change the way we provide
download links and use the http protocol for our downloads at
gnu.org/s/guix. Currently we only offer the ftp protocol links. The
ports 20 and 21 are commonly blocked in the tor network by relays, that
I was able to telnet to port 21 of alpha.gnu.org was just luck.

Changing this would make our downloads more accessible than they are now.

If there are no objections I will prepare the patch for the website as
soon as I have time to do it.

It would not fix
the fact that we use ftp:// internally in some downloads (which breaks
guix package --fallback when you try to torify guix), but this could
be fixed later.
----- Forwarded message from ng0 <contact.ng0@cryptolab.net> -----

Date: Fri, 3 Mar 2017 10:54:56 +0000
From: ng0 <contact.ng0@cryptolab.net>
To: Richard Stallman <rms@gnu.org>, hellekin@gnu.org, ams@gnu.org, bugs@gnu.support, gnu-system-discuss@gnu.org, anonymous@foto.nl1.torservers.net, mail2news@nym.alias.net, security-discuss@gnu.org
Subject: Re: [security-discuss] gnuradio project DoS attacks GNU wget users

On 17-03-02 20:08:39, ng0 wrote:
> On 17-03-02 11:50:09, Richard Stallman wrote:
> > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> > [[[ whether defending the US Constitution against all enemies,     ]]]
> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > 
> >   > As far as I perceive it, ftp.gnu.org and the alpha ftp do not provide
> >   > any access to be used from tor exit nodes.
> > 
> > This sounds like a real problem.  Can someone present a specific test case
> > that fails?
> 
> That's as easy as running tor with a configuration where you exclude
> at least exit-nodes located in the USA. Then you will try to download
> any file on one of the download locations of gnu, with a graphical
> webbrowser - it does not have to be torbrowser - you pass it the
> arguments to use the socks5 proxy of tor as described in the torproject
> website documentation, and just trying to establish a connection to
> ftp.gnu.org will fail with "Error: Bad IP connecting".
> 
> I have not checked my config in a while, but this shows that there's at
> least an problem if you connect not from within the USA. I can't recall
> if I ever had a good exit-node connecting to ftp.gnu.org, but I doubt it.

I have a correction to make: after someone else in a conversation told
me that it works for them, I tried to reproduce my problem. THe problem
is just when I use the ftp:// links, everything else works.

Which means, `torify telnet alpha.gnu.org 21' worked as well as
accessing the ftp over `http://alpha.gnu.org' and `http://ftp.gnu.org',
previously I assumed the ftp of gnu.org is still limited to only ftp
port access. So there is a problem with port 21 and maybe 20, but this
problem exists only because a majority of tor relays filter those ports.

I think the only improvement GNU can make is to have a list of onion
services, if GNU wants to. This can be achieved like Debian does with
https://onion.debian.org/ but it can also be achieved with sub domains
to just one onion. For an example take a look at http://secushare.org/
and http://youbroketheinternet.org where secushare.org mentions the
onion at the bottom of the page and for the second domain I have
forgotten where the anchor for the "Why not HTTPS" is.

> >   > I find this annoying every time I have to check releases, update
> >   > software for Guix, etc. If mirroring would be an option I would run an
> >   > .onion mirror.
> > 
> > Last I heard we had lots of mirrors.  Making another kind of mirror
> > would be useful too.
> > 
> > -- 
> > Dr Richard Stallman
> > President, Free Software Foundation (gnu.org, fsf.org)
> > Internet Hall-of-Famer (internethalloffame.org)
> > Skype: No way! See stallman.org/skype.html.
> > 
> 
> Below I use "mirrors" when I refer to the root download architecture at
> gnu.org, the exception is the provided mirror which should be clear from
> context.
> 
> If this (whereby I mean providing .onion access at the root level
> of software distribution, the gnu.org servers) is not or not right now
> possible to be provided by the FSF/GNU[0], I strongly consider to
> provide an .onion mirror with the intention to add .gnu gnunet later on.
> However there are problems:
> 
> * I'm not looking really forward to administrate server(s) again, even
>   if the underlying system makes administration easier.
> * I'm limited in resources both financially and time to invest.
> * My non-commercial ISP of choice is prepared for lots of traffic, they
>   even have some tor exit- and non-exit relays/nodes in their network,
>   but if this mirror would be used it would be a centralization of
>   service which would be an easy target to take down, in addition to
>   testing out how much traffic is okay for their infrastructure. Last
>   time I ran an tor non-exit relay in there it was still okay with
>   several TB of data per month.
> 
> I know I can just mirror some (and not all) mirrors of gnu.org, reducing
> the size which is needed. At the current size of all gnu.org mirrors
> this results in ~125GiB. Taking in consideration the operation system to
> add and that at IN-Berlin eV (the ISP) you can only buy disk space in 25
> sizes (n times 25) I get less than 20 Euro / month.
> Now the consideration of the choice of datacenter vs "other places" and
> therefore the choice of machine in use is how much electricity is
> wasted in the process.
> I have to think about compromisses of use vs costs as the ideal solution
> would be to also provide a service for binary substitutes similar to
> what's offered from https://hydra.gnu.org at the moment.
> 
> 0: I'm not sure who's responsible for the server maintenance, I know
> both parties are involved depending on the level of maintenance.
> 


----- End forwarded message -----

Re: [contact.ng0@cryptolab.net: Re: [security-discuss] gnuradio project DoS attacks GNU wget users]

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

ng0 <contact.ng0@cryptolab.net> writes:

[...]
>
> I have a correction to make: after someone else in a conversation told
> me that it works for them, I tried to reproduce my problem. THe problem
> is just when I use the ftp:// links, everything else works.
>
> Which means, `torify telnet alpha.gnu.org 21' worked as well as
> accessing the ftp over `http://alpha.gnu.org' and `http://ftp.gnu.org',
> previously I assumed the ftp of gnu.org is still limited to only ftp
> port access. So there is a problem with port 21 and maybe 20, but this
> problem exists only because a majority of tor relays filter those ports.
>
> I think the only improvement GNU can make is to have a list of onion
> services, if GNU wants to. This can be achieved like Debian does with
> https://onion.debian.org/ but it can also be achieved with sub domains
> to just one onion. For an example take a look at http://secushare.org/
> and http://youbroketheinternet.org where secushare.org mentions the
> onion at the bottom of the page and for the second domain I have
> forgotten where the anchor for the "Why not HTTPS" is.
>
[...]

I would like to add that there is a software called onionbalance which
is useful for deloying hidden service[0].

[0]: https://blog.torproject.org/blog/cooking-onions-finding-onionbalance

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [contact.ng0@cryptolab.net: Re: [security-discuss] gnuradio project DoS attacks GNU wget users]

[ng0]

On 17-03-03 20:42:09, Alex Vong wrote:
> ng0 <contact.ng0@cryptolab.net> writes:
> 
> [...]
> >
> > I have a correction to make: after someone else in a conversation told
> > me that it works for them, I tried to reproduce my problem. THe problem
> > is just when I use the ftp:// links, everything else works.
> >
> > Which means, `torify telnet alpha.gnu.org 21' worked as well as
> > accessing the ftp over `http://alpha.gnu.org' and `http://ftp.gnu.org',
> > previously I assumed the ftp of gnu.org is still limited to only ftp
> > port access. So there is a problem with port 21 and maybe 20, but this
> > problem exists only because a majority of tor relays filter those ports.
> >
> > I think the only improvement GNU can make is to have a list of onion
> > services, if GNU wants to. This can be achieved like Debian does with
> > https://onion.debian.org/ but it can also be achieved with sub domains
> > to just one onion. For an example take a look at http://secushare.org/
> > and http://youbroketheinternet.org where secushare.org mentions the
> > onion at the bottom of the page and for the second domain I have
> > forgotten where the anchor for the "Why not HTTPS" is.
> >
> [...]
> 
> I would like to add that there is a software called onionbalance which
> is useful for deloying hidden service[0].
> 
> [0]: https://blog.torproject.org/blog/cooking-onions-finding-onionbalance


But that wasn't really what I asked for here. The email was just for
reference, you can reply to the original thread if you want to.

Re: [contact.ng0@cryptolab.net: Re: [security-discuss] gnuradio project DoS attacks GNU wget users]

[Leo Famulari]

On Fri, Mar 03, 2017 at 11:08:43AM +0000, ng0 wrote:
> Hi,
> 
> I don't like repeating myself when I have written the content before.
> So going by the message below, I'd like to change the way we provide
> download links and use the http protocol for our downloads at
> gnu.org/s/guix. Currently we only offer the ftp protocol links. The
> ports 20 and 21 are commonly blocked in the tor network by relays, that
> I was able to telnet to port 21 of alpha.gnu.org was just luck.

I'm not that familiar with Tor, so forgive me if I'm asking questions
that everyone else already knows the answer to.

Would it be enough to offer an HTTPS source for our `gnu.org/s/guix`
downloads? Would that work for Tor users? Or do we have to create an
Onion service, too?

What are the pros and cons?

If the HTTPS link can be accessed reliably over Tor, I think that would
be better for us, because it would reduce the amount of Guix sysadmin
work.

> It would not fix
> the fact that we use ftp:// internally in some downloads (which breaks
> guix package --fallback when you try to torify guix), but this could
> be fixed later.

Are you talking about using FTP to download the sources of some
packages?

Re: [contact.ng0@cryptolab.net: Re: [security-discuss] gnuradio project DoS attacks GNU wget users]

[ng0]

On 17-03-03 12:50:17, Leo Famulari wrote:
> On Fri, Mar 03, 2017 at 11:08:43AM +0000, ng0 wrote:
> > Hi,
> > 
> > I don't like repeating myself when I have written the content before.
> > So going by the message below, I'd like to change the way we provide
> > download links and use the http protocol for our downloads at
> > gnu.org/s/guix. Currently we only offer the ftp protocol links. The
> > ports 20 and 21 are commonly blocked in the tor network by relays, that
> > I was able to telnet to port 21 of alpha.gnu.org was just luck.
> 
> I'm not that familiar with Tor, so forgive me if I'm asking questions
> that everyone else already knows the answer to.

There are no unnecessary questions, I'll gladly answer.

> Would it be enough to offer an HTTPS source for our `gnu.org/s/guix`

I think what happened here is, everyone seems to miss the point of my
email. The content below is just for reference, the question was just to
change the ftp:// links to http:// .. and I just found out, to answer
your question, that https://alpha.gnu.org/ works too.

> downloads? Would that work for Tor users? Or do we have to create an
> Onion service, too?

That's being solved on sys admin level of GNU and/or FSF, at least
that's what I understand from what rms wrote further in the thread.

> What are the pros and cons?
> 
> If the HTTPS link can be accessed reliably over Tor, I think that would
> be better for us, because it would reduce the amount of Guix sysadmin
> work.

The https works. The problem I have at the moment is that the homepage
uses ftp:// as the only links for alpha.gnu.org and the signatures.
There are other uses of ftp:// in the source of the code, not the
website, which I have to look at more closely to decide what can be
changed.

> > It would not fix
> > the fact that we use ftp:// internally in some downloads (which breaks
> > guix package --fallback when you try to torify guix), but this could
> > be fixed later.
> 
> Are you talking about using FTP to download the sources of some
> packages?
> 

No, about guix daemon using guix download to fetch the sources over ftp.
I'm still working my way towards an "torified" guix, but I know that
port 21 and 20 are often (there are exceptions) blocked by tor relay
admins. This results in ftp:// download scheme not working.