Re: GSoC proposal
First off, I am not interested in per circuit information, and I sincerely hope that tor would refuse to provide such information via its controller interface. The very idea seems in opposition to the purpose of tor. Actually, I was thinking to show the bandwidth of a circuit, without additional infos, to estimate how fast a circuit may be. Secondly, the kind of information I am interested in seeing would be primarily focused upon server operations and performance, such as a) the number of exits currently active to each active port, If I understand well you are interested in knowing the tcp / udp ports contacted by exit connections ? b) the number of exits to each port during some time interval (e.g., an hour) for consecutive time intervals (i.e., a way to collect hourly statistics throughout each day), OK but remember my objective wasn't to collect statistics continuously. Of course, it would be available while monitor run. c) the number of circuits currently using each existing router connection, d) the current, average, and actual maximum number of onion skins queued for decryption over some preceding time period, e) the hourly maximum number of onion skins queued for decryption throughout the day, f) the number of relay-only circuits currently active, g) the number of hidden service introductions/rendezvous connections currently active and during hourly periods throughout the day, h) statistics showing how closely (or not) the BandwidthRate and BandwidthBurst targets are being met, and i) statistics regarding cells dropped for each of the possible reasons, and j) statistics on various directory service operations. I took note, I think relay's admin would be helped a lot with theses information. Best wishes for a successful project! Thanks you very much for your suggestions, they are relevant, and I would enjoy to have such data available for my relay :) Regards, Baptiste
SSL Certs Cached By Browsers, Privacy Issues?
Aside from the much discussed forged SSL certificates, and the most recent mention of uptime being passed via SSL, I now bring up a new discussion regarding legit SSL certificates, how they may be stored/cached and any possible privacy implications of this. Are there any privacy considerations when it comes to your browser, Tor, and SSL? The subject was brought up on #tor @ irc.oftc.net the other day, with a brief log pasted to the bottom of this post for reference. It was observed, in Konqueror (Settings-Configure Konqueror-Crypto-Peer SSL Certificates- and click on one cert to see cache options) peer certs may be cached and they may expire or be retained forever, are there privacy implications to either choice, or to the caching of these certs in particular? Specific questions for those of you who know anything about SSL: + How do different browsers (Firefox, Epiphany, Konqueror, etc.) cache SSL certificates? + If the cache method differs, to what degree? Is any method between them more dangerous to privacy when using Tor or not? + Should cached SSL certs be purged from the browser between sessions? + What about SSL2? Any tests, thoughts, discussions on this topic welcome here on the list! ** * BEGINNING OF CHAT LOG FOR REFERENCE: ** madgorilla Two questions: [1] When you accept an SSL cert from a website does retaining it until it expires affect privacy, esp when I read an uptime ssl bug with ff recently, should these be purged after each browser session [2] may tor hidden services use SSL stacked on top? nickm 2 is easy: yes. madgorilla ty nickm 1 depends on browser behavior and what you mean by accept. madgorilla reading on the tor list someone mentioned uptime being transmitted through SSL with FF, perhaps not a bug but a feature? :P madgorilla and by mean accept I mean cache peer ssl cert until they expire nickm I don't see what the uptime problem has to do with retaining ssl certs. madgorilla okay, let us ignore the uptime issue and focus on retaining ssl certs then for the sake of this question please :) madgorilla should these be purged between browsing sessions or retained madgorilla some say they are valid for years nickm okay. so I could be wrong about this, not being as deep in ssl as I'd like, but my understanding is that whenever you connect to an ssl server for a new session, the server sends you a certficiate. Every time. Does the browser really cache it? Or are you talking about clicking yes to the accept this cert forever button? madgorilla nickm, konqueror appears to cache them nickm I guess the browser could verify it only once, so it doesn't have to do the extra public key operation every time. madgorilla it even gives you the option to cache them forever madgorilla so how does firefox handle this and between the two, is there a risk madgorilla perhaps I could pose this Q to the list madgorilla or another one SSL related if such a ML exists madgorilla in konqueror: Settings-Configure Konqueror-Crypto-Peer SSL Certificates- and click on one to see cache expiration status and whether you want to retain it forever nickm To be clear, are you talking about certs you manually approve, or ones the browser accepts without your help. madgorilla I don't know how FF deals with them madgorilla In konqueror these are accepted unless they are bad madgorilla if they are bad it pops up with a warning and choices nickm Assuming by bad you mean not signed by a recognized CA, sure. madgorilla yes, sorry for any lack of clarity there. nickm So are you talking about certs that it asks you about, or all certs? weasel however, weasel when the cert is self signed or otherwise not automatically accepted by a browser and you say weasel accept this cert now and forever then next time you go there the site will be able to tell that you've been here before nickm right. weasel simply because you finish your ssl handshake faster killerchicken That is a very interesting topic killerchicken it seems that indeed a server can tell whether someone has already been to the site, even if they have a certificate signed by a trusted CA weasel other than session caching? killerchicken hm, I just had a very quick look at the RFC nickm Of course, if most users click accept now and forever and you don't, then you stick out a lot. killerchicken no, that's not it killerchicken it seems that clients could cache information about the master key killerchicken I don't know whether that is only session caching or lives for a longer time killerchicken mikeperry: ping killerchicken mikeperry: earlier, there was a discussion about ssl certificates killerchicken maybe you're interested mikeperry the one on or-talk? killerchicken no, in this channel killerchicken it was about whether a server could note that a client has been to the site before killerchicken By looking at how long it takes for the client to accept the cert, or possibly by not having to send a
Re: Smallest cheapest device to run a tor home server?
On Fri, Apr 11, 2008 at 11:47 AM, Rochester TOR Admin [EMAIL PROTECTED] wrote: Maybe someone else has found a better answer but when I researched this I found that although dd-wrt can run tor, there aren't any updated pre-built packages so you will most likely have to compile your own. Check out the archives for some help: http://archives.seul.org/or/talk/Sep-2006/msg00389.html I still think in the end it's better to run a cheap computer dedicated to tor than to try to install it onto the firmware. If you do find an easier solution, let us know! :) ROC Tor Admin On Thu, Apr 10, 2008 at 1:58 PM, Chris Palmer [EMAIL PROTECTED] wrote: Tom Arnold writes: I have a linux WLAN router ( DD-WRT ) with 125 Mhz, 4 mb flash and 16 mb RAM ( 3 mb free ). Is that enough to run Tor? ( I didnt find any recent ipk packages .. so i guess it is not worth it otherwise people would do it ... ) Would a 32 mb device with 200 mhz do the trick? Or what about the NSLU2 or the Linkstation. Or is a used laptop the best choice? Those are all likely to be insufficient. A used laptop could work, or you could take a look at sites like http://mini-itx.com/ for small systems. Personally I am running Tor on an old server, 2x500Mhz PII's with a cable modem (e.g., keeping ~1350 connections open at once). While I have quite a bit of RAM and hard drive space Tor doesn't take up much of either, and the computing power is more than enough. If you want me to run some benchmark's I'd be more than happy to. -madjon -- [EMAIL PROTECTED]
Re: Smallest cheapest device to run a tor home server?
Tom Arnold wrote: Would a 32 mb device with 200 mhz do the trick? Or what about the NSLU2 or the Linkstation. Or is a used laptop the best choice? So many questions :) ( BTW i didnt find any requirements on the homepage ) A fanless VIA Epia board, booted from CF could do the trick.
Re: Smallest cheapest device to run a tor home server?
Yes, Epia would certainly do the trick. I guess a 32mb router with 200 mhz could do it too. The Slug ( http://en.wikipedia.org/wiki/NSLU2 ) seems to work too. But i think something more powerfull like the gigabit Linkstation ( http://en.wikipedia.org/wiki/Linkstation ) will certainly be enough to route 60 kb/sec ( 30 up and down ) .. why would TOR need more resouces?? I think i might get an old Pentium notebook with 64mb+ RAM or a Linkstation.
Re: Smallest cheapest device to run a tor home server?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jonathan Addington wrote: (much snippage) Personally I am running Tor on an old server, 2x500Mhz PII's with a cable modem (e.g., keeping ~1350 connections open at once). While I have quite a bit of RAM and hard drive space Tor doesn't take up much of either, and the computing power is more than enough. If you want me to run some benchmark's I'd be more than happy to. (snip) Kitsune started on an old PII 300Mhz with 256MB of RAM; I've since migrated it to some AMD Duron 800Mhz/512MB RAM hardware a friend gave me. The Debian Etch install on the hard drive was transferred in its entirety via a dd command, although I did swap the generic x86 kernel for a K7-optimized one. Kitsune had been a guard node before, while on the PII; on the Duron, it's been running for about a month, and has been marked as Fast/Guard/Stable for most of that time. It's important to note that - as some have noted here - the stability of the perimeter router/firewall is VERY important. I used to have a WRT54G running HyperWRT/Thibor at the front lines; it crashed A LOT (it couldn't handle the large state tables that were being generated). After migrating kitsune, I killed the 54G's routing function, and converted it to a switch/AP only. The old PII that used to run kitsune, got a pfSense install. It's VERY stable, and the traffic shaper is really nice; I haven't had to use any traffic limitations on kitsune itself. * So, bottom line, the processing requirements aren't bad, but you need to be careful with what you do for a perimeter router/firewall. =:oD - -- F. Fox AAS, CompTIA A+/Network+/Security+ Owner of Tor node kitsune http://fenrisfox.livejournal.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSAAQe+j8TXmm2ggwAQih4Q/9F45ezsAvhZWTxp7UilRE4EZ+Ty1ZO2OF /N4Bpg5jKxFWJbSTNw6Q1pbwPD6AXx9CwTI3RsZopwTQwKlzp5rLhGm+vFoDDyB9 DxzLo95sYpBOV7b/m6l6m4EbtV5tDfuL/ClB/tBpMWybOrv8VByoNooSOeq4vXVx m56bmlofooqYu0DhLDhI/TeDQtpH3bTuqtuhk7Ta+gRRbN3icw20qn7p0oouh2zp BWTWBPc0o/6S1Tp46HyONoPgqBJQGJM0BKNDVPSHTYqc0pd7LF55zMOv5liXwr0Z ekRRo+M8wUE1HKerXbVmnntRcyl/pSBcSruYgBVDy53HHe2rU80Jr9tTjxLmCeI+ qDzOI/cp8kNduSUVl85B5dRKghc2U1mYDLykbcetsMBiB3QOQ5aTfaEZlDusl9WE DhjWRJ30huMyDyvId6xrOGFi59amPFr2OnayfsO0IDxmrAhBh36G9TWZcpBhVadi EPVXKJwAEzkTqpsZvOqoyRLWlzDT9zMQvNVWxdulUjcivf0E6AGaMs2mSr4Pq+5W CE4V91JqDyT3KbVSbhu0icwXE4EFG+4ruMAOGQ6Zjq4TMqwBXdf7aKlu14Y83P3o Ki6dO/JNOAFhTkkPwLCKv4Rh/X+G/zNY0KY5iCFNRRP5Th/QIPsp6YiRj7co7yw1 C2Q7cDaoQbQ= =Hd+1 -END PGP SIGNATURE-
Re: Smallest cheapest device to run a tor home server?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I should also note that with the pfSense box, I used a three-interface configuration, allowing for a true DMZ; this not only gave me more peace-of-mind, but made traffic shaping for the Tor server a lot easier. I just used catch-all rules for all traffic coming from and going into the DMZ, putting it in pfSense's P2P queue - the lowest priority. - -- F. Fox AAS, CompTIA A+/Network+/Security+ Owner of Tor node kitsune http://fenrisfox.livejournal.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSAARPuj8TXmm2ggwAQjNghAAoNt0YGdQvSdHTaOZIJ6pqtvflvu3Q91G xU5MO5t91VqKCTKUPlrtgOpS4jNaNgLF519Arv+gWWu+VrPQiWNQgKRsVrXOL4GF QTxuwX/Kd2v5VFHh2yYSyrhtW+o8vCBmIDDxb/Z2Kr68KW6XSDaws/TDLVXXxViY xdWX9GGQXS1j9Gn5ArcPZu4mVUH74ikkTB4mbokNRvS9NCK43NTOxMDVWm3t2BlA quKOShPsJmxd+CXWgd5nJpkPzDyNlXm32KSncTwVC6d/zF0WM5oDHCOK+ZJJ9fFT MPaa8SXv+fRWuwbbuJgrZJxDgrF2BCIzO1iGC5UlTurviQHcsZ+AOhitaT+UUpMq p4NUB5rnmGv/RnACTvznZP/+SgI9yV/pnXbw5q1DqbyITbAx1mMBMLNpahhoWHqi TSSlewdKa6EZYESeXn8Gz4voFxTAL5yj7bUv9jEGmR3WhJRHvERfdYEPzWo222A2 Psd++Vch7XfWEnj3c8RHqMbtkIuOfbbxQBcKSG7bSRxNbx/caQJfYEFRb76FpWzT E0TfRhQlLaTwtlrs+cMu8gH4aDWvrkgHUQKYQLdlXtqlE3XFq9Lr0JDi9JzN74vd NjEuJ3arwV8BxNJqNdlkjE3KDmIc7qVtEmREt+6Kx0x5zCaws7rA4MADmpDSROe3 J2qKY6uc674= =naTw -END PGP SIGNATURE-
