The deadline for students submitting applications is _MARCH 31_.

I’ve put up a page with more details here:
  http://anonymous.livelyblog.com/2008/01/04/state-of-the-onion/ Tor allows people to run location hidden services. These are services who run on Tor-clients (running as a bridge or server is not required) who allow people to conenct to them through servers in the Tor-network.

The Another Porn Exchange (APE) and Yet Another Porn Exchange (YAPE) seems to be very popular.

Forums

The various forums are also quite popular. Like The Onionforum. People go there and talk about all kinds of things, mostly normal things like politics and the various other subjects who are popular on the normal Internet. There are also some post on subjects who I assume nobody would dare talk about without being anonymous, but this is actually less frequently the case. Most people go there and talk about the same things they talk about in other forums, except that they happen to be anonymous when using this service and happen to not be able to find out who is running the forum.

There’s also http://xiwayy2kn32bo3ko.onion/tor/, a forum where people write using small drawings who look like houses, squares, circles and other odd things. There are rumors that people in Asia understand these drawings.

Documents, books, etc

Alex Jones of Infowars.com and PrisonPlanet.com has “read the federal documents, and know their TOTAL PLAN”. He is a pretty popular guy because of it, and is even mentioned is various posts the core.onion because of is knowledge of such documents. Many interesting documents are available on various onion sites. The Tor Library has a quite a few. Bebop’s Home in Onionspace has a great collection of cyberpunk (and other) documents. You may also want to read Thomas Paine’s Common Sense and The Federalist papers, which were originally published anonymously. There are also Tor mirrors of sites on the normal Internet, such as textfiles.com. A interesting document leaked out of the German police is also worth reading. Orwell’s 1984, and other books, are available at a text files at http://2evy5quvwdyiyuqr.onion/mirrors/

Blogs!

Blogs, like this one, are read by many people. There are, naturally, many onion blogs too. Like http://balrqba4×57ofa6s.onion/, which is mostly about Tor-related software. Monster warns that the Ice-Age is Coming.

Videos

Some people do not like WTO, which is understandable since they are powertripping tyrants who want dictatorial control over you and your family. A mirror of quite a few WTO protest videos exist within in onion-land.

Chat and talk about how your day was

People like to talk about their day anonymously. There are many onoin IRC servers. There’s even a web based chat.

Software

The masked operating system can (only?) be downloaded using Tor. There are also various attack and defend tools available. If you find yourself under computer attack by commie nazi then perhaps you should go there and find out what they are using to attack you and how to defend yourself. http://gdos2zurqy7miigj.onion/pub/ allows you to download GnuPG and other nice things.

Files…

Sites such as sTORage and the Anonymous Upload Center allow people to upload and download files. All sorts of things are available that those kind of services. All they have in common is that the content serviced as files…

Games!

There are also some pirated consolegames for the MAME arcade machine emulator floating around. I guess it is a good idea to hide who you are when you are making hundres of pirated MAME ROMS available to the general public - even though there are actually quite a few sites offering the same games on the regular Internet.

Search

You can use Torgle to search.

Gone with the wind…

It appears that many of the previously popular .onion sites are now gone with the wind. Which is understandable, it is hard to maximise profits now by running these services: How do you get anyone to pay you when the visitors of you site are all Tor-users who are unwilling to tell you who or where they are?

nnqtnsoohprzqcke.onion was a popular .onion-only search-engine based on the datapark motor. It’s now gone with the wind, just like many other onion sites.

Interesting? not really..

Some onions are just plain uninteresting. Like http://metaq3ayddzzcfzc.onion/, which only tells you that “It works!”. That’s probably great, but it’s really not that interesting.

Starting points

The http://anegvjpd77xuxo45.onion/services/ services list periodically checks onion-sites it knows about and lists which are up and which are down. Many people like to add their sites to core.onion, since that is listed in the Tor-page on the heavily-censored NATO (=nazi) propaganda vessle “Wikipedia”. There are “HiddenServices” pages here, here and here. The Torgle search engine is also a nice starting point, just type in what you are looking for and it will (mostly) find something about that.

