port number conflict: 8123 is (or was) used by polipo and is blocked by TorButton #536

New Issue

zooko · 2008-11-18T02:16:07Z

zooko commented

2008-11-18 02:16:07 +00:00

When people install polipo -- some sort of add-on or tool related to tor -- then their firefox starts refusing to let them view port 8123. There is no button or hyperlink to say "Yeah, yeah, let me view this anyway.". The only work-around is to learn how to edit the port blacklist in firefox.

I've heard the rumor that this blacklisting might be because someone did, or could, break the anonymity of tor users by CSRF attack on port 8123.

http://www.pps.jussieu.fr/~jch/software/polipo/manual/Web-interface.html

It seems like the best solution is probably for Tahoe to choose a new port number.

Adding Cc: tahoe-dev@allmydata.org so that other people who know something about this can chime in.

When people install polipo -- some sort of add-on or tool related to tor -- then their firefox starts refusing to let them view port 8123. There is no button or hyperlink to say "Yeah, yeah, let me view this anyway.". The only work-around is to learn how to edit the port blacklist in firefox. I've heard the rumor that this blacklisting might be because someone did, or could, break the anonymity of tor users by CSRF attack on port 8123. <http://www.pps.jussieu.fr/~jch/software/polipo/manual/Web-interface.html> It seems like the best solution is probably for Tahoe to choose a new port number. Adding Cc: tahoe-dev@allmydata.org so that other people who know something about this can chime in.

zooko added the

labels 2008-11-18 02:16:07 +00:00

zooko added this to the 1.3.0 milestone 2008-11-18 02:16:07 +00:00

zooko commented

2008-11-25 23:48:06 +00:00

Brian previously posted a good summary of this to the tahoe-dev list:

http://allmydata.org/pipermail/tahoe-dev/2008-August/000774.html

