Re: [tor-relays] Anti-Sybil (re: Explain... all the Nodes)
On Thu, May 02, 2019 at 04:01:52PM -0400, grarpamp wrote: > On 5/2/19, Herbert Karl Mathé wrote: > > I strongly believe certain issues need be brought up into conscious, and > > into presence: into discussion, actually. > > > > Therefore appreciating this as it might fit too well into context > > > > Keeping things below surface, or trying so, has too often proven to be a > > very bad idea as these will come up sooner or later anyway, then with much > > higher magnitude. Even worse, trust is then destroyed. > > As said before, the category of Anti Sybil Web of Trust Projects > needs considered, and could even cover such speculative subjects. > > It's not about analysing the meta of one node or one operator, > even if a true positive hit, in general the yield is approximately > zero percent of any overlay network's nodes, it's about stepping > back and agnostically analysing them all. > > Go investigate and collate all the possible meta informations... > > Node location, payment, OS, ISP, uptimes, anon / nym / PGP / GovID, > workplace, politic, blogs, whatever else you can imagine, > including incorporating what's already in the consensus, contact, > MyFamily, nickname, both real world and virtual infos, > operator to operator p2p Web of Trust... > Note that we created a research system for gathering such data, reasoning about the trust implications, and applying it to routing decisions. we wrote a paper on it that we presented at PETS 2015. "20,000 In League Under the Sea: Anonymous Communication, Trust, MLATs,and Undersea Cables" https://www.petsymposium.org/2015/papers/04_Jaggard.pdf I don't know that anyone has done much with this since, but I hope that's helpful information. aloha, Paul > No node has to supply any infos. > > Put it all in a db and give users tools to select node sets. > > Some users might select State's, or State's workers or > even Statist's nodes, over say anon nodes, as maybe they > feel they have to play by some "rules" that anon nodes don't. > Others might reject operators that post stupid pics on Facebook. > Or all Ubuntu relays. Or nodes that engage in free speech > they don't like, some in Tor Project would love that selector, lol. > > It doesn't matter, it's a meta project, with it you can accept or > reject on whatever whim you wish by node fingerprints in your client. > > And if the Sybil WoT project ends up discovering some interesting > potential threats classes among the entire node set, you win. > Until then, you are potentially missing all of that, and are not > raising Sybil's costs of doing business by forcing them to > expend much resource into playing real world Web of Trust > against users who might select to use various positive-meta-ranking > and or WoT structures. Right now Sybil's cost is only a little hosting. > > If not, you can still report bad exits and other actual technical > node and traffic mangling to tor-relays and or bad-relays, > at least until someone DHT's or otherwise distributes tor > away from the more centralized DA design. > > Note that Tor's architecture does not protect much against > Global Passive Adversary of NSA style fiber Vampires, > that threat does not require Sybil nodes, nor do they > have to be Global or Govt, even Tier-N backbones can > tap, analyse, and do nefarious things like and with that, > including sell, give, and partner it all away. > Though they can and do run Sybil nodes to help inject, > manipulate, block, see, etc traffic, nodes, and clients. > > On flip perspective, maybe you really don't want to develop > WoT's and such, simply because enabling creeping featureism > of it all can lead to exclusivity and control whereby valuable anon > diversity is selected away from and purged. That would be very bad. > > Either way, other than the usual design, protocol, code, and "Lawfare" > exploit space, and the coming Quantum Compute adversary, Sybil and Vampire > are likely todays biggest remaining threats to overlay networks. > > None of todays networks seem to be trying to do anything to stop > Sybil, and only a few networks put Vampire as any sort of priority [1]. > While Vampire may perhaps be solved with some technical measures, > Sybil may require some sort sort of human based measures. > > > [1] Curiously, cryptocurrencies do employ Anti-Sybil in various > proofs of work (adversary cost raising), and can help defund Vampires. > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] OR banned?
I have no say in how/when your relay can be reinstated. But, before
you resume any such research from any relay you should consult the Tor
Research Safety Board guidelines and then submit to them a request for
advice about the research you wish to do.
https://research.torproject.org/safetyboard.html
HTH,
Paul
On Thu, Aug 24, 2017 at 02:35:29PM -0300, Marcus Danilo Leite Rodrigues wrote:
> David,
>
> My relay was harvesting .onion addresses and I apologize if that breaks any
> rule or ethical guideline.
>
> I'm a Junior Researcher at the Laboratory of Security and Cryptography at
> University of Campinas. We were conducting some research on malicious
> Hidden Services to study their behavior and how we could design a tool that
> could tell malicious and benign Hidden Services apart.
>
> Because we focus mainly on web pages, we use a crawler to get almost all of
> the data we need. However, there are some statistics (such as the size of
> the Tor network, how many HSs run HTTP(s) protocol, how many run other
> protocols and which protocols do they run, etc) which cannot be obtained
> through a crawler. That's why we were harvesting .onion addresses.
>
> We would run a simple portscan and download the index page, in case it was
> running a web server, on a few random addresses we collected. We would also
> try and determine the average longevity of those few HSs. However, after
> collecting the data we needed for statistical purposes, the .onion
> addresses we collected would be deleted and under no circumstances we would
> disclose the information we collected on a specific .onion address we
> harvested. In addition, we would never target specific harvested HS, but
> only a random sample.
>
> We would like to keep running our relay. We can make this process as
> transparent as possible without disclosing any information that would harm
> the anonymity of any user. We could also comply with any demands that the
> Tor authorities might have. In case that's not possible, we will completely
> respect your decision and will no longer harvest .onion addresses. However,
> I'd like to ask for our IP address range to be unbanned so that other
> people at my university can conduct some other research in the future and
> so we can run a regular relay :)
>
> I appreciate the time you took to address this issue and I'm willing to
> answer any questions you may have.
>
> Much obliged,
> Marcus.
>
> 2017-08-24 12:16 GMT-03:00 David Goulet :
>
> > On 24 Aug (12:11:47), Marcus Danilo Leite Rodrigues wrote:
> > > Hello.
> > >
> > > I was running a Tor Relay for the past month (fingerprint
> > > 71BEBB61D0D35234D57087D035F12971FA315168)
> > > at my university and it seems that it got banned somehow. I got messages
> > on
> > > my log like the following:
> > >
> > > http status 400 ("Fingerprint is marked rejected -- please contact us?")
> > > response from dirserver '171.25.193.9:443'. Please correct.
> > >
> > > I was hoping to get some information regarding this ban and how I could
> > > correct whatever was done wrong in order to get my relay up and running
> > > again.
> >
> > Hello Marcus,
> >
> > You relay has been found to be harvesting .onion addresses which is
> > strictly
> > prohibited on the network.
> >
> > See https://blog.torproject.org/blog/ethical-tor-research-guidelines
> >
> > Were you conducting some research or ?
> >
> > Thanks for running a relay!
> > David
> >
> > >
> > > Best wishes,
> > > Marcus Rodrigues.
> >
> > > ___
> > > tor-relays mailing list
> > > tor-relays@lists.torproject.org
> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
> >
> > --
> > dI6qBwjRAsZuHbMRuPaXkArKESn4fYnY9Gcn/UW8Dlc=
> >
> > ___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
> >
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] torservers.net: some exits became guards? (deanonymization risk)
Hi Nusenu, On Thu, Jun 08, 2017 at 09:58:00AM +, nusenu wrote: > Dear Torservers, > > are you aware that you have recently become a relay operator with > end-to-end correlation (deanonymization) capabilities? (in fact you are > the biggest known such operator) > This is especially bad for tor clients because you are also one of the > biggest tor exit operators. > > Some of your relays which used to be exits recently became guard-ony relays. > https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#httpswwwtorserversnetdonatehtml-support-a Apologies if this is focusing on a minor point of your message or illuminates nothing but my general tiredness/distractedness, but I don't see how switching a relay from being an exit to being guard-only increases correlation risk from that relay. It shouldn't be possible to use the relay in both positions simultaneously. And even if it could serve as both guard and exit simultaneously, the route-selection algorithm would preclude it being used as both ends for any circuit. And if all torservers.net relays are properly indicated to be from the same family, they will never be selected for both ends of a circuit. Potentially, a client opening multiple circuits through multiple guards (so not using the current standard default of using a single guard) could have some guards and some exits of concurrent circuits run by torservers.net if they satisfy the /16 separation. But that is generally not what is meant by 'end-to-end correlation'. aloha, Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is there a reason for all exit nodes being public?
On Wed, Dec 07, 2016 at 02:15:55PM +0200, Rana wrote: > >How would that work? First of all, the clients need to know which exit nodes > >exist, so that they can build circuits. That list, as well as that of the > >middle nodes, is public, otherwise you'd >have to manually request exits by > >email/web service/… As a result you'd be limited to a few exits, which might > >not necessarily have an exit policy matching your needs, or might be > >offline, >or simply overloaded on account of there being less than regular > >exits. > The same way bridges work. They are not published. > > >By the way, I just checked, Gmail works without problems over Tor (both Web > >and IMAPS). > Using Gmail over Tor when they already know who you are is > self-defeating. Try to register an anonymous Gmail account using > Tor. Responses have already been given in this thread about trying to obtain an email account that is anonymous (err, pseudonymous) with the intended meaning that the service provider is not directly given another identity (phone number, etc.) intended to be kept separate---where "given" means that the service provider can (easily) associate these. (So not some sort of ZKP of a blinded credential, etc.) 'Anonymous' often gets thrown around quite recklessly, but the much more important problem with the above statement is perpetuating the false impression that letting a service provider know such associations must be contrary to the goals of Tor. As we wrote in 1996, "Our motivation here is not to provide anonymous communication, but to separate identification from routing. Authenticating information must be carried in the data stream... use of a public network should not automatically reveal the identities of communicating parties. The goal here is anonymous routing, not anonymity." As of last April, FaceBook reported over a million users per month via Tor. As to GMail, you might want to access GMail over Tor to complicate geo-location by GMail, or because you don't want a local ISP (or your VPN provider or...) to know you are accessing GMail, or... aloha, Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TOR router install without access to root
In case it helps, here is a paper describing vulenrability of different classes of Tor user behavior to AS, Internet Exchange Point, and Tor relay or relay family adversaries. http://www.nrl.navy.mil/itd/chacs/biblio/users-get-routed-traffic-correlation-tor-realistic-adversaries Note that doing AS-aware routing so as to improve security is a fairly active area of research. Nonetheless, I think the original point about hosting providers having physical access to hardware with keys from many independently-run relays has not been amongst the considerations. It is countered somewhat by even current Tor's default routing algorithm that prevents choosing relays in the same circuit from the same family but also from the same range of IP addresses. But it hasn't been scrutinized specifically as far as I know. And here is a paper giving a framework to be able and talk about and use expectations of adversaries at the above places, and on undersea cables, via mutual legal assistance treaties, etc. (Note that this is research. It is some years away from anything like this being deployed in Tor. And trying to design trust policies and routing algorithms for your own Tor traffic is not something even an expert should try at this stage of development.) http://www.nrl.navy.mil/itd/chacs/jaggard-2-league-under-sea-anonymous-communication-trust-mlats-and-undersea-cables-proceedings HTH, Paul On Wed, May 25, 2016 at 10:41:22PM +0200, pa011 wrote: > @Green > Thank you - couldn’t handle 'attack vector' as a synonym for ""method or > type of attack" :-) > > Additional to that is it clever for a supporter of TOR to to run more > than one Relay (Exit) with a single ISP or even AS > https://en.wikipedia.org/wiki/Autonomous_system_(Internet) or does this > build a kind of new attack vector? > > > > Am 25.05.2016 um 22:22 schrieb Green Dream: > > @Paul: sure. Nils pointed out that a lot of relays using the same > > hosting provider could be an attack vector, because the provider would > > be a single point where all the relays' secret keys could be collected. > > My point is that if you look at the AS (Autonomous System) Number, it's > > normally the same for all the hosting provider's servers in that > > country. So if Tor path selection looks at the AS, and avoids building a > > circuit that uses two nodes from the same AS, this attack vector > > basically goes away. It's worth noting if you weren't already aware, > > both Atlas and Globe display the AS Number for every relay. > > > > > > > > ___ > > tor-relays mailing list > > tor-relays@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor hidden services & SSL EV certificate
On Tue, Dec 29, 2015 at 12:27:06PM -0900, Jesse V wrote: > On 12/29/2015 11:18 AM, Aeris wrote: > >> A few hidden services have added an > >> HTTPS cert but I think that's mostly for a publicity stunt than anything > >> else. > > > > As indicated in the roger’s lecture, HTTPS is usefull for HS : > > - browsers handle more securely cookies or other stuff in HTTPS mode, > > avoiding some possible leaks > > - because anybody can create an HS and proxify any content, X.509 certs > > allow users to verify the authenticity of the HS (you are on the official > > Facebook HS if you have a cert with facebook.com *AND* > > facebookcorewwwi.onion > > inside) > > > > I've downloaded the .webm of Roger's lecture but haven't had the time > today to listen to it. My point was that HSs already have an > authentication mechanism and it's assumed that you can verify the > address through some trusted out-of-band method, so in that case you > don't need an SSL cert. This can sometimes be superior to trusting the > centralized CA model, but I agree that the points you've listed are > useful applications as well. > In case it is helpful. Griffin Boyce and I have a paper forthcoming in IEEE Security & Privacy Magazine on this topic. The final editorial changes are not in so it might change a little, but you can find the hopefully-close-to-final version at https://github.com/saint/w2sp-2015/blob/master/SP_SPSI-2015-09-0170.R1_Syverson.pdf It covers - How the self-authentication of onionsites that Jesse has been noting and the SSL certs for registered-domain websites that Benoit asked about can complement each other in a variety of ways---and not just for big companies but for individuals, small businesses, local organizations, clubs, sports teams, etc. - The current state of certs for onionsites (EV only), and what the issues are that stand in the way of DV certs and a proposal for resolving them. - How this can all dovetail nicely with Let's Encrypt (an issuance and usage design that binds things together nicely so it is hard to undetectably set up a spoof onionsite of another onionsite of a registered-domain site, etc. and vice versa) once DV certs are allowed. - A description of using GPG that can be done right now while waiting for the world to catch up, and an existing example of a site that does such binding (from a small site operator who found his hosting provider was blocking access from the Tor network). We just cited one such example in the paper, but there are of course others, e.g., https://blog.patternsinthevoid.net/isis.txt aloha, Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Giving away some "pre-warmed" relay keys for adoption
On Sun, Jul 26, 2015 at 08:41:13AM +, Yawning Angel wrote: > On Sun, 26 Jul 2015 07:13:44 +0500 > Roman Mamedov wrote: > > Either way you won't do much damage even if any of this ends up being > > false, as the consensus weight and the stable status will drop more > > rapidly than they are gathered if your node can't maintain them. > > Giving away the identity keys for high capacity relays that actual > users are using as Guards seems irresponsible at best, and downright > malicious assuming a realistic threat model for the Tor Network as a > whole. > I've been following this thread but haven't had time (and won't for several days at least) to formulate a thorough thoughtful response, but your statements are too absolute and without qualification. I'm not saying that specifically the intended actions (whatever they may be) in this case are reasonable. I am saying that your responses are too broad. Let's assume purely for simplicity that the transfer can be done in a secure fashion. Then if, for example, someone transferred keys to long-known trusted persons w/in the Tor community (say some of the dir-auths and others at similar levels of trust) in a way that (a) actually diminished the network concentration of trust among people by spreading his family to others where the result is more flat, and (b) paid attention to AS, country (by Geo-IP), etc. so that neither AS nor country changed. This should probably be fine. (I actually don't think (b) is needed if this is a relatively rare occurrence. Given other aspects of network churn and the very limited way that Tor currently manages location awareness, that is not the low-hanging fruit.) There are probably other scenarios where this would be an OK action. And it's not just a security/performance trade-off. Having those relays just disappear reduces the diversity and capacity of the network, which has security implications too. Here is another example wrt another factor. (If I'm going on too long here and losing you, skip the rest of this paragraph.) Someone could be maintaining several relays reasonably well but realize that their ability to securely maintain them is going to diminish slightly for some reason, still probably keeping them among the upper half of relays wrt security practice and circumstance. However, they realize that they can securely transfer authority over those relays to people who are both more trusted/reputed w/in the Tor community and in a better position to maintain their security going forward. In that case, they would be improving the security of the network by (securely) handing over the private keys than by continuing to maintain the relays themselves. It is fine to note that this is something that could only make sense if done carefully. But claiming that the transfer of authority over private keys from on person to another must always be irresponsible diminishes the value of your primary point by overstating the argument. aloha, Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to Run High Capacity Tor Relays
On Fri, Jul 24, 2015 at 04:06:14AM -0400, grarpamp wrote: > On Wed, Jul 22, 2015 at 11:08 AM, teor wrote: > > The 20 July 2015 platform percentages on > > https://metrics.torproject.org/servers-data.html are: > > 87.9 Linux > > 6.9 Windows > > 4.5 FreeBSD > > 0.5 Darwin (OS X, OpenDarwin, …) > > 0.1 Other > > with counts... > 6042 Linux 83% > 889 Windows 12% > 220 FreeBSD 3% > 71 OpenBSD 1% > 41 Darwin .5% > 10 NetBSD .1% >5 SunOS >4 DragonFly >4 Bitrig >1 GNU/kFreeBSD >1 ElectroBSD > > Market share doesn't really say anything about ability to fill the > relay role, Good point. This also may not be the revealing indication of market share. The distribution can be quite different if the question is not number of relays per platform but fraction of bandwidth by platform or probability of being chosen as exit (or guard, etc.) by platform. aloha, Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Subpoena received
On Thu, Apr 23, 2015 at 11:47:17AM +0200, re...@mobtm.com wrote: > Hi, > > > The counterpart we need to contribute is a > > letter by our lawyer and favorably a letter from EFF or some other > > bigger organization guaranteeing Tor is what it is and we as client do > > not try to fool them. > > as the US government sponsored (parts of) the Tor development - what > about giving them US military research papers about the Tor network? > > http://www.dtic.mil/dtic/tr/fulltext/u2/a465464.pdf is one of them, > co-authored by a Navy researcher and performed by the Naval Research > Laboratory. > Not merely sponsored: I created Tor along with Roger and Nick, and I invented the underlying onion routing technology years earlier with David Goldschlag and Mike Reed. All of this was done under NRL projects with funding we received from various sponsors. I have no idea what is legally relevant for this, but it might also be useful to point them at ExoneraTor https://exonerator.torproject.org/ which was designed after interactions with law enforcement indicated that such a tool would be useful for them. aloha, Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On Thu, Jan 08, 2015 at 10:04:35AM -0500, Nick Mathewson wrote: > Hi, all! > > While looking into a bug report, I noticed that an exit node was using > one of Google's well-known public DNS servers for its own DNS server. > > No disrespect to the operators of Google's fine public DNS service, > but my sense is that using it for a Tor exit node might not be the > greatest idea for users' privacy, having one DNS provider that gets to > see so many requests. It's probably a better idea to have your own > local cacheing DNS server. > > Would anybody like to share a guide about how to set one of those up > safely and migrate correctly? > I know people have already started to make specific suggestions and I don't intend to comment on those. But I wanted to say that in general there is another consideration: AS and other network level vulnerabilities. Obviously recursive resolution may send queries wherever, but using a local resolver should limit the network adversaries seeing exit DNS traffic. The flip side is that, against such an adversary, using a DNS server that supports encryption of queries and responses is probably more important than it being local. (At least until Tor starts choosing exits to minimize exposure to network adversaries on the destination link ;>) -Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Close friend
On Mon, Aug 18, 2014 at 04:41:33PM +1200, Christian Gagneraud wrote: > On 18/08/2014 4:26 p.m., Rex Wolf wrote: > >On 17/08/2014 9:11 PM, IceFish ThreeTwo wrote: > >>I'm pretty sure I read somewhere that the Family option in torrc is > >>used so that nodes administrated by the same person never make a > >>circuit with each other, which somehow protects anonymity. Should my > >>friend and I put each other's fingerprints in the Family field? Seems > >>logical since we know each other and if the point of theFamily field > >>is to protect anonymity. > > > >Hi IceFish, > > > >The MyFamily option is what you've described--an option used so that > >nodes administered by the same person / entity will only be used once in > >any given circuit (other nodes from the same family will not be used in > >the same circuit). > > > >This isn't so much to protect your anonymity as a relay operator, but to > >limit any one client's potential vulnerability. For example, if one > >relay operator happens to control both the guard node and the exit node > >in a circuit, they can correlate the timing of packets entering and > >exiting the network, and determine both a person's identity and the > >content of their traffic. > > On the other hand, if I'm a bad guy who as lot of entry and exit nodes, I > will certainly not disclosed it by using a "MyFamily" flag... Right. It's not meant to guard against that. But if you're honest and you are threatened or coerced or your relays are otherwise collectively compromised, MyFamily limits the damage. aloha, Paul > > Chris > > >You and your friend may know each other, but unless you both administer > >each other's nodes, I don't think you would need to use the MyFamily option. > > > > -Rex > > > > > > > >___ > >tor-relays mailing list > >tor-relays@lists.torproject.org > >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Grouping cloud relays running within same provider
On Fri, Apr 18, 2014 at 10:02:33PM +0200, Paul Staroch wrote: > Am 2014-04-18 21:31, schrieb mr.cur...@urssmail.org: > > Is there any way currently to do this, or are there already some > > safeguards in place? > > In its default configuration, Tor ensures that each relay in a > circuit belongs to another /16 subnet (cf. Tor Path Specification > [1], section "2.2. Path selection and constraints"). However, in the > case of Amazon EC2, this constraint does not suffice as Amazon uses > IP addresses from several different /16 subnets. > Note that this important but was not a guarantee even before the use of cloud relays. In my 2009 paper with Matt Edman "AS-Awareness in Tor Path Selection" we described the generation of 1500 paths using the Tor path selection algorithm "Of those 15,000 paths, 163 (or ≈ 1.1%) contained an entry and exit node that resided in the same AS despite having an IP address from different /16 subnets. Out of those 163 paths, all but one also had a distinct /8 network address." aloha, Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Watching the attacks on my relay
On Sat, Nov 09, 2013 at 12:50:18PM +, mick wrote: > On Fri, 08 Nov 2013 20:15:51 +0100 > elrippo allegedly wrote: > > > Jope. I tend to have some issues with some CA's. > > But yes you are right, i should get me a decent certificate. > > I will do that, promise. > > > > You self signed your site certificate...? > > > > > > > I don't see any problem per se with a self-signed certificate on a site > which does not purport to protect anything sensitive (such as financial > transactions). The problem with this particular certificate is that > the common name identifier is both wrong (www) and badly formattted > (http://) But both of those errors can be corrected very quickly. > > Why pay a CA if you don't trust the CA model? > You may want to take a look at https://blog.torproject.org/blog/life-without-ca -Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Amazon abuse report
On Mon, Nov 04, 2013 at 08:18:29AM -0800, Gordon Morehouse wrote: [snip] > > > > That's just plain silly. > > Not as silly as you think, but the outright blocking vs finding ways > to throttle is more a discussion worth having. I suspect most of the > Silent Majority(tm), if polled, would rather throttle than block. > > I *swear* there was a paper on this other than the 2009 one I posted > the other day. > Are you perhaps thinking of "Throttling Tor Bandwidth Parasites"? Available at http://www.syverson.org/ or http://www-users.cs.umn.edu/~jansen/publications.shtml Throttling is tricky and not a panacea. This is noted in the above paper and analyzed in some detail in "How Low Can You Go: Balancing Performance with Anonymity in Tor", also available at http://www-users.cs.umn.edu/~jansen/publications.shtml aloha, Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