Have fun in onion-land! And remember, think before posting in forums and such. What you say can be used to identify who you are, or where you are, what your interests are and so on regardless of the connection being anonymous or not. If you post your phone number then everybody knows who you are, regardless of how you post it…

Older Tor-presentations (From 23c3 and WTH) can be downloaded from The TorrentChannel’s Technology page.

In other related news, Roger Dingledine has now prepared and posted secret Tor-presentation slides from the 24th Chaos Communication Congress which was held in Berlin, Germany this week.

These secret slides are now available for your studying pleasure at http://freehaven.net/~arma/slides-24c3.p…

One last thing: Happy new year!

From: Roger Dingledine <arma@mit.edu>
To:  or-talk at freehaven.net
Date: Today 02:00:48

Tor 0.2.0.10-alpha adds a third v3 directory authority run by Mike Perry,
adds most of Karsten Loesing’s new hidden service descriptor format, fixes
a bad crash bug and new bridge bugs introduced in 0.2.0.9-alpha, fixes
many bugs with the v3 directory implementation, fixes some minor memory
leaks in previous 0.2.0.x snapshots, and addresses many more minor issues.

Tor 0.2.0.11-alpha fixes some build problems with the previous
snapshot. It also includes a more secure-by-default exit policy for
relays, fixes an enormous memory leak for exit relays, and fixes another
bug where servers were falling out of the directory list.

Tor 0.2.0.12-alpha fixes some more build problems as well as a few
minor bugs.

 https://www.torproject.org/download.html

Changes in version 0.2.0.12-alpha - 2007-11-16
This twelfth development snapshot fixes some more build problems as
well as a few minor bugs.

o Compile fixes:
- Make it build on OpenBSD again. Patch from tup.
- Substitute BINDIR and LOCALSTATEDIR in scripts. Fixes
package-building for Red Hat, OS X, etc.

o Minor bugfixes (on 0.1.2.x):
- Changing the ExitPolicyRejectPrivate setting should cause us to
rebuild our server descriptor.

o Minor bugfixes (on 0.2.0.x):
- When we’re lacking a consensus, don’t try to perform rendezvous
operations. Reported by Karsten Loesing.
- Fix a small memory leak whenever we decide against using a
newly picked entry guard. Reported by Mike Perry.
- When authorities detected more than two relays running on the same
IP address, they were clearing all the status flags but forgetting
to clear the “hsdir” flag. So clients were being told that a
given relay was the right choice for a v2 hsdir lookup, yet they
never had its descriptor because it was marked as ‘not running’
in the consensus.
- If we’re trying to fetch a bridge descriptor and there’s no way
the bridge authority could help us (for example, we don’t know
a digest, or there is no bridge authority), don’t be so eager to
fall back to asking the bridge authority.
- If we’re using bridges or have strictentrynodes set, and our
chosen exit is in the same family as all our bridges/entry guards,
then be flexible about families.

o Minor features:
- When we negotiate a v2 link-layer connection (not yet implemented),
accept RELAY_EARLY cells and turn them into RELAY cells if we’ve
negotiated a v1 connection for their next step. Initial code for
proposal 110.

Changes in version 0.2.0.11-alpha - 2007-11-12
This eleventh development snapshot fixes some build problems with
the previous snapshot. It also includes a more secure-by-default exit
policy for relays, fixes an enormous memory leak for exit relays, and
fixes another bug where servers were falling out of the directory list.

o Security fixes:
- Exit policies now reject connections that are addressed to a
relay’s public (external) IP address too, unless
ExitPolicyRejectPrivate is turned off. We do this because too
many relays are running nearby to services that trust them based
on network address. Bugfix on 0.1.2.x.