I've written a patch to convert the default port of tahoe from 8123 to 3456, but I'm holding off on pushing that patch until our buildbot is all green again. (#534)

Ooh! Buildbot is green again! Pushing my patch!

Brian previously posted a good summary of this to the tahoe-dev list: <http://allmydata.org/pipermail/tahoe-dev/2008-August/000774.html> I've written a patch to convert the default port of tahoe from 8123 to 3456, but I'm holding off on pushing that patch until our buildbot is all green again. (#534) Ooh! Buildbot is green again! Pushing my patch!

zooko commented

2008-11-26 00:00:24 +00:00

fixed by changeset:fe6abac87baf1786

zooko added the

fixed

label 2008-11-26 00:00:24 +00:00

zooko closed this issue

2008-11-26 00:00:24 +00:00

warner commented

2008-11-26 00:02:50 +00:00

sigh. I kind of liked 8123, and I'm a little worried about what might break with this change.

secorp commented

2008-11-26 00:05:16 +00:00

I sigh with Brian - is this really necessary? I too am afraid that this will cause a lot of unnecessary debugging time due to port mis-matches.

tahoe-lafs removed the

fixed

label 2008-11-26 00:05:16 +00:00

tahoe-lafs reopened this issue

2008-11-26 00:05:16 +00:00

zooko changed title from ~~port number conflict: 8123 is (or was) used by polipo~~ to port number conflict: 8123 is (or was) used by polipo and is blocked by TorButton

2008-11-26 02:10:28 +00:00

warner commented

2008-12-03 23:50:49 +00:00

so, since zooko pushed the patch to implement this change, I must either explain/justify it in the release notes and NEWS file, or revert it. We've discussed both back and forth in IRC for the last few days.

As a data point, TCP port 3456 is reserved by IANA for the "vat" tool (which I think is the early voice-chat protocol). See http://www.iana.org/assignments/port-numbers for details:

vat             3456/tcp   VAT default data
vat             3456/udp   VAT default data
#                          Van Jacobson <van&ee.lbl.gov>
vat-control     3457/tcp   VAT default control
vat-control     3457/udp   VAT default control
#                          Van Jacobson <van&ee.lbl.gov>

I suspect that any easy-to-type human-generated port number will suffer from this problem. That said, I also suspect that there are more people using Torbutton than using VAT these days. (in fact, it's possible that there are more people using Tahoe than VAT..)

Zooko's pointed out that he'd like to use the port number as a sort of informal grid-id, that is, a group of people who are using the same grid could choose a random free TCP port number (call it XYZ) and all configure their local tahoe nodes to listen on it. Then they can exchange URLs that point at <http://localhost:XYZ/uri/URI> and know that they'll all work. This reduces the confusion when someone uses two disparate grids and might otherwise try to look up URIa (generated on grid A) in a node that's connected to grid B.

Oh the other hand, some day I hope that we'll have grid ids embedded in the URI itself, and any tahoe node should be able to connect to any grid to retrieve a file, in which case we'd prefer that all tahoe nodes use the same webport.

so, since zooko pushed the patch to implement this change, I must either explain/justify it in the release notes and NEWS file, or revert it. We've discussed both back and forth in IRC for the last few days. As a data point, TCP port 3456 is reserved by IANA for the "vat" tool (which I think is the early voice-chat protocol). See <http://www.iana.org/assignments/port-numbers> for details: ``` vat 3456/tcp VAT default data vat 3456/udp VAT default data # Van Jacobson <van&ee.lbl.gov> vat-control 3457/tcp VAT default control vat-control 3457/udp VAT default control # Van Jacobson <van&ee.lbl.gov> ``` I suspect that any easy-to-type human-generated port number will suffer from this problem. That said, I also suspect that there are more people using Torbutton than using VAT these days. (in fact, it's possible that there are more people using Tahoe than VAT..) Zooko's pointed out that he'd like to use the port number as a sort of informal grid-id, that is, a group of people who are using the same grid could choose a random free TCP port number (call it XYZ) and all configure their local tahoe nodes to listen on it. Then they can exchange URLs that point at `<http://localhost:XYZ/uri/URI>` and know that they'll all work. This reduces the confusion when someone uses two disparate grids and might otherwise try to look up URIa (generated on grid A) in a node that's connected to grid B. Oh the other hand, some day I hope that we'll have grid ids embedded in the URI itself, and any tahoe node should be able to connect to any grid to retrieve a file, in which case we'd prefer that all tahoe nodes use the same webport.

warner commented

2008-12-03 23:54:26 +00:00

Also, as far as IANA is concerned, '8123' is up for grabs (i.e. the Torbutton folks took the same ad-hoc grab-something-that-looks-free approach that we did). Again from http://www.iana.org/assignments/port-numbers :

privoxy         8118/tcp    Privoxy HTTP proxy
privoxy         8118/udp    Privoxy HTTP proxy
#                           Andreas Oesterhelt <oes&privoxy.org> June 2002
#               8119-8120   Unassigned
apollo-data     8121/tcp    Apollo Data Port
apollo-data     8121/udp    Apollo Data Port
#                           Anthony Carrabino <anthonyc&vistasoftware.com> August 2003
#               8123-8127   Unassigned
paycash-online  8128/tcp    PayCash Online Protocol
paycash-online  8128/udp    PayCash Online Protocol

Also, as far as IANA is concerned, '8123' is up for grabs (i.e. the Torbutton folks took the same ad-hoc grab-something-that-looks-free approach that we did). Again from <http://www.iana.org/assignments/port-numbers> : ``` privoxy 8118/tcp Privoxy HTTP proxy privoxy 8118/udp Privoxy HTTP proxy # Andreas Oesterhelt <oes&privoxy.org> June 2002 # 8119-8120 Unassigned apollo-data 8121/tcp Apollo Data Port apollo-data 8121/udp Apollo Data Port # Anthony Carrabino <anthonyc&vistasoftware.com> August 2003 # 8123-8127 Unassigned paycash-online 8128/tcp PayCash Online Protocol paycash-online 8128/udp PayCash Online Protocol ```

zooko commented

2008-12-04 12:46:39 +00:00

"Oh the other hand, some day I hope that we'll have grid ids embedded in the URI itself, and any tahoe node should be able to connect to any grid to retrieve a file, in which case we'd prefer that all tahoe nodes use the same webport."

I'm skeptical that grid ids embedded into the URI are a good idea. They might be, but they might not. In either case, the prospect of that future feature probably shouldn't have a big influence on the current question of port numbers -- the current issues with port numbers are more important.

As I emphasized on IRC, I have the following desires about port numbers:

Not disrupting the allmydata.com roll-out.
Making "wrong grid errors" clearer.
The Tor conflict.

"Oh the other hand, some day I hope that we'll have grid ids embedded in the URI itself, and any tahoe node should be able to connect to any grid to retrieve a file, in which case we'd prefer that all tahoe nodes use the same webport." I'm skeptical that grid ids embedded into the URI are a good idea. They might be, but they might not. In either case, the prospect of that future feature probably shouldn't have a big influence on the current question of port numbers -- the current issues with port numbers are more important. As I emphasized on IRC, I have the following desires about port numbers: 1. Not disrupting the allmydata.com roll-out. 2. Making "wrong grid errors" clearer. 3. The Tor conflict.

warner commented

2008-12-06 05:27:26 +00:00

I don't think we've come to a resolution on this. I don't know how to justify switching to a port that is assigned by IANA.

I've observed three different deployment scenarios that are affected by the choice of default port. The first is a single user giving Tahoe a try at home (our developer community). This user tends to run a single node, and intends to use its webapi. I think these users would most benefit from a low-effort path to their Tahoe node listening on a webport that matches what the documentation uses in its examples.

The second is me, when I build a local test grid, with multiple nodes on a single machine. I am often surprised by the fact that N-1 of these nodes fail at startup, because they all defaulted to the same webport, and only the first node started was able to claim it. I added the "--webport none" option to make this easier for me to set up, but in fact I usually forget and have to go back and edit the node configs (usually to disable the webport on all but one node).

The third is allmydata (as represented by Zandr) when we set up a new webapi node on our commercial grid. In some cases, these nodes are fronted by an HTTP load-balancing proxy. In others, they live on a round-robin DNS name. In the latter case, it is important that all the nodes listen on the same port, so we advertise HOST:8123 (and have customer-side tools which embed that base URL). The round-robin DNS case obligates us to only run one webapi node per ip address, of course.

I'm not worried so much about the continuing allmydata.com rollout: it's a simple matter to add the appropriate --webport argument to the scripts we use when creating these nodes. I'm more concerned about an apparently gratuitous change which will bring the (new) docs into conflict with existing user's (old) nodes.

That said, I'm not feeling as strongly about this change as I was a week ago. Maybe I'm just desperate to get this release out :).

