tor-dev

tor-dev@lists.torproject.org

3581 discussions

[PATCH] entrynodes.c: Improve readability (issue 9971)
by Martin Kepplinger 08 Jul '14

08 Jul '14

Maybe we can do away with issue 9971 and improve readability: https://trac.torproject.org/projects/tor/ticket/9971 As response to this mail, I'll append seperate patches for the 3 sub-issues mentioned. They apply (and are build-tested) seperately to the current tree, so a maintainer can quickly pick one of them up, if happy with it. There shouldn't be a conflict in *1* and *2* but I could append a patchset anyway. sub-issue *3* is *only* a call for advice and will be written on top of the other ones, after discussion. 1* rename entry_guard_t's made_contact to used_so_save_if_down I think that's readable. Is that about what arma had in mind? 2* rename for_discovery argument of add_an_entry_guard() to I like probationary more than provisional. Those 2 are suggested in issue 9971. I chose forced_probationary for now, because isn't it strictly a suboptimal situation in terms of desired 'grade of anonymity'. What do you think? 3* NEEDS REVIEW FIRST: regarding the int arguments of add_an_entry_guard(). I look at: node_t *chosen is a node to add. prepend is set if the guard should become first in the list? there are 2 users of add_an_entry_guard() that pass it a chosen node. One is a bridge (prepend) and the other one is a user-defined node (!prepend), so: Given the fact that the list is not supposed to be long and the two 'users' are somewhat similar, why not prepend the node if explicitly given?

1 4

[PATCH] remove test for remote SOCKS Port at config validation
by Martin Kepplinger 08 Jul '14

08 Jul '14