o Major bugfixes:
- Fix a memory leak on exit relays; we were leaking a cached_resolve_t
on every successful resolve. Reported by Mike Perry; bugfix
on 0.1.2.x.
- On authorities, never downgrade to old router descriptors simply
because they’re listed in the consensus. This created a catch-22
where we wouldn’t list a new descriptor because there was an
old one in the consensus, and we couldn’t get the new one in the
consensus because we wouldn’t list it. Possible fix for bug 548.
Also, this might cause bug 543 to appear on authorities; if so,
we’ll need a band-aid for that. Bugfix on 0.2.0.9-alpha.

o Packaging fixes on 0.2.0.10-alpha:
- We were including instructions about what to do with the
src/config/fallback-consensus file, but we weren’t actually
including it in the tarball. Disable all of that for now.

o Minor features:
- Allow people to say PreferTunnelledDirConns rather than
PreferTunneledDirConns, for those alternate-spellers out there.

o Minor bugfixes:
- Don’t reevaluate all the information from our consensus document
just because we’ve downloaded a v2 networkstatus that we intend
to cache. Fixes bug 545; bugfix on 0.2.0.x.

Changes in version 0.2.0.10-alpha - 2007-11-10
This tenth development snapshot adds a third v3 directory authority
run by Mike Perry, adds most of Karsten Loesing’s new hidden service
descriptor format, fixes a bad crash bug and new bridge bugs introduced
in 0.2.0.9-alpha, fixes many bugs with the v3 directory implementation,
fixes some minor memory leaks in previous 0.2.0.x snapshots, and
addresses many more minor issues.

o New directory authorities:
- Set up ides (run by Mike Perry) as the third v3 directory authority.

o Major features:
- Allow tunnelled directory connections to ask for an encrypted
“begin_dir” connection or an anonymized “uses a full Tor circuit”
connection independently. Now we can make anonymized begin_dir
connections for (e.g.) more secure hidden service posting and
fetching.
- More progress on proposal 114: code from Karsten Loesing to
implement new hidden service descriptor format.
- Raise the default BandwidthRate/BandwidthBurst to 5MB/10MB, to
accommodate the growing number of servers that use the default
and are reaching it.
- Directory authorities use a new formula for selecting which nodes
to advertise as Guards: they must be in the top 7/8 in terms of
how long we have known about them, and above the median of those
nodes in terms of weighted fractional uptime.
- Make “not enough dir info yet” warnings describe *why* Tor feels
it doesn’t have enough directory info yet.

o Major bugfixes:
- Stop servers from crashing if they set a Family option (or
maybe in other situations too). Bugfix on 0.2.0.9-alpha; reported
by Fabian Keil.
- Make bridge users work again — the move to v3 directories in
0.2.0.9-alpha had introduced a number of bugs that made bridges
no longer work for clients.
- When the clock jumps forward a lot, do not allow the bandwidth
buckets to become negative. Bugfix on 0.1.2.x; fixes bug 544.

o Major bugfixes (v3 dir, bugfixes on 0.2.0.9-alpha):
- When the consensus lists a router descriptor that we previously were
mirroring, but that we considered non-canonical, reload the
descriptor as canonical. This fixes bug 543 where Tor servers
would start complaining after a few days that they don’t have
enough directory information to build a circuit.
- Consider replacing the current consensus when certificates arrive
that make the pending consensus valid. Previously, we were only
considering replacement when the new certs _didn’t_ help.
- Fix an assert error on startup if we didn’t already have the
consensus and certs cached in our datadirectory: we were caching
the consensus in consensus_waiting_for_certs but then free’ing it
right after.
- Avoid sending a request for “keys/fp” (for which we’ll get a 400 Bad
Request) if we need more v3 certs but we’ve already got pending
requests for all of them.
- Correctly back off from failing certificate downloads. Fixes
bug 546.
- Authorities don’t vote on the Running flag if they have been running
for less than 30 minutes themselves. Fixes bug 547, where a newly
started authority would vote that everyone was down.

o New requirements:
- Drop support for OpenSSL version 0.9.6. Just about nobody was using
it, it had no AES, and it hasn’t seen any security patches since
2004.

o Minor features:
- Clients now hold circuitless TLS connections open for 1.5 times
MaxCircuitDirtiness (15 minutes), since it is likely that they’ll
rebuild a new circuit over them within that timeframe. Previously,
they held them open only for KeepalivePeriod (5 minutes).
- Use “If-Modified-Since” to avoid retrieving consensus
networkstatuses that we already have.
- When we have no consensus, check FallbackNetworkstatusFile (defaults
to $PREFIX/share/tor/fallback-consensus) for a consensus. This way
we start knowing some directory caches.
- When we receive a consensus from the future, warn about skew.
- Improve skew reporting: try to give the user a better log message
about how skewed they are, and how much this matters.
- When we have a certificate for an authority, believe that
certificate’s claims about the authority’s IP address.
- New –quiet command-line option to suppress the default console log.
Good in combination with –hash-password.
- Authorities send back an X-Descriptor-Not-New header in response to
an accepted-but-discarded descriptor upload. Partially implements
fix for bug 535.
- Make the log message for “tls error. breaking.” more useful.
- Better log messages about certificate downloads, to attempt to
track down the second incarnation of bug 546.

o Minor features (bridges):
- If bridge users set UpdateBridgesFromAuthority, but the digest
they ask for is a 404 from the bridge authority, they now fall
back to trying the bridge directly.
- Bridges now use begin_dir to publish their server descriptor to
the bridge authority, even when they haven’t set TunnelDirConns.

o Minor features (controller):
- When reporting clock skew, and we know that the clock is _at least
as skewed_ as some value, but we don’t know the actual value,
report the value as a “minimum skew.”

o Utilities:
- Update linux-tor-prio.sh script to allow QoS based on the uid of
the Tor process. Patch from Marco Bonetti with tweaks from Mike
Perry.

o Minor bugfixes:
- Refuse to start if both ORPort and UseBridges are set. Bugfix
on 0.2.0.x, suggested by Matt Edman.
- Don’t stop fetching descriptors when FetchUselessDescriptors is
set, even if we stop asking for circuits. Bugfix on 0.1.2.x;
reported by tup and ioerror.
- Better log message on vote from unknown authority.
- Don’t log “Launching 0 request for 0 router” message.

o Minor bugfixes (memory leaks):
- Stop leaking memory every time we parse a v3 certificate. Bugfix
on 0.2.0.1-alpha.
- Stop leaking memory every time we load a v3 certificate. Bugfix
on 0.2.0.1-alpha. Fixes Bug 536.
- Stop leaking a cached networkstatus on exit. Bugfix on
0.2.0.3-alpha.
- Stop leaking voter information every time we free a consensus.
Bugfix on 0.2.0.3-alpha.
- Stop leaking signed data every time we check a voter signature.
Bugfix on 0.2.0.3-alpha.
- Stop leaking a signature every time we fail to parse a consensus or
a vote. Bugfix on 0.2.0.3-alpha.
- Stop leaking v2_download_status_map on shutdown. Bugfix on
0.2.0.9-alpha.
- Stop leaking conn->nickname every time we make a connection to a
Tor relay without knowing its expected identity digest (e.g. when
using bridges). Bugfix on 0.2.0.3-alpha.

- Minor bugfixes (portability):
- Run correctly on platforms where rlim_t is larger than unsigned
long, and/or where the real limit for number of open files is
OPEN_FILES, not rlim_max from getrlimit(RLIMIT_NOFILES). In
particular, these may be needed for OS X 10.5.

Official website: https://www.torproject.org/

0.1.2.18 is getting close to ready; please test it
From: Roger Dingledine
To: or-talk
Date: 2007-10-16 06:32

Hi folks,

We’re getting close to having 0.1.2.18 ready. I’ve put snapshots at

 https://tor.eff.org/dist/tor-0.1.2.17-de…
 https://tor.eff.org/dist/tor-0.1.2.17-de…

 https://tor.eff.org/dist/vidalia-bundles…
 https://tor.eff.org/dist/vidalia-bundles…

 https://tor.eff.org/dist/vidalia-bundles…
 https://tor.eff.org/dist/vidalia-bundles…

 https://tor.eff.org/dist/win32/tor-0.1.2…
 https://tor.eff.org/dist/win32/tor-0.1.2…

 https://tor.eff.org/dist/osx/Tor-0.1.2.1…
 https://tor.eff.org/dist/osx/Tor-0.1.2.1…

Please grab it, try it out, and let us know whether we broke anything.

Thanks,
–Roger

Partial list of changes in version 0.1.2.18 - 2007-10-??

• Major bugfixes (crashes):
  •     - If a connection is shut down abruptly because of something that
  •       happened inside connection_flushed_some(), do not call
  •       connection_finished_flushing(). Should fix bug 451:
  •       “connection_stop_writing: Assertion conn->write_event failed”
  •       Bugfix on 0.1.2.7-alpha.
  •     - Fix possible segfaults in functions called from
  •       rend_process_relay_cell().
•   o Major bugfixes (other):
  •     - Stop publishing a new server descriptor just because we get a
  •       HUP signal. This led (in a roundabout way) to some servers getting
  •       dropped from the networkstatus lists for a few hours each day.
  •     - Hidden services were choosing introduction points uniquely by
  •       hexdigest, but when constructing the hidden service descriptor
  •       they merely wrote the (potentially ambiguous) nickname.
  •     - Clients now use the v2 intro format for hidden service
  •       connections: they specify their chosen rendezvous point by identity
  •       digest rather than by (potentially ambiguous) nickname. These
  •       changes could speed up hidden service connections dramatically.
  •     - When looking for a circuit to cannibalize, consider family as well
  •       as identity. Fixes bug 438. Bugfix on 0.1.0.x (which introduced
  •       circuit cannibalization).
• Minor bugfixes:
  • Don’t try to access (or alter) the state file when running –list-fingerprint or –verify-config or –hash-password. (Resolves bug 499.)
  • When generating information telling us how to extend to a given router, do not try to include the nickname if it is absent. (Resolves bug 467.)
  • Fix a user-triggerable segfault in expand_filename(). (There isn’t a way to trigger this remotely.)
  • When sending a status event to the controller telling it that an OR address is readable, set the port correctly. (Previously we were reporting the dir port.)
  • Fix a minor memory leak whenever a controller sends the PROTOCOLINFO command. Bugfix on 0.1.2.17.
  • When loading bandwidth history, do not believe any information in the future. Fixes bug 434.
  • When loading entry guard information, do not believe any information in the future.
  • When we have our clock set far in the future and generate an onion key, then re-set our clock to be correct, we should not stop the onion key from getting rotated.
  • On some platforms, accept() can return a broken address. Detect this more quietly, and deal accordingly. Fixes bug 483.
  • It’s not actually an error to find a non-pending entry in the DNS cache when canceling a pending resolve. Don’t log unless stuff is fishy. Resolves bug 463.

Java exposes a programmatic sockets interface, and a malicious applet can construct properly formed control port commands. If the control port is enabled with the NULL authentication and accessible to the web browser, the malicious applet can authenticate and send arbitrary commands.

To summarize, Tor users with the following conditions may be at risk:

• vulnerable version of Java enabled in web browser
• control port enabled with NULL authentication and accessible

Use of proxy switching browser add-ons (e.g., Torbutton, FoxyProxy)
may increase this risk if the Java Virtual Machine can perform
arbitrary DNS resolution through the native operating system resolver.

Possible workarounds:

• disable Tor control port
• if control port is required, use ‘HashedControlPassword’ option
• disable Java in the web browser and/or uninstall from OS
• If Java is required, consider a virtual machine solution such as JanusVM or firewalled environment that only allows DNS requests through web browser