I don't think we've come to a resolution on this. I don't know how to justify switching *to* a port that is assigned by IANA. I've observed three different deployment scenarios that are affected by the choice of default port. The first is a single user giving Tahoe a try at home (our developer community). This user tends to run a single node, and intends to use its webapi. I think these users would most benefit from a low-effort path to their Tahoe node listening on a webport that matches what the documentation uses in its examples. The second is me, when I build a local test grid, with multiple nodes on a single machine. I am often surprised by the fact that N-1 of these nodes fail at startup, because they all defaulted to the same webport, and only the first node started was able to claim it. I added the "--webport none" option to make this easier for me to set up, but in fact I usually forget and have to go back and edit the node configs (usually to disable the webport on all but one node). The third is allmydata (as represented by Zandr) when we set up a new webapi node on our commercial grid. In some cases, these nodes are fronted by an HTTP load-balancing proxy. In others, they live on a round-robin DNS name. In the latter case, it is important that all the nodes listen on the same port, so we advertise HOST:8123 (and have customer-side tools which embed that base URL). The round-robin DNS case obligates us to only run one webapi node per ip address, of course. I'm not worried so much about the continuing allmydata.com rollout: it's a simple matter to add the appropriate --webport argument to the scripts we use when creating these nodes. I'm more concerned about an apparently gratuitous change which will bring the (new) docs into conflict with existing user's (old) nodes. That said, I'm not feeling as strongly about this change as I was a week ago. Maybe I'm just desperate to get this release out :).

zooko commented

2008-12-06 13:29:00 +00:00

I'm pretty sure VAT doesn't mind if we use its port number, because it is dead. I worked in the VoIP field for a few years (2002, 2004, 2005) and I never heard of it. (By the way, Van Jacobson is a great Internet engineer, and since his recent enthusiasm is "Content-centric networking" -- http://video.google.com/videoplay?docid=-6972678839686672840 -- I'm hoping he'll notice Tahoe. ;-))

I agree with you that having a single fixed port number as the default and as used in the docs is useful for new users.

So, as far as I can tell, the current trunk with the default port and docs being 3456, plus appropriate controls on the part of allmydata.com to make sure that nodes they deploy use 8123, should be good enough.

I'm pretty sure VAT doesn't mind if we use its port number, because it is dead. I worked in the VoIP field for a few years (2002, 2004, 2005) and I never heard of it. (By the way, Van Jacobson is a great Internet engineer, and since his recent enthusiasm is "Content-centric networking" -- <http://video.google.com/videoplay?docid=-6972678839686672840> -- I'm hoping he'll notice Tahoe. ;-)) I agree with you that having a single fixed port number as the default and as used in the docs is useful for new users. So, as far as I can tell, the current trunk with the default port and docs being 3456, plus appropriate controls on the part of allmydata.com to make sure that nodes they deploy use 8123, should be good enough.

zooko commented

2009-02-04 20:05:50 +00:00

We're going to ship tahoe-1.3.0 with a default port number of 3456, but the bigger issue is that each tahoe grid should use a different port number, so people should try not to rely on the default port number.

zooko added the

fixed

label 2009-02-04 20:05:50 +00:00

zooko closed this issue

2009-02-04 20:05:50 +00:00

Sign in to join this conversation.