tor-dev September 2013

tor-dev@lists.torproject.org

59 participants
70 discussions

entry guards and linkability
by Leif Ryge 19 Sep '13

19 Sep '13

Is the following statement correct? When a user connects to Tor from multiple locations where the network is monitored by the same adversary, their persistent use of the same set of entry guards uniquely identifies them and reveals their location to the adversary. Assuming this is an accurate assessment, wouldn't it make sense to maintain separate sets of entry guards for each network that the user connects from? ~leif

2 3

What to read to analyze Tor's use of NTor?
by Roger Dingledine 19 Sep '13

19 Sep '13

Hi Nick, Ian, I've been pointing people to "Section 6 of http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.228.6223" when they ask what NTor is. But then I realized that that's not the best (single) place to send cryptographers when I ask them to analyze whether we've designed or built it right. Then I found https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/216-ntor-han… which looks great but then I also found https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l852 which looks crisper. So the questions: A) Which combination and order of these three resources should I point people at? That is, does the tor-spec stanza replace proposal 216 completely, or is there still some use to looking at the proposal too, or is the proposal wrong now because you fixed stuff since then but didn't change the proposal, etc? Did I miss any good resources? B) What are the sketchiest parts -- the parts of the design or the implementation that you most want review on, or that you think would be most fruitful for finding issues? C) What else should I be asking you, in terms of how to get this thing reviewed the mostest and the bestest? We rolled out NTor quicker than we rolled out TAP, relatively speaking, and now it would count as breaking a widely deployed system so I bet we can get some more people evaluating it. Thanks! --Roger

2 1

Using TorPS to estimate chances of all-TAP paths
by Roger Dingledine 19 Sep '13

19 Sep '13

Hi Aaron, Sathya, I have another use for your fine path simulator. :) See https://trac.torproject.org/projects/tor/ticket/9777 The first question is: for a recent consensus, what's the chance that your middle hop and your exit hop will both be running 0.2.4.7-alpha or earlier? The extra credit for question one is to generate the answers to question one for each of the past n consensuses (where n is, say, the past month) so somebody can graph them. The second question is: if we change path selection to try again if we choose such a path, what does that do to our anonymity, for various definitions of anonymity like the ones in the upcoming CCS paper? The extra credit for question two, if you haven't guessed it already, is to get some data points for question two from the past as well. I'm guessing getting 24*30 of them will be no fun, so whatever isn't no fun is fine. What can I do to help make it happen? If the answers are "actually not all that high" and "oh hey those curves aren't all that different" respectively, I want to put #9777 into 0.2.4 and enable it. If those aren't the answers, we'll need to sort out a better plan. Thanks! --Roger

1 0

OnionMail First Test
by Liste 19 Sep '13

19 Sep '13

Work complete for the version 0.0.0Beta http://anopticon.ws/13c03c09/OnionMail-0.0.0.B.zip to create user: telnet 127.0.0.1 9100 C = client S = Server S: +OK ControlPort 1.0 sfl‚4£$£"f C: server alice hackme <- default password S: +OK KESIA [example] `example` C: addusr test <-- local part S: +OK New user created S: Mail=test(a)your.onion S: User=test S: SMTPPasswd=lunc6){><uFXSpaoWnJHl1px S: POP3Passwd=kfzb};VW,NKwLz"JM2Hmrwot S: Server=your.onion S: MsgSize=2000000 S: MaxMsg=128 S: MsgOld=40 S: Inet= S: QFDN=your.onion S: . C: quit S: +OK Closing smtp server (tls if available) 127.0.0.1 25 user test etc...etc... pop3 port 110 (tls if available) 127.0.0.1

5 6

BSD 2/3-Clause License (was: Torperf)
by Karsten Loesing 18 Sep '13

18 Sep '13

On 9/16/13 2:51 PM, Sathyanarayanan Gunasekaran wrote: > I'm currently using BSD 3-Clause License (used by Tor) for torperf2. > Kevin ported ooni's setup script and made it work with torperf2, but > ooni uses a BSD 2-Clause License (both are copyrighted to The Tor > Project). Kevin and I think they are compatible, but I wanted to check > in with you before I merged the changes. Thoughts? I have, honestly, no idea. Cc'ing tor-dev@ in the hope that someone else can answer this question. All the best, Karsten

3 2

Liberte-Linux cable-communication
by josef.winger＠email.de 17 Sep '13

17 Sep '13

Was there a discussion about the 'cables-communication' approach from Liberte-Linux in the mailing list? What's the general oppinion here? Is it trustable/secure/relyable? best /jo

1 0

Message to obfsproxy maintainers: New obfsproxy/pyptlib releases
by George Kadianakis 16 Sep '13

16 Sep '13

Hey people, some days ago I pushed new releases for obfsproxy and pyptlib. Latest releases are obfsproxy-0.2.3 and pyptlib-0.0.4: https://gitweb.torproject.org/pluggable-transports/pyptlib.git https://gitweb.torproject.org/pluggable-transports/obfsproxy.git Please upgrade the packages if you are interested :) The new releases add some nice features and bugfixes (see ChangeLog files). Also, obfsproxy-0.2.3 depends on pyptlib-0.0.4 so it would be great if you could upgrade both packages. (There is probably going to be another release in the next two weeks. I will keep you posted when it happens.) Thanks! PS: I have CCed the obfsproxy maintainers for Debian, FreeBSD, Arch and Gentoo. Sorry if I forgot someone else.

1 0

Status report - Stream-RTT
by ra 14 Sep '13

14 Sep '13

tl;dr When building a circuit, measuring the RTT a single time could provide better latency and anonymity while not affecting throughput. Multiple measurements could be used for running real-time applications like VoIP or optimizing throughput. Despite the fact that the Tor network is currently in an unusual state so to say, I have been spending the last weeks looking into stream-RTT data of circuits. I gathered the data shortly before and at the beginning of the huge botnet usage. This is what I have found out: As assumed stream-RTT measurements of a single circuit are not at a fixed value but distributed since they are subject to multiple influences. After comparing stream-RTT distributions of multiple circuits, I found lots of different shapes and I realized that no single distribution fits them all. The Time-To-First-Byte (TTFB) for fetching a small website over HTTP is used to approximate the latency of a certain circuit. I used different methods to check the correlation between the RTT of a circuit and its TTFB - all indicating a very high correlation. Hence, stream-RTTs of a circuit make a good estimator for its TTFB and therefor its latency. In terms of latency, using a single stream-RTT measurement ("First-RTT") performs better than the currently used method CBT. So far I haven't done any testing/calculations on the other metrics: bandwidth and anonymity. I would assume the former to be unaffected by First-RTT. Latter could probably be slightly increased, if the percentage of discarded circuits would be reduced from 20% with CBT to 10% or 15% with First-RTT - while still achieving a minor improvement in latency. Nevertheless I would not recommend using First-RTT as method for providing low latency circuits to applications, because it only gives a small hint about the quality of a circuit and cannot make sure that some latency properties hold for a certain circuit. Nevertheless First-RTT works pretty well comparing to the minimum effort it takes. Additionally I played around a lot with methods to provide a better estimator for latency properties of a certain circuit. But they all need far more than a single measurement and are therefor out of scope for the common case. Besides they cannot protect against suddenly changing circuit conditions. But they could be used to fulfill a application specific maximum RTT for real-time applications like VoIP. With the use of similar techniques it should be possible to detect circuits that include a node that's within its bandwidth limit. This could be used for providing high bandwidth circuits for applications like BitTorrent. Best, Robert

1 0

Re: [tor-dev] Help with rebasing arma's n23-5 tor branch to current master
by Charlie Belmer 14 Sep '13

14 Sep '13

Hey Karsten & Dev team, I didn't mean to take this off channel, so my apologies for that. I ran a few more tests this week (and my apologies on the slowness of some of this work - life has been hectic this past month), but I am not finding much of use. I could not find any errors which are not also present in when N23 is disabled. If you want to browse the logs for yourself, I uploaded a partial log from a run to http://www.charliebelmer.com/scallion.n23.log(730MB). The most telling entries I found so far are below, but I see the same errors whether UseN23 is set to 1 or not, so it is likely not the root cause. I'll keep digging. Error 1 (Seems to occur when opening channel): 0:0:49:406270 [thread-2] 0:9:41:348157618 [scallion-info] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] bw_weights_error_t networkstatus_check_weights(int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int)(): Bw weight mismatch 1. G=214 M=12174 E=165 D=27654 T=40207 Wmd=4769 Wme=-724848 Wmg=0 Wed=461 Wee=734848 Wgd=4769 Wgg=10000 Wme=-724848 Wmg=0 0:0:49:407692 [thread-2] 0:9:41:348157618 [scallion-info] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] bw_weights_error_t networkstatus_check_weights(int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int64_t, int)(): Bw weight mismatch 1. G=214 M=12174 E=165 D=27654 T=40207 Wmd=4769 Wme=-724848 Wmg=0 Wed=461 Wee=734848 Wgd=4769 Wgg=10000 Wme=-724848 Wmg=0 Error 2: 0:0:54:227263 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] void conn_read_callback(int, short, void *)(): socket 1000264 wants to read. 0:0:54:227281 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] int connection_read_to_buf(connection_t *, ssize_t *, int *)(): 1000264: starting, inbuf_datalen 0 (0 pending in tls object). at_most 16448. 0:0:54:227302 [thread-2] 0:10:55:012000001 [shadow-debug] [4uthority1-73.1.0.0] [_tcp_endOfFileSignalled] 73.1.0.0:10021 (descriptor 1000264) <-> 91.1.0.0:9111: signaling close to user, socket no longer usable 0:0:54:227321 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] TLS error: unexpected close while reading (SSL negotiation finished successfully) 0:0:54:227338 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] int tor_tls_read(tor_tls_t *, char *, size_t)(): read returned r=0, err=-8 0:0:54:227354 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] int connection_read_to_buf(connection_t *, ssize_t *, int *)(): TLS connection closed on read. Closing. (Nickname nonexit10, address 91.1.0.0) 0:0:54:227373 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] void channel_close_for_error(channel_t *)(): Closing channel 0x7f546d03ce40 due to lower-layer error 0:0:54:227389 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] void channel_change_state(channel_t *, channel_state_t)(): Changing state of channel 0x7f546d03ce40 (global ID 21) from "open" to "closing" 0:0:54:227420 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] void channel_remove_from_digest_map(channel_t *)(): Removed channel 0x7f546d03ce40 (global ID 21) from identity map in state closing (4) with digest BBF25A366EA5376B0026CE6EDE3DF536211429BE 0:0:54:227440 [thread-2] 0:10:55:012000001 [shadow-debug] [4uthority1-73.1.0.0] [tcp_close] 73.1.0.0:10021 (descriptor 1000264) <-> 91.1.0.0:9111: user closed connection 0:0:54:227452 [thread-2] 0:10:55:012000001 [shadow-debug] [4uthority1-73.1.0.0] [_tcp_setState] 73.1.0.0:10021 (descriptor 1000264) <-> 91.1.0.0:9111: moved from TCP state 'TCPS_CLOSEWAIT' to 'TCPS_LASTACK' 0:0:54:227473 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] void connection_mark_for_close_internal_(connection_t *, int, const char *)(): Calling connection_mark_for_close_internal_() on an OR conn at /home/coffee/shadow/shadow/build/tor/src/or/connection.c:2932 0:0:54:227491 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] int conn_close_if_marked(int)(): Cleaning up connection (fd -1). 0:0:54:227509 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] void circuit_n_chan_done(channel_t *, int)(): chan to NULL/91.1.0.0:9111, status=0 0:0:54:227546 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] void channel_change_state(channel_t *, channel_state_t)(): Changing state of channel 0x7f546d03ce40 (global ID 21) from "closing" to "channel error" 0:0:54:227565 [thread-2] 0:10:55:012000001 [scallion-debug] [4uthority1-73.1.0.0] [scalliontor_logmsg_cb] int connection_remove(connection_t *)(): removing socket -1 (type OR), n_conns now 26 On Tue, Sep 3, 2013 at 10:47 AM, Karsten Loesing <karsten(a)torproject.org>wrote: > On 9/3/13 4:32 PM, Charlie Belmer wrote: > > Hi Karsten, > > > > I have run several tests, but I haven't been able to satisfy myself yet. > I > > attached the results from my latest round of tests for your review. I am > > comparing the n23 branch (UseN23 1 set in each torrc) with the initial > head > > I merged n23 with. It seems that for some reason, the n23 branch > completes > > far fewer downloads, though I haven't yet found the cause, or found > > anything interesting in the logs. > > > > $ grep "fg-download-complete" m1.large-tor/data/scallion.log | wc -l > > 8827 > > $ grep "fg-download-complete" m1.large-n23/scallion.log | wc -l > > 308 > > > > I would definitely appreciate any thoughts, insights, or advice! > > Interesting! Can you re-run the n23 simulation on info or even debug > log level? That might reveal some more information. You'll do that by > running "scallion --log-level=INFO". A tiny network should be > sufficient for that. Watch out for filling disks. > > If you want me to look at the scallion.log file, feel free to post it > somewhere, and I'll see if something looks unusual to me. > > Thanks, > Karsten > > > > On Tue, Sep 3, 2013 at 8:58 AM, Karsten Loesing <karsten(a)torproject.org > >wrote: > > > >> Hi Charlie, > >> > >> did you have the chance to simulate your rebased n23-5 branch using > Shadow? > >> > >> If not, maybe I can help by simulating it once and writing down more > >> specific instructions for you? > >> > >> Thanks! > >> Karsten > >> > >> > >> On 8/8/13 10:36 AM, Karsten Loesing wrote: > >>> (Moving this discussion back to tor-dev@ with Charlie's permission.) > >>> > >>> On 8/6/13 4:10 AM, Charlie Belmer wrote: > >>>> Hey Karsten, > >>>> > >>>> I've been reading up on Shadow & Scallion to do some performance > >> testing on > >>>> N23. Before I go too far down that road, I wanted to check in with > you. > >>>> > >>>> Are there existing blueprints or best practices I should be following? > >>> > >>> Thanks for looking into this! > >>> > >>> So, I wouldn't call the following notes blueprints or best practices, > >>> but they are a description of what I would do to run Shadow simulations > >>> of your branch. > >>> > >>> First of all, be sure to read the Shadow wiki which has contains lots > of > >>> interesting stuff: https://github.com/shadow/shadow/wiki > >>> > >>> The next step would be to get a vanilla Tor master (that your branch is > >>> based on) running in a minimal or tiny Shadow network. It's probably > >>> easiest to use a local Ubuntu VM for this. Or you can start an > m1.large > >>> EC2 instance for the tiny network, or an even smaller instance for the > >>> minimal network. > >>> > >>> Once that simulation succeeds, you'll want to run another simulation > >>> using your branch, extract performance metrics using Shadow's analyze > >>> script, produce a PDF with graphs also using the analyze script, and > >>> then wonder if things are faster than before. > >>> > >>> The minimal or tiny networks are mostly there to learn that things are > >>> working as expected. You'll probably want larger networks for real > >>> performance results, but starting small to get everything working is > >>> probably easier. > >>> > >>> Sounds doable, I guess. However, here's where things start to get > >>> tricky: in order to simulate Tor master (or a branch based on it) in > >>> Shadow, you'll have to perform quite a few extra steps like compiling > >>> your own CMake and Clang/LLVM. Not really hard, but you need to get > all > >>> pieces together before Shadow does what you want. > >>> > >>> I'm pasting detailed instructions that I used to simulate Steven's uTP > >>> branch in Shadow below as an example. Not everything applies to your > >>> branch, but it should give you the general idea. > >>> > >>> If something remains unclear, please feel free to ask! > >>> > >>>> Depending how it goes, I'd also look at re-trying adaptive 23 or > tuning > >> the > >>>> existing implementation. > >>> > >>> Neat! We should probably include Mashael in that discussion once you > >>> have a working and simulated n23-5 branch. Maybe she has ideas what > >>> parts need tweaking. I'm cc'ing her in this mail so she knows what > >>> you're working on. > >>> > >>> In any case, having a working rebased n23-5 branch is already a big > step > >>> forward. > >>> > >>> Thanks! > >>> Karsten > >>> > >>> > >>> === START OF INSTRUCTIONS === > >>> > >>> Launch new EC2 instance running Ubuntu Server 13.04 64 bit > >>> > >>> Set ulimit -n to 25000, see Shadow wiki for details > >>> > >> > https://github.com/shadow/shadow/wiki/Preparing-your-machine#system-configs… > >>> > >>> $ sudo apt-get update > >>> $ sudo apt-get upgrade > >>> > >>> Clone and test-compile modified libutp > >>> > >>> $ sudo apt-get install build-essential git automake libssl-dev > >> libevent-dev > >>> $ mkdir src > >>> $ cd src/ > >>> $ git clone https://github.com/sjmurdoch/libutp > >>> $ cd libutp/ > >>> $ make > >>> $ cd ../ > >>> > >>> Clone and test-compile Tor branch utp > >>> > >>> $ git clone https://git.torproject.org/tor.git > >>> $ cd tor/ > >>> $ git remote add sjm217 https://git.torproject.org/sjm217/tor.git > >>> $ git fetch sjm217 > >>> $ git checkout -b utp sjm217/utp > >>> $ ./autogen.sh > >>> $ LDFLAGS="-L/home/ubuntu/src/libutp" > CFLAGS="-I/home/ubuntu/src/libutp" > >>> LIBS="-lutp -lrt" ./configure --disable-asciidoc > >>> $ make > >>> $ make distclean > >>> $ cd ../ > >>> > >>> Modify Tor to use uTP for all links (or "0 &&" for not using uTP for > any > >>> link) > >>> > >>> diff --git a/src/or/channeltls.c b/src/or/channeltls.c > >>> index 0551b73..b7b36e1 100644 > >>> --- a/src/or/channeltls.c > >>> +++ b/src/or/channeltls.c > >>> @@ -418,7 +418,7 @@ channel_tls_connect(const tor_addr_t *addr, > uint16_t > >>> port, > >>> /* Create a uTP connection */ > >>> tor_addr_to_sockaddr(addr, port, (struct sockaddr*)&sin, > sizeof(sin)); > >>> tor_addr_to_str(addr_str, addr, sizeof(addr_str), 0); > >>> - if (!strncmp(addr_str, "128.232.10.129", sizeof(addr_str))) { > >>> + if (1 || !strncmp(addr_str, "128.232.10.129", sizeof(addr_str))) { > >>> log_info(LD_CHANNEL, > >>> "Trying uTP connection to %s", addr_str); > >>> tlschan->utp = UTP_Create(tor_UTPSendToProc, tlschan, (const > struct > >>> sockaddr*)&sin, > >>> > >>> Install CMake 2.8.10 > >>> > >>> $ wget http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz > >>> $ tar xf cmake-2.8.10.2.tar.gz > >>> $ cd cmake-2.8.10.2/ > >>> $ ./configure > >>> $ make > >>> $ export PATH=~/src/cmake-2.8.10.2/bin:$PATH > >>> $ cd ../ > >>> $ which cmake # result: /home/ubuntu/src/cmake-2.8.10.2/bin/cmake > >>> > >>> Build Clang and LLVM from source > >>> > >>> $ wget http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz > >>> $ wget http://llvm.org/releases/3.2/clang-3.2.src.tar.gz > >>> $ tar xaf llvm-3.2.src.tar.gz > >>> $ tar xaf clang-3.2.src.tar.gz > >>> $ cp -R clang-3.2.src llvm-3.2.src/tools/clang > >>> $ cd llvm-3.2.src/ > >>> $ mkdir build > >>> $ cd build/ > >>> $ cmake -DCMAKE_INSTALL_PREFIX=/home/ubuntu/.local ../. > >>> $ make > >>> $ make install > >>> $ export PATH=~/.local/bin/:$PATH > >>> $ cd ../../ > >>> $ which clang # result: /home/ubuntu/.local/bin//clang > >>> > >>> Install Shadow > >>> > >>> $ sudo apt-get install gcc xz-utils make automake autoconf cmake tidy > >>> libtidy-dev libglib2.0 libglib2.0-dev dstat pdftk python2.7 > >>> python-matplotlib python-numpy python-scipy > >>> $ git clone https://github.com/shadow/shadow.git > >>> $ cd shadow > >>> $ ./setup dependencies > >>> $ ./setup build -g -i /home/ubuntu/src/libutp -i > >>> /usr/include/x86_64-linux-gnu/c++/4.7 -l /home/ubuntu/src/libutp > >>> --tor-prefix /home/ubuntu/src/tor --tor-lib utp > >>> $ ./setup install > >>> $ export PATH=~/.shadow/bin/:$PATH > >>> > >>> Simulate tiny network in Shadow > >>> > >>> $ cd resource/examples/scallion/ > >>> $ tar xf tiny-4GB-m1.large.tar.xz > >>> $ cd tiny-4GB-m1.large/ > >>> $ scallion > >>> > >>> Graph simulation results > >>> > >>> Add one line to beginning of analyze.py: > >>> > >>> import matplotlib; matplotlib.use('Agg') > >>> > >>> For additional traffic simulations: > >>> > >>> $ grep -v "\[traffic-" scallion.log > scallion-notraffic.log > >>> > >>> $ cd ~/src/ > >>> $ mkdir results > >>> $ cd results/ > >>> $ python ~/src/shadow/contrib/analyze.py parse --output uTP-1 > >>> > >> > ~/src/shadow/resource/examples/scallion/tiny-4GB-m1.large/data-utp-1/scallion.log > >>> $ python ~/src/shadow/contrib/analyze.py parse --output uTP-0 > >>> > >> > ~/src/shadow/resource/examples/scallion/tiny-4GB-m1.large/data-utp-0/scallion.log > >>> $ python ~/src/shadow/contrib/analyze.py parse --output vanilla > >>> > >> > ~/src/shadow/resource/examples/scallion/tiny-4GB-m1.large/data-vanilla/scallion.log > >>> $ python ~/src/shadow/contrib/analyze.py plot --title "sjm217's utp > >>> branch (#9166)" --prefix "sjm217-utp" --data vanilla/ "vanilla > >>> 0.2.4.4-alpha" --data uTP-1/ "uTP for all links" --data uTP-0/ "uTP for > >>> none of the links" > >>> > >>> === END OF INSTRUCTIONS === > >>> > >>> > >> > >> > > > >

2 2

Hidden Service location referrals in DNS/web
by Jeroen Massar 13 Sep '13

13 Sep '13

Hi, I don't know what the current status/discussion for this is, hence this email, a reply to a ticket # or mail thread would be fine too ;) Is there currently a plan or way to state for a site: "you can find us as hidden service X" ? In DNS we could use something like: www NAPTR 10 50 "s" "TOR+HTTPS" "" _https._tcp _https._tor. SRV 0 0 443 <fingerprint>.onion. Of course, there is a latency hit there, DNSSEC should be used for authentication and if there is somebody watching DNS they know that you have something that looks at Tor records, thus it might not be ideal for all situations. Having a Torified DNS resolver would resolve that though. Using _https._tor. allows other services to also use this scheme. When 'datagram tor' comes out we can add a "_dtor" or something to support datagram variants of the connections. Another way, which does not show that you are looking for Tor would be to use the "alternate" link ability of HTML, eg for RSS there is: <link rel="alternate" type="application/rss+xml" title="RSS version" href="/rss/" /> Thus we could have something like: <link rel="alternate" type="application/tor+hiddenservice" title="Tor hidden service version" href="https://<fingerprint>.onion" /> on a webpage. If the webpage you get that on is https you have assurance that the hiddenservice is truly there. That would be webpage only though, but that is quite a large portion of the web... Greets, Jeroen

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2013