The latest Java downloads are available at http://java.com/ or http://pseudo-flaw.net/tor/attacking-tor-control-port-with-java/.

# Subject: Tor security advisory: cross-protocol http form attack
# From: Roger Dingledine
# Date: Sat, 1 Sep 2007 14:31:54 -0400

On Thu, Aug 02, 2007 at 06:19:18PM -0400, Roger Dingledine wrote:
> Tor 0.1.2.16 fixes a critical security vulnerability that allows a
> remote attacker in certain situations to rewrite the user’s torrc
> configuration file. This can completely compromise anonymity of users
> in most configurations, including those running the Vidalia bundles,
> TorK, etc. Or worse.

Here are the further details that we promised:

In a nutshell, a malicious website or Tor exit node can give the Tor
user a page that includes a POST element directed to Tor’s control port
(localhost:9051). Tor binds its control port only to localhost to avoid
letting untrusted people send it commands, but the attacker skips past
this protection by making the browser do the connection. And the user
doesn’t even have to click on anything if she’s got javascript enabled.

This particular attack worked because Tor’s control protocol gave an
error message on unrecognized commands but didn’t hang up. So all the
http headers from the POST were unrecognized commands, and eventually
we got to the payload — which contains recognized commands — and it
went bad from there.

Jochen Topf wrote a fine paper describing this attack in 2001:
 http://www.remote.org/jochen/sec/hfpa/in…
Thanks to Kyle Williams and Martin Peck who independently rediscovered
the attack in the context of Tor.

The 0.1.2.16 and 0.2.0.4-alpha versions of Tor patched this particular
problem by hanging up if the first command wasn’t a successful
‘authenticate’ command. The recently released 0.1.2.17 and 0.2.0.6-alpha
versions of Tor now enable application-level authentication by default
in the Windows and OS X bundles, which should stop a broad class of
related attacks. Everyone should upgrade.

Yay full disclosure,
–Roger

The evidence is overwhelming and can not be denied: Using old versions of the free software network security package “Tor” is bad for you and gives you lousy security. It is admitted. You really should download a new version from https://tor.eff.org/ and upgrade and share this free software with all your friends.

You must buy it now

Official Tor story regarding security of current versions of Tor and good reasons to upgrade is this:

Tor 0.1.2.16 fixes a critical security vulnerability that allows a
remote attacker in certain situations to rewrite the user’s torrc
configuration file. This can completely compromise anonymity of users
in most configurations, including those running the Vidalia bundles,
TorK, etc. Or worse.

Users who do not have ControlPort enabled are secure; if you are not
sure, you should upgrade and you should probably overwrite your torrc
file with the default when you upgrade. More details will be posted over
the next few days.

https://tor.eff.org/download.html

We have Vidalia bundles for OS X Tiger on the website now. The recommended
workaround for Windows users is either to wait until we have a Vidalia
bundle ready, or do separate installs of the Win32 “expert” package from
 https://tor.eff.org/download-windows
and the Windows Vidalia-only package from
 http://vidalia-project.net/download.php

Changes in version 0.1.2.16 - 2007-08-01
o Major security fixes:
- Close immediately after missing authentication on control port;
do not allow multiple authentication attempts.

Immediate danger indicated

Unofficial developer on IRC story regarding the new version is this:

02:06 < xiando> I read the annoucement. It says immediate danger for all tor users. very bad. news at 11.
02:07 < nickm> yup. all users who don’t upgrade. quite bad. upgrade upgrade upgrade.

You upgrade your Tor immediately by downloading from https://tor.eff.org/download.html (or svn update)

Those who configure their Tor-clients as Bridges pass traffic between end-users and the Tor-network.

People who can’t get to the Tor-network because the main Tor-network is blocked can connect to a bridge (which hopefully isn’t blocked) and use that to get to a uncencored version of the Internet.

Tor is the adversary

Bridges makes it so much harder to block people from the Tor-network. If your corporation, school, government or anyone else says that

“Tor is bad and privacy is bad and anonymity is bad and we need to turn it all off and we do not want you or your familiy to have access to this technology”

and they block you from connecting to all known Tor-servers then all you have to do is to find someone who is running a bridge and use that to get to the Tor-network. The adversary can just download a complete list of all Tor-servers and block them. It is that much harder for the adversary to figure out that some computer on some ADSL somewhere is a bridge when there is no huge list which includes it.

Official “please test this” story

The official Roger Dingledine story regarding this is:

Hi folks,

The upcoming 0.2.0.3-alpha release has a couple new features from the
blocking-resistance design we’re working on. I’m going to write down more
details about how it works soon, but I wanted to give people a chance
to play with it (and report problems) now that it’ll be out in a release.

For background on the design, see
 https://tor.eff.org/svn/trunk/doc/design…

In short, the new Tor release lets you run a relay that isn’t in the
main directories (known as a bridge), and you can configure your client
by giving it a set of bridge addresses to use as your first hop into
the Tor network and as your source of directory information. There’s no
support in Vidalia for it yet, and the design is still in flux, but here
are some tips to get you started.

(Warning: these instructions are geared for people who are comfortable
editing their torrc and messing around with Tor. If it breaks and
you think it’s a bug, please let me know; if you just fail to get it
working, wait for a few more releases and it’ll be easier. Also, note
that these features alone do not provide very good blocking-resistance;
more features are on the way still.)

Thanks!
–Roger

********* Part one: using a bridge when you’re a client *****

Add these lines to your torrc file:

UseBridges 1
TunnelDirConns 1
Bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1

You can specify as many Bridge lines as you like, one for each bridge
you’d like to use. You can leave out the key if you don’t know it or
don’t care:

Bridge 128.31.0.34:9009

******** Part two: setting up your own bridge ***********

Configure yourself as if you were a normal Tor server. Make sure to
define a DirPort. Then add this line to your torrc file:

PublishServerDescriptor 0

This makes you into a Tor server that doesn’t advertise on the main
directory authorities. You should tell people your IP address and ORPort
(and optionally your identity fingerprint) and they can write their own
Bridge lines as in “Part one” above.

Optionally, you may want to set

RelayBandwidthRate 50 KB
RelayBandwidthBurst 50 KB

instead of the more traditional BandwidthRate and BandwidthBurst options,
so you can use your bridge as a Tor client too and not get hit by your
own rate limiting.

********Part three: a bridge directory authority *********

For the adventurous, I’m also running a temporary bridge directory
authority. If you want your bridge to publish to this bridge authority,
use these lines in your torrc:

PublishServerDescriptor bridge
dirserver moria1 v1 orport=9001 128.31.0.34:9031 FFCB 46DB 1339 DA84 674C 70D7 CB58 6434 C437 0441
dirserver moria2 v1 orport=9002 128.31.0.34:9032 719B E45D E224 B607 C537 07D0 E214 3E2D 423E 74CF
dirserver tor26 v1 orport=443 86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D
dirserver lefkada orport=443 140.247.60.64:80 38D4 F5FC F7B1 0232 28B8 95EA 56ED E7D5 CCDC AF32
dirserver dizum 194.109.206.212:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755
dirserver moria5 orport=9005 bridge no-v2 128.31.0.34:9035 F812 FCC1 E3EB E2E8 1C09 E516 E51A F9BF AFE3 3974

The first line specifies to publish to all authorities of type ‘bridge’,
and the last line specifies a new dirserver of type bridge. The others
are just repeating the current dirservers so we don’t lose them when we
define a new one. I promise I’ll have a better interface for this soon.

Then clients that use your bridge can add

UpdateBridgesFromAuthority 1

to their torrc, and now even if your IP:port change (for example you’re
on a dynamic IP address), they’ll still be able to find you again.