(why doesn't git send-email work for this list?) this is UNTESTED and for now, more of a question if this may suffice to close ticket 4019: -- Martin Kepplinger http://martinkepplinger.com

1 1

[ot] tor2web static maps
by grarpamp 07 Jul '14

07 Jul '14

I think I saw these posted here earlier from a tor2web person. The url's seem unreliable at times. Are there new, updated, or canonical links to this data? Or to a document outlining them? Thanks. https://antani.tor2web.org/antanistaticmap/stats/yesterday https://antani.onion.to/antanistaticmap/stats/yesterday

2 2

[PATCH] Add some words about meek in proposal 203
by Lunar 07 Jul '14

07 Jul '14

This is mostly David Fifield's words from an email exchange. --- I re-read proposal 203 the other day and wondered how it was related to the meek pluggable transport. As I might not be the only one, I thought it could be worthwhile to share David's answer. Feel free to improve! proposals/203-https-frontend.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/proposals/203-https-frontend.txt b/proposals/203-https-frontend.txt index 26101b3..df30cd5 100644 --- a/proposals/203-https-frontend.txt +++ b/proposals/203-https-frontend.txt @@ -245,3 +245,31 @@ Side note: What to put on the webserver? "Something to add to your HTTPS website" rather than as a standalone installation. +Related work: + + meek [1] is a pluggable transport that uses HTTP for carrying bytes + and TLS for obfuscation. Traffic is relayed through a third-party + server (Google App Engine). It uses a trick to talk to the third + party so that it looks like it is talking to an unblocked server. + + meek itself is not really about HTTP at all. It uses HTTP only + because it's convenient and the big Internet services we use as cover + also use HTTP. meek uses HTTP as a transport, and TLS for + obfuscation, but the key idea is really "domain fronting," where it + appears to the censor you are talking to one domain (www.google.com), + but behind the scenes you are talking to another + (meek-reflect.appspot.com). The meek-server program is an ordinary + HTTP (not necessarily even HTTPS!) server, whose communication is + easily fingerprintable; but that doesn't matter because the censor + never sees that part of the communication, only the communication + between the client and CDN. + + One way to think about the difference: if a censor (somehow) learns + the IP address of a bridge as described in this proposal, it's easy + and low-cost for the censor to block that bridge by IP address. meek + aims to make it much more expensive: even if you know a domain is + being used (in part) for circumvention, in order to block it have to + block something important like the Google frontend or CloudFlare + (high collateral damage). + +1. https://trac.torproject.org/projects/tor/wiki/doc/meek -- 1.7.10.4

3 3

Spinning off Directory Archive from Metrics Portal
by Karsten Loesing 07 Jul '14

07 Jul '14

Hello devs, I'm continuously tweaking the Metrics Portal [0] in the attempt to make it more useful. My latest idea is to finally spin off the Directory Archive part from it, which is the part that serves descriptor tarballs. I'd like to hear what people think about that. Let me give you some more context. The Metrics Portal serves three main purposes: 1. Graphs [1]: there are graphs on network size, network diversity, user number estimates, and performance measurements. This is probably what most visitors are interested in. In addition to graphs, there are also tables and .csv files for download. 2. Research [2]: we offer descriptor tarballs for download and explain the data formats. This is mostly interesting for researchers and developers. (This is the part that I'd like to spin off and move to a separate place.) 3. Status [3]: we provided (and still provide) services that are based on archived descriptors. This includes ExoneraTor and Consensus Health, both of which have moved to their own sites, and it includes Relay Search which is high on the list of endangered services. While we (did) provide these services on the Metrics Portal, they're almost gone. So, my plan is to move away the Research part, number 2 above, and re-organize the remaining Graphs part to address visitors who are not necessarily researchers or developers. The new Directory Archive website would contain the following content: - Start page: possibly re-using parts from the current start page [0]. - Data: How to obtain the data, possibly re-using parts from the current Data page [4], but without separate pages for file lists. - Formats: similar to the current Data Formats page [5]. - Tools: similar to the current Tools page [6]. What would be a good name for the new website holding the Tor Directory Archive? How about: - CollecTor, collector.torproject.org (not available yet) or - AggregaTor, aggregator.torproject.org (not available yet) On the software side, I'd like to remove all dynamic (Java) parts from the new website and have it served by Apache alone instead of Tomcat. The only parts that still need to be dynamically generated would be file lists, and I'd like to solve that by using Apache directory listings or some other Apache module. The re-organized Metrics Portal is going to have the following content: - Start page: possibly re-using parts from the current start page [0]. - Graphs: all four sub pages from the current Graphs page [1], so Network, Bubbles, Users, and Performance. - Aggregated data: the processed data behind graphs that is currently available on the Statistics page [7]. Speaking of, if anybody wants to help design the new website (or help re-design the existing Metrics Portal website once the cruft is gone), your help would be much appreciated. Bonus points if no JavaScript is required, at least for the Directory Archive website. Please contact me if you're interested. Any feedback welcome! Thanks! All the best, Karsten [0] https://metrics.torproject.org/ [1] https://metrics.torproject.org/graphs.html [2] https://metrics.torproject.org/research.html [3] https://metrics.torproject.org/status.html [4] https://metrics.torproject.org/data.html [5] https://metrics.torproject.org/formats.html [6] https://metrics.torproject.org/tools.html [7] https://metrics.torproject.org/stats.html

3 6

7 Dir Servers Dropping - Doctor Error?
by Tom Ritter 07 Jul '14

07 Jul '14

On 6 July 2014 18:59, doctor role account <doctor(a)cappadocicum.torproject.org> wrote: > ERROR: Unable to retrieve the consensus from maatuska (http://171.25.193.9:443/tor/status-vote/current/consensus): timed out > ERROR: Unable to retrieve the consensus from tor26 (http://86.59.21.38:80/tor/status-vote/current/consensus): timed out > ERROR: Unable to retrieve the consensus from urras (http://208.83.223.34:443/tor/status-vote/current/consensus): timed out > ERROR: Unable to retrieve the consensus from gabelmoo (http://212.112.245.170:80/tor/status-vote/current/consensus): timed out > ERROR: Unable to retrieve the consensus from moria1 (http://128.31.0.39:9131/tor/status-vote/current/consensus): timed out > ERROR: Unable to retrieve the consensus from dannenberg (http://193.23.244.244:80/tor/status-vote/current/consensus): timed out > ERROR: Unable to retrieve the consensus from Faravahar (http://154.35.32.5:80/tor/status-vote/current/consensus): timed out I've been keeping an eye on consensus health, it seems to be pretty reliable, but this is an obvious outlier. I assume it was a doctor error of some sort? -tom

2 1

Revised spec for on adding extra torrc fields
by Virgil Griffith 06 Jul '14

06 Jul '14

Damian and I worked through this off-list and this is the output of our consensus. URL: https://dl.dropboxusercontent.com/u/3308162/ExtraRelayDescriptorFields.v3.t… Any further revisions to be made before adding this to torspec? -V

1 0

GSoC Stegotorus Security Enhancement
by Noah Rahman 05 Jul '14

05 Jul '14

Greetings all, I've been refining the Elligator handshake to work on the circuit level for now as opposed to the connection level[1], merging in some SRI changes[2], especially those with respect to configuration files[3], and studying resources in order to prepare for a possible implementation of Elligator^2 [4][5](with parts in Lua [6]) as well as understanding the new SRI JumpBox alternative [7] to the transparent proxy that vmon developed. Happy fireworks (for you US-based readers!) [1] https://github.com/TheTorProject/stegotorus/tree/f--chop-handshaker [2] https://github.com/SRI-CSL/stegotorus [3] https://github.com/TheTorProject/stegotorus/tree/f--modus-operandi [4] http://www.hackersdelight.org/divcMore.pdf [5] http://www.hackersdelight.org/MontgomeryMultiplication.pdf [6] I also can probably implement concurrency in Lua faster than in C++ or Go, and Lua bignum libraries do exist. Also, why this numbering begins at 1 instead of zero ;p [7] Vinod Yegneswaran, private communcation.

1 0

GSOC Pluggable Transport Combiner Status Update 3
by quinn jarrell 05 Jul '14

05 Jul '14

Hi everyone, I've been working on: - Making tor connect to the pt combiner directly instead of connecting to the first pt as it did before. Now when tor sends a socks request to the combiner, the socks request is intercepted and a connection is made to the first pt instead of the requested bridge. The last pt has its destination set as the original requested bridge address so when the last pt is finally given the data to obfuscate, it will forward it to the actual bridge. - Added a configuration file reader to the pt combiner server - Turned the obfs3_flashproxy method into a configuration file and set it as the default configuration file if one is not specified. - Worked on rearranging the project structure into a python and go project [0] You can see my progress at [1] [0] https://trac.torproject.org/projects/tor/ticket/12215 [1] https://github.com/infinity0/obfs-flash

1 0

Re: [tor-dev] Response on adding extra torrc fields
by Damian Johnson 05 Jul '14

05 Jul '14

> Hi Damian! I'm trying to make this work under your suggestions, but I'm not > entirely clear how. Can you help me get this in shape to pass your muster? Hi Virgil, I'd be glad to! Adding tor-dev@ back in case others have thoughts on the details. I like your idea, what I was trying to hint by asking about the motivation was that the proposal should clearly explain why we're doing this (with example use cases). As for detail, I mean the proposal should have text we can copy and paste into the dir-spec. Maybe something like... ============================================================ The following would be added to section 2.1.2 of the dir-spec (Extra-info document format): "X-" CustomKey SP CustomValue NL CustomKeyChar = ALPHA / DIGIT / "_" / "-" CustomKey = 1*20 CustomKeyChar CustomValueChar = atext / SP CustomValue = 1*200 CustomValueChar Custom field that can appear multiple times, for example... X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar A CustomKey cannot appear more than once, and there cannot be more than ten of these entries. ============================================================ As a controller library author what I want from proposals is enough detail so I know *exactly* how to parse new additions. There's lot of potential edge cases. Can values be an empty string? How about keys? What should we do if a key appears multiple times? Is that valid? You mentioned a 5 KB limit, is that per option or for all custom fields? Rather than a size threshold, in the above I'm proposing a limit of ten entries each of which can be at most 220 characters. That would only be 2 KB so feel free to tweak these limitations. I'm not entirely sure 'atext' is what we want here. This would exclude tabs, but maybe that's not such a bad thing. You can look it up on... http://www.ietf.org/rfc/rfc2822.txt Cheers! -Damian

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev