root/tags/REL3_4_2/CHANGES

Revision 13232, 39.7 kB (checked in by kasimir, 2 years ago)

Data only dump from old repository - all commits by kasimir

  • Property svn:executable set to *
Line 
1
2Copyright (c) 2006-2007, Joseph B. Kowalski
3See LICENSE for licensing information
4
5
6TorNetworkStatus Changes
7
8
9--Version 1.0--
10
11Initial release.
12
13
14--Version 1.1--
15
16Addition of router detail page.
17
18Addition of real-time-calculated router uptime to router detail page.
19
20Addition of bandwidth graphs to router detail page. This functionality makes
21use of the free 'JPGraph' PHP libraries.
22
23Addition of country code data to main and router detail pages. This
24functionality makes use of the free 'GeoIP' PHP API and country database.
25
26Separation of database refresh operation from main page render operation. The
27database refresh operation has been moved out of the web root into it's own
28script, 'tns_update.php'. This greatly increases page render speed in
29situations where the local-cache is expired.
30
31Addition of 'tns_agent.php' script to handle background scheduled database
32refresh operations.
33
34Movement of the SQL database creation script out of the web root.
35
36Addition of ability to click on a column header on main page to sort. Multiple
37clicks alternate sort direction.
38
39Addition of code to handle situations where a user attempts to load a page
40while a background database refresh is in progress. In these situations, the
41user will be notified of the database refresh being in progress, and the page
42will automatically reload in 10 seconds, retaining any sort or search criteria
43that was initially passed by the user.
44
45Various performance improvements during main page render, some major. Code
46cleanups. Implementation of CSS / HTML restructuring to greatly reduce the
47size of page.
48
49
50--Version 1.2--
51
52Application-wide security fixes.
53
54Multiple XSS vulnerabilities fixed.
55
56Possible SQL injection vulnerability fixed.
57
58Code cleanups, further performance enhancements.
59                                               
60
61--Version 1.3--
62                       
63Major changes to the way the application gets it's network status information
64and router descriptors.
65
66Previously, for network status information, the application would cycle
67through the local Tor server's "cached-status" documents of Authority servers
68you explicitly allowed in the application config file, using a different one
69for each local-cache refresh. This had two problems. First, it meant that you
70would get a different number of routers listed, and oftentimes different
71properties listed for a specific router depending on which Authority server's
72cached-status doc had been used. Second, and this is the bigger of the two
73problems, is that this is not the way the Tor network works. The Tor network
74leaves it up to each client/server to calculate what it believes to be the
75correct view of the network based on the multiple sources of network status
76information it has available. This is important for security reasons, and
77plays a significant role in making it harder for someone to play some bad
78tricks on network users. So, now network status information is obtained by
79asking the local Tor server's control port to list all routers it has an
80opinion about. This ensures the data being presented has been through the
81proper "voting" process done by the Tor software, and is what the local Tor
82server believes to be correct.
83
84Previously, for individual router descriptors, the application would do one
85of two things. One, the default, was to directly ask whichever Authority
86server was used for the last local-cache refresh. This was bad, as it
87basically meant that for the duration of the current cache life, every
88visitor going to the "router_detail" page was causing a request for a
89descriptor to be sent to that Authority server. Not what we want for the
90Authority servers, I'm sure. Two, a user could specify that they always wanted
91to use a certain Tor server for descriptor requests. This fixed the issue with
92hammering the Authority servers, but only if people used the option. Now,
93router descriptors are also obtained through the local Tor server's control
94port. Also, router descriptors are no longer written to files on the hard
95drive. This was unnecessary and slow.
96
97These changes allowed a lot of clean-up to be done in the config file. There
98are a lot less variables in there now.
99
100 
101--Version 1.4--
102
103Addition of an option to export the IP Addresses of all current Tor routers to
104a CSV (Comma Separated Value) file. This may be of some use for people looking
105to get a quick, current list of Tor router IP's, whether to formulate block
106lists, or to assist with other Tor network status apps / pages.
107
108Addition of "Bandwidth" and "Uptime" columns to main page. The bandwidth
109reading is obtained from the "Bandwidth Observed" parameter of the router
110descriptor and is displayed in KB/s. The uptime reading is obtained from the
111"Uptime" parameter of the router descriptor and is displayed in days. Both of
112these columns are sortable.
113
114Back end changes to make the addition of the "Bandwidth" and "Uptime" columns
115to the main page, described above, possible. These changes consisted of making
116the scheduled background update process request and parse the descriptors of
117every router that the local Tor server has an opinion about, as identified by
118it's network status request response, so that the bandwidth and uptime
119information (and everything else in the descriptor) could be inserted into the
120database at this stage to be available for use on the main page. Previously,
121descriptors were only requested and parsed on an as-needed basis when a user
122loaded the "router_detail.php" page, and the data parsed from them was not
123stored. Now, it's all inserted into the database during the main update
124process which opens up the possibilities for all kinds on new stuff. The
125downside to doing it this way is that the main update process CAN take
126considerably longer (especially when the local Tor server is very busy), which
127led to the second major back end change: Using two router (local-cache) tables
128instead of one. Basically, only one table is marked as active at any given
129time, and all page loads use the active table. When the update process runs,
130it runs on the non-active table, and marks it as the active table upon
131successful completion. This prevents users from seeing the "Database refresh in
132progress" error message, as they will instead just be seeing the old data
133until the new data is ready. I was quite serious about not causing a
134performance hit to page load times due to the new functionality, and this was
135the solution implemented to avoid that.
136         
137
138--Version 1.5--
139
140Major performance enhancements to both the background update process and the
141main page load process.
142
143First, for the update process, we are now obtaining the full network status
144opinion document and the full recent descriptor document from the control port
145of the Tor server. Previously, we were obtaining the full network status
146opinion document, and then, as we parsed out this file, we requested server
147descriptors of the Tor server's control port individually. This tended to
148sometimes cause somewhat of a load on the Tor server and cause the descriptors
149to be fed back very slowly, sometimes taking up to a half hour for a full
150refresh. Now, since we grab both full documents all at once, it only takes the
151Tor server a few seconds to provide them. Second, we are now writing the
152parsed network status information and the parsed descriptor information into
153two separate database tables (NetworkStatus & Descriptor). This makes for
154cleaner design and tables with less columns. And, in keeping with the spirit
155of the updates made in Version 1.4, there is two of each of these tables
156(NetworkStatus & Descriptor) so that one set can be updated while the other
157set can continue to be used by folks loading the page and running queries,
158etc., until the new set is ready.
159
160Performance improvements to the load time of the main page were obtained by
161switching to the MySQL MyISAM storage engine, instead of the InnoDB engine we
162had been using previously. MyISAM is significantly faster than InnoDB, and,
163since we currently don't make use of transactions, there is no reason not to
164use it. Also, indexes were added to the NetworkStatus and Descriptor tables
165on the "Fingerprint" column, since this is what is used for the join of these
166two tables during page load. This further increased the query speed.
167
168Some other small performance improvements were implemented, especially on the
169"router_detail.php" page.
170
171The update process now has more robust error handling.
172
173Addition of "Count" column to main page.
174
175Addition of green check marks and red x's to indicate whether a flag is "Yes"
176or "No". Previously, it would just print "Yes" or "No".
177
178Modifications of font selections and background images to hopefully achieve
179two things: Fit more in a smaller space, and make the page easier to read.
180
181
182--Version 1.6--     
183
184The application now performs reverse-DNS lookups during the update process and
185stores this information in the database. This enables a user to choose whether
186they would like addresses displayed as IP or Hostname. Of course, whichever
187display they choose, it is sortable.
188
189Added Hostname information to the router detail page as well.
190
191Added "Last Update Elapsed Time" field to main page. Good way to see if your
192system is experiencing problems during the background updates.
193
194Added "Current Descriptor Signature" field to the main page for the Network
195Status Source router information section.
196
197Minor CSS changes to improve layout and formatting in certain situations. 
198
199
200--Version 1.7--
201
202Changes to the way variable handling is done. I moved all state maintaining
203variables into PHP session, such as all of the "Flags" variables and the
204Address Display Mode, SortRequest, and SortOrder variables. Also, wherever
205possible because of addition to session, variables were removed from the URL's
206in the anchor tags of the generated page. The only ones that were left in
207URL's were variables that need to be manipulated by clicking on a link, namely
208the SortRequest and SortOrder variables. This makes the URL's in the anchor
209tags of the generated page much shorter and cleaner, since a whole lot less is
210being passed around via GET. This in turn reduces the generated page size,
211sometimes considerably depending on the custom query options in effect.
212Another nice benefit to doing things this way is that if a user has custom
213options set, completely browses away from the site, and later comes back
214within their same browser session, all of their options will be configured as
215they were when they left.
216
217Also, variables that needed to remain in URL's have shorter names to further
218reduce the amount of data being passed around via GET, and hence the length
219of the URL's in the generated page.
220
221Further cleanups to HTML formatting and CSS on both the main page and the
222router detail page.
223
224Addition of timer to bottom of main page to indicate how long page generation
225took on the server.
226
227 
228--Version 1.8-- 
229
230Changes / cleanup to CSS. All CSS information is now defined in one external
231style sheet which resides in the "web/css" directory, and the different parts
232of the code that need the style sheet simply reference it rather than defining
233everything at the top of every HTML page output to the browser.
234
235Addition of row highlighting for Mozilla Firefox / Opera. This makes it easier
236to visually track which row you are currently moused over. This feature does
237not currently work in Internet Explorer since that would require JavaScript,
238and I'm trying to keep this app JavaScript free for those who browse with it
239disabled.
240
241When sorting by IP Addresses, they are now sorted naturally, rather than as
242strings. This should make the IP Address search quite a bit more meaningful.
243This change also applies to the CSV (Comma Separated Value) file list of IP's.
244
245
246--Version 1.9-- 
247
248Added proper escaping of problem characters to all strings that get populated
249from data parsed from router descriptors and network status documents before
250database inserts are performed. This should prevent the update process from
251dying when these characters are encountered, which would sometimes happen.
252
253Now using the standard "gethostbyaddr" PHP function to do hostname lookups.
254Previously, I was doing some custom parsing on the output of the Unix "host"
255command, as I thought it would be faster, but, after comparing the two, I see
256no speed degradation with using "gethostbyaddr". The advantage of using
257"gethostbyaddr" over "host" is that we are not using a platform-specific
258command which limits where the application can run without modification.
259
260Addition of Advanced Search functionality, which lets you perform free-text
261searches on the following data: Fingerprint, Router Name, Country Code,
262Bandwidth, Uptime, Last Descriptor Published, IP Address, Hostname, Onion
263Router Port, Directory Server Port, Platform, & Contact. You can apply the
264following modifiers when searching the above data: Equals, Contains, Is Less
265Than, or Is Greater Than. The Advanced Search works in conjunction with the
266other Custom Query options (Sort By, Sort Order, Address Display Mode, and
267Require Flags), allowing a great deal of flexibility to customize the result
268set as desired.
269
270Addition of indexes where necessary in the database to better facilitate
271speedy free-text searches.
272
273Addition of "Hostname" field to "Tor Server Providing Network Status Opinion"
274section.
275
276Addition of feature to tell user if they are accessing the page through the
277Tor network or not, color coded.
278
279Additional escaping of potentially troublesome HTML characters before
280displaying on page for "Contact" field on main page and router detail page.
281
282 
283--Version 2.0--
284
285Small performance enhancement to background update process. When clearing old
286data from the descriptor and network status tables, we now use the "truncate
287table" command rather than the "delete from" command. This is faster because
288"truncate table" deletes all records from the table at once, while "delete
289from" deletes records one row at a time.
290
291Enhancement of "Require Flags" custom query option so that the user now has
292three options available for each flag: "Off", "Yes", and "No". "Off" means
293the status of the flag is not a factor in the search. "Yes" means a router
294must have flag set in order to show up in result set. "No" means that a router
295must not have flag set in order to show up in result set. Previously, a user
296only had the equivalent of the "Off" and "Yes" options. Also, when a flag is
297set to "Off", it's column header in the result list will have a blue
298background, "Yes" will have a green background, and "No" will have a red
299background. This further increases the level of flexibility with searches.
300
301Addition of "Country Code" field to "Tor Server Providing Network Status
302Opinion" section. 
303
304Addition of background color to drop-down lists and edit box in advanced
305search section.
306
307Minor changes to text in custom query section to facilitate clarity.
308
309
310--Version 2.1--
311
312Addition of "Aggregate Network Statistic Graphs / Details" page. This page
313contains four graphs of network-wide aggregate information: Number of Routers
314by Country Code, Number of Routers by Observed Bandwidth, Number of Routers
315by Time Running, and an aggregate summary of various criteria including router
316flags.
317
318Addition of "EventDNS" and "Hibernating" statistics to newly renamed
319"Aggregate Network Statistics Summary" section on main page.
320
321Improvement to the way that the "Aggregate Network Statistics Summary" section
322of the main page gets it's data. Previously, each piece of information used
323was collected by a separate SQL query. Now, all of this has been joined into
324one large query to cut out the overhead of multiple SQL calls.
325
326Change to CSS which affects the highlight color of links which are on a white
327background, for increased readability.
328
329
330--Version 2.2--
331
332Fixed a bug in the code that detects whether or not the user is connecting to
333the server through the Tor network. Previously, it would tell a user they were
334connecting through the Tor network if their IP address matched the IP address
335of any Tor server. Now, it will only tell the user they are connecting through
336the Tor network if their IP address matches the IP address of a Tor server AND
337that Tor server is an exit node.
338
339Addition of exit node only CSV file download, for those who don't want the
340IP's of all Tor servers.
341
342Addition of graph of exit routers by country code to Network Detail page. This
343is useful for letting us see where we are most likely to exit the Tor network.
344
345Addition of "BadDirectory" flag information everywhere we make use of flags.
346The "BadDirectory" flag was added in Tor version 0.1.2.5-alpha.
347
348Minor cleanups to documentation to enhance readability.
349
350Fixed minor bug in SQL database create script.
351
352
353--Version 2.3--
354
355Redesign of the "Custom / Advanced Query Options" box on the main page. I am
356now using drop-down lists for the sort request, sort order, and address mode
357parameters instead of radio buttons, which takes up a lot less screen real-
358estate and also makes adding new options for these parameters in the future
359more practical.
360
361Slight changes to the "Application Server Details" (Previously "Application
362Server Information") box on the main page to enhance readability.
363
364Addition of the "Number of Descriptors In Cache" field to the "Application
365Server Details" box.
366
367Movement of the "Application Server Details" box to the bottom of the page.
368This has the dual purpose of improving page readability as well as making the
369"Approximate Page Generation Time" figure more accurate, since it is now
370calculated closer to the bottom of the page. Previously, the PHP code which
371generates the "Custom / Advanced Query Options" box still ran after this time
372was calculated.
373
374Update of source URL at bottom of page to new domain.
375
376
377--Version 2.4--
378Modified "Aggregate Network Statistic Summary" box to also show "percent of
379total network" values for each statistic listed. This allows you to easily see
380what percent of Tor routers are exit nodes, what percent are mirroring the
381directory, what percent of the total network your current result set makes up,
382etc.
383
384Modified "Network Status Opinion Source" box to allow clicking on the nickname
385of the router to jump directly to its router detail page. This makes it easy
386for a user to get detailed information about the source of the network data
387that they are seeing.
388
389Modified code that detects whether a user is accessing the site through the
390Tor network or not. Now, if the user is accessing through the Tor network, the
391name of their exit node is displayed in addition to the IP address. Also, the
392user can click on the name of the exit node to jump directly to its router
393detail page. This makes it easy for a user to get detailed information about
394the exit node they are currently coming through.
395
396Modified page footer to also include a link to the change history and license
397of the application.
398
399Removed the "$MinRouterThreshold" variable from the config file, and all code
400that made use of the variable. This really became obsolete when version 1.4 of
401the application was released and we started using two sets of tables in the
402database for storing router information instead of one. Since that time, a
403user will always have their page generated from the active set of router
404tables in the database, while the next refresh operation is being performed on
405the inactive set. This makes this variable, which was used to see if a
406database refresh was in progress and display an error to the user back when we
407used a single set of tables, obsolete.
408
409Fixed a bug in the generation of the Comma Separated Value (CSV) list of exit
410nodes. A comma was incorrectly being added after the last entry in the file,
411which might have caused problems for parsers.
412
413Added "Number of Routers by Platform" graph to network detail page. This lets
414us easily see how popular different operating systems are for running Tor
415routers.
416
417Modified "Number of Routers by Time Running (Weeks)" graph on network detail
418page to be full page width. This makes this graph easier to read since it
419usually has a lot of items along the x axis.
420
421
422--Version 2.5--
423Fixed lots of minor HTML and CSS errors. All pages now validate as "CSS
424version 2.1" and "HTML 4.01 Transitional".
425
426Modified the handling of all SQL queries which return a result set so that the
427result set populates into an associative array rather than a numerically
428indexed array. This allows items in the result set to be referred to by column
429name rather than a numerical array index. This is a significant step towards
430being able to offer the user the ability to do things such as select which
431columns they want displayed on the page, etc, as it is much more flexible
432than using numerical indexes because your entire result set handling code is
433no longer affected by re-arranging the order of items in your query, or adding
434and removing items on the fly. It is also generally considered a database
435programming best practice, as a lot of confusion and potential for bugs is
436eliminated by being able to use easily recognizable column names as opposed to
437numerical indexes.
438
439Modified the "Address Display Mode" in the "Custom / Advanced Query Options"
440so that users now have a third choice -- "Hostname + IP Address". Previously,
441the user could only choose one at a time, and had no way to view both
442simultaneously. "IP Address Only" mode is still the default as the "Hostname +
443IP Address" mode can result in a much larger amount of data being returned,
444but now the option is there for those who want it.
445
446
447--Version 2.6--
448Added the ability for users to select which columns they want displayed in the
449main router table. This should be good for ensuring that the page does not
450grow larger and larger as new informational items about Tor routers become
451available, since we can just maintain reasonable default settings and leave
452the obscure stuff off unless a user intentionally turns it on. Also, the SQL
453query for obtaining the main router list has been made dynamic so that it will
454only request columns from the database if the user will actually be displaying
455them.
456
457Added "Fingerprint" as a column display option.
458
459Removed "Address Mode" from "Custom / Advanced Query Options" since it is made
460obsolete by the users ability to select which columns they want displayed,
461which offers more granularity.
462
463Efficiency improvement in the way that it is determined if a given flag
464column for a given router should display the red "x" or green check mark.
465Previously, there was an "If" statement that set the appropriate CSS class for
466the table data cell based on whether a flag variable for that router was '0'
467or '1'. Now, there is a CSS class that ends in '0' and '1', and the variable
468value is just dumped directly into the class statement in the appropriate
469place. This saves up to '$NumberOfDifferentFlags X $NumberOfRoutersInResultSet'
470'If' statements from being executed on each page load, normally many thousand.
471
472Fixed a bug in the generation of CSV files that was causing a comma to be
473added after the last column in a row. According to RFC 4180, this is incorrect.
474Also, added a newline character (\n) to the end of files.
475
476Added "Comma Separated Value (CSV) List of Current Result Set" option. This
477lets a user get a comma separated value (CSV) file of their current search
478result set, exactly as displayed on screen (Including sort preferences, column
479display preferences, and any other custom query parameters that may be
480applied). The first record (row) in the generated CSV file will contain the
481column names for reference. This should be very useful for users wishing to
482export the data from a custom query into an external data source.
483
484
485--Version 2.7--
486Moved the column display options to their own page, rather than having them on
487the main page in the "Custom / Advanced Query Options" box. You can get to the
488column display options by following the "Custom / Advanced Display Options"
489link from the top of the page and then clicking on the "Column Display
490Preferences" link. This should provide a much more comfortable interface for
491customizing column display options.
492
493Added the ability for users to re-configure the order that columns display in.
494Previously, users could only add and remove columns. This should allow much
495more flexibility to users wishing to customize the look of the page.
496
497Updated "Comma Separated Value (CSV) List of Current Result Set" functionality
498to support the newly added ability of users to re-configure column display
499order. This way, the CSV file of the current result set benefits from the same
500level of flexibility as the main page display.
501
502
503--Version 2.8--
504Added the ability for users to display four additional columns on the main
505page: "Platform", "Contact", "EventDNS", & "Hibernating". Users can sort by
506the new columns and, in the case of the "EventDNS" and "Hibernating" items,
507filter query results based on whether they are true or false, as they are
508treated as "Flags" by the application. All four of the newly added columns are
509set to "Off" by default.
510
511Updated the "Comma Separated Value (CSV) List of Current Result Set" script to
512support the addition of the new columns.
513
514Bug fix to the "Comma Separated Value (CSV) List of Current Result Set" script:
515Commas (,) and double-quotes (") are now replaced with a dash (-) and a single-
516quote ('), respectively, when they occur in a field to be written to the CSV
517file, as these characters would cause problems for automatic parsers.
518
519Modified the "Router Detail" page to display information on the "EventDNS" and
520"Hibernating" items alongside the other flags, since it has now been
521determined that the application will be treating these items like any other
522flag. Previously, these two items were displayed in the "General Information"
523section of the page, not the "Router Flags" section.
524
525Modified the order in which some items display in the "Aggregate Network
526Statistic Summary" section of the main page and the "Aggregate Summary --
527Number of Routers Matching Specified Criteria" graph on the "Network Detail"
528page to enhance consistency throughout the application.
529
530Minor source code cleanups to enhance consistency between scripts.
531
532
533--Version 2.9--
534Various application-wide code cleanups to fix all known situations that would
535generate PHP warnings.
536
537Fixed a rare division by zero bug that could occur during the generation of
538the bandwidth history graphs on the router detail page.
539
540Updates to the way "Uptime" information is presented. Previously, the "Router
541Detail" page would calculate the real-time uptime of the router (By looking
542at the difference between the current time and when the router descriptor was
543last published, and adding this value to the published "Uptime" value in the
544descriptor, compensating for time zone differences), but the other places that
545made use of the "Uptime" value did not, such as the main page, the "Network
546Detail" page, and the "Comma Separated Value (CSV) List of Current Result Set"
547functionality. These places would simply use the static "Uptime" value from
548the latest descriptor, and would not perform any real-time calculations on it.
549Now, all places that make use of the "Uptime" value perform the real-time
550calculations on it. This eliminates discrepancies between what the "Router
551Detail" page shows and what is shown everywhere else. Additionally, code to
552gracefully deal with situations where a certain descriptors publish time is
553obviously wrong, such as when it's in the future, was added to all places
554doing the "Uptime" calculations.
555
556Modified all places that display a "DirPort" value to say "None" rather than
557"0" for routers that do not mirror the directory. This is less confusing.
558
559Modified all places that display a "CountryCode" value to say "N/A" rather than
560nothing for routers where country code information could not be retrieved.
561Again, less confusing.
562
563Made the "Tor Network Status" text at the top and bottom of each page a link
564to get back to the main page. This should be more user-friendly than having to
565hit "back" to get to the main page when on the "Network Detail" and "Router
566Detail" pages. The links also exist on the main page itself, which will just
567refresh the page with the user's current settings.
568
569Added two new array variables to the config file to allow the default column
570display options to be set on a global scale. These options are what will be
571used when the user has not yet performed any customization on their display
572preferences. Both the active/inactive columns and their display order can be
573specified.
574
575Changed default column display preferences -- Added "Hostname" and removed
576"Bad Dir" and "Bad Exit".
577
578Removed support for the "EventDNS" descriptor flag entirely. The logic for this
579functionality was faulty, and since all new Tor versions have EventDNS enabled
580by default, and the Tor developers plan to remove the old DNS logic entirely
581at some time in the future (According to the "dir-spec" document), I decided
582to just go ahead and remove this now since it is becoming irrelevant.
583
584Removed "IRIX" as a listed operating system on the "Platform Graph", as it
585seems there have been no Tor servers running on this OS for some time now.
586
587Other minor fixes/enhancements.
588
589
590--Version 3.0--
591Complete redesign of the way that the application determines if you are
592accessing the site through the Tor network or not, or if the provided IP
593belongs to a Tor server capable of exiting to the specified IP and port (See
594section on "Tor Exit Query" page, below). Previously, we would simply check to
595see if the IP address that the user was coming from was a Tor server with the
596'Exit' flag set to true, and tell them they were coming through the Tor
597network if so. Now, we check if the user is coming from the IP address of a
598Tor server, regardless of it's 'Exit' flag status. If so, we pull the Exit
599Policy for the matching Tor server(s), look at what IP and Port the client is
600accessing us on, and parse the exit policy to determine if the Tor server(s)
601would allow or deny such an access. We then give the user information on each
602Tor server that matches their exit IP, letting them know if it would allow
603access to us or not considering it's exit policy. Finally, we also tell the
604user if it appears that they are coming to the site via a Tor Hidden Service
605or from the local machine directly. This is determined by checking if the user
606is coming to the site from the '127.0.0.1' IP address. Note that the
607application now handles situations where there are multiple Tor servers with
608IP's that match where the user is coming from (Or the IP provided, in the case
609of the "Tor Exit Query" page, see below). In these cases, it will cycle through
610each applicable Tor server to provide Exit Policy match information.
611
612Addition of "Tor Exit Status" page. This page provides the same information
613about whether a user is accessing the site through the Tor network as is
614available on the main page, but without all the other information. This may be
615easier for someone who just wants a simple answer for "Is my Tor installation
616working?", and should serve as a good entry point for such situations. This
617page also contains a link to the main Tor documentation page.
618
619Addition of "Tor Exit Query" page. This page allows a user to enter in an IP
620to check if it matches that of one or more Tor servers, and, if it does,
621checks to see if those Tor servers are capable of exiting to the destination
622IP address and port that the user provides.
623
624Addition of a DNSBL server. This allows a standard, non-web interface method
625for clients to query whether or not an IP address belongs to an active Tor
626server, and whether or not an IP address belongs to an active Tor server that
627would allow exiting to a specified destination IP address and port. Please
628see the "README_DNSBL" file in the source distribution for full setup and
629usage information.
630
631
632--Version 3.1--
633Nearly a complete redesign of the DNSBL server added in the last version to
634improve performance. Major changes:
635
6361) Previously, there was a Perl script which performed the actual listening
637for DNS requests, and when one was received, the script passed on the details
638of the request to a PHP script, which is where the main processing happened.
639The PHP script would then return a value to the Perl script indicating success
640or failure of the request. This had the horrible performance penalty of
641needing to invoke PHP every time a new request was received. Now, the entire
642process is handled within the same Perl script -- All of the PHP code to
643process the DNSBL request has been ported over to Perl -- So there is no
644calling an external executable again and again. Additionally, Perl runs faster
645than PHP with all other factors being equal.
646
6472) With the old PHP script, since it had to be invoked anew from within the
648Perl script with each request, this also meant that a new database connection
649had to be setup with each request. This also caused a performance penalty.
650Now, since everything is handled from within a single script, a single
651database connection can be maintained the entire time the script is running.
652
6533) Previously, when the DNSBL script did it's database queries to pull the
654IP addresses and exit policies of Tor routers, it did it the same way that the
655main application does, which means joining two large tables together on the
656router fingerprint key. While this works fine for the main application and
657it's very large queries, it did not suit the performance needs of a DNS
658server. Now, I have added two new in-memory database tables specifically for
659the DNSBL functionality. These two tables are populated during the update
660cycle, and contain only the necessary information (prejoined) required by the
661DNSBL server. The fact that they are in memory and are a lot smaller than the
662other tables should help the DNSBL server to return queries much quicker.
663These two tables act just like the set of NetworkStatus and Descriptor tables
664in that only one is ever active at a given time. The update cycle will always
665be updating the non-active table in the background while requests can continue
666being served by the active table. When the update is done successfully, a flag
667in the Status table is toggled to tell the application to begin using the
668other table as the active one, and the process repeats -- No downtime for
669updates.
670
671Fixed a bug that would cause the DNSBL server to only return "NXDOMAIN"
672responses if the database connection was lost until the script was restarted,
673even if the database connection came back up later. Now, the server will
674return "SERVFAIL" responses while the database server is down, but it will
675resume correct operation once the database server comes back up.
676
677Various other minor bug fixes, mainly relating to the "Tor Exit Status" and
678"Tor Exit Query" functionality that was added in the last release.
679
680
681--Version 3.2--
682Removed the first type of query that the DNSBL server could perform, which
683was to simply lookup if a provided IP address was an active Tor server or not.
684This was causing confusion amongst some users, and causing people to focus on
685whether or not an IP is a Tor server at all, which is exactly what we are
686trying to get away from by providing an answer to the more granular question
687"Is this IP address a Tor server that is capable of exiting to my destination
688IP and port?", which is precisely what the second (and now only) query type
689does. This had the added benefit or making the server a little faster, since
690a bit of logic was removed. Please see the "README_DNSBL" file in the source
691distribution for full setup and usage information.
692
693
694--Version 3.3--
695Complete rewrite of the DNSBL server in Java. This provided a performance
696increase on the order of approximately 5x over the old Perl version of the
697server. On a Pentium 2.4 GHz machine with 2 GBs of RAM, I was able to
698consistently obtain load test results of 200 queries/sec or more. These tests
699were conducted across the internet, and not on the local machine.
700
701Addition of the "dnsbl_server.php" page. This page provides usage instructions
702for the DNSBL server, and informs users of it's domain name. Note that the
703link to "dnsbl_server.php" from the main page will only display if you
704set the "$DNSBL_Domain" variable in the "config.php" file, so you can leave
705this variable set to 'null' if you are not running a DNSBL server, or do not
706wish to advertise it on the web site.
707
708Addition of the "$Hidden_Service_URL" variable to the "config.php" file. If
709you are also making the TorNetworkStatus site available through a Tor Hidden
710Service, you can enter the URL here, and a link will be added to the main page.
711If you are not making the site available as a Hidden Service, or do not wish
712to advertise it on the web site, you can leave this variable set to 'null'.
713
714Removal of the "tor_exit_status" page. This functionality is already provided
715by the main page (Tells a user if they are accessing the site through the Tor
716network or not), and the user already has two options to do custom exit
717queries if desired: The "tor_exit_query" page, and the DNSBL server. Both are
718linked to from the main page.
719
720Modifications to the "tns_update.php" file and the database create script to
721accommodate the re-write of the DNSBL server.
722
723
724--Version 3.4--
725Rename of the DNSBL server to DNSEL (DNS Exit List) server. This was by
726recommendation of Roger Dingledine of the Tor project. All filenames, variable
727names, etc, have been adjusted to reflect the rename.
728
729Added basic hit counting functionality to the DNSEL server. Now, every five
730minutes, the DNSEL server will write a record to the "DNSEL_LOG" table with a
731timestamp, a TotalResponses counter, and counters of how many "NOERROR",
732"SERVFAIL", "NXDOMAIN", and "NOTIMP" responses it has sent out since it was
733started. This procedure runs in it's own thread, and so should not have any
734measurable effect on performance.
735
736Improved the code that detects whether a user is accessing the site via a Tor
737hidden service. Previously, I checked to see if the user was coming from
738127.0.0.1. Now, I check to see if the "HOST" header provided by the client
739upon access exists in the "$Hidden_Service_URL" from the config file. If so,
740we tell them they are accessing the site as a hidden service. If not, we
741proceed on to the normal checks to see if they are accessing through the Tor
742network.
743
744Modified the DNSEL server to return SERVFAIL instead of NXDOMAIN for requests
745which are outside of the zone the DNSEL server is authoritative for.
746
747Modified the DNSEL server to return NXDOMAIN instead of NOTIMP for requests
748other than type 'A' and 'ANY' when the request is in the authoritative zone.
749
750Modified the documentation / default variables for the DNSEL server to use the
751"ip-port.torhosts.example.com" domain, rather than "tor.dnsel.example.com".
752This encourages users to setup servers that are consistent with the
753"torel-design.txt" document maintained by the Tor project.
754
755===============================================================================
756--Version 3.4.1--                             (changes made by Kasimir Gabert)
757
758* Fixed bottom headers for new domain
759* Updated IP detection so it works through Squid
760* Added known mirrors bar
761
762TODO:
763* Move the two changes into configuration items
764* Centralize the known mirrors and make it dynamic
765===============================================================================
766--Version 3.4.2--
767
768* (ticket 12) Fixed error with server IP detection for non-Squid servers
769* (ticket 12) Added config option for Squid server
770===============================================================================
771
772
773
774
775NOTE: This product includes GeoLite data created by MaxMind, available from
776http://www.maxmind.com/.
Note: See TracBrowser for help on using the browser.