[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7153 [Pluggable transport]: Don't require pluggable transport proxies to be SOCKS proxies
#7153: Don't require pluggable transport proxies to be SOCKS proxies
---------------------------------+------------------------------------------
Reporter: karsten | Owner: asn
Type: project | Status: new
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Keywords: SponsorF20130228 | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by zwol):
Some time ago I promised to write up a bit of an explanation for why
"cram[ming] all the actual addresses into the socks username/password"
isn't great for !StegoTorus.
A full configuration for the !StegoTorus client [assuming the presence of
a bunch of things that still haven't actually been implemented] is pretty
heavyweight. It looks something like this -- format not to be taken as
set in stone, but contents pretty much all necessary --
{{{
bridge example_name {
tor_id "ca8a aab2 05b3 5b13 5afc 2782 b891 b555 c6fa f824"
key "IQt2ejUA1gD927mLFXGN1daxojRa,qcjh1z8mduWejiM6IT8PdQle/UJq"
window [1356824532 1356910932]
ticket "gRT3RayKU4epkB7xPJV/p1Pm0G7faYA09vG4FAhkrqU="
addresses {
"192.0.2.1:80" {
steg http
formats [html js css pdf swf]
maxconn 6
maxrate 8000
}
"192.0.2.2:443" {
steg embed
template spdy
maxconn 2
maxrate 65535
}
"192.0.2.3:6666" {
steg irc
maxconn 1
maxrate 1000
}
// five to ten more of these
}
}
}}}
As written, that's 586 bytes long; obviously it could be more compact, but
as a ballpark estimate of how much space a good wire format would take,
zlib only manages to compress it down to 369 bytes. So we are already
uncomfortably close to the 512-byte upper limit on a SOCKS5
username/password pair; I suspect adding the anticipated five to ten more
listener addresses would put it over the limit. SOCKS4a doesn't have that
limit but I'm worried about compatibility issues; most of the SOCKS code
out there probably blithely assumes short usernames and passwords. (We do
control both sides of the SOCKS dialogue, so maybe this concern is
unwarranted.)
In addition, having SOCKS support in !StegoTorus ''at all'' is
inconvenient. It's only about 800 lines of code (not counting tests), but
they add complexity to the connection setup and teardown logic, which has,
over the lifetime of the project, been by far the most troublesome
component to get right. There are still several known bugs in there and
no doubt more I haven't even noticed yet. Removing SOCKS would allow (in
my opinion) a significant and worthwhile simplification of that component.
Configuring !StegoTorus independently of Tor may also prove more
convenient in the larger picture. The "DEFIANCE" architecture that was
presented at FOCI last summer contemplates packaging up pluggable-
transport configurations as "network entry tickets" and delivering them to
clients in a semi-automated manner. So there would be a controller
process that would receive basically the above configuration blob from the
network. In the current pluggable transport design, it would have to be
parsed, repackaged as a bridge descriptor in Tor's dynamic configuration,
and then repackaged again to hand off to the transport plugin. Feeding it
directly to the pluggable transport instead (as a file in the filesystem,
presumably) saves two data-reformatting operations. Furthermore, it means
!StegoTorus only needs one configuration parser, and the "ACS dance"
client needs none at all.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7153#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs