Re: [tor-talk] Massive Bandwidth Onion Services

On Mon, Dec 19, 2016 at 10:42 AM, David Goulet wrote: > So, in this case with 1 single intro point that fails, the client will ask > another HSDir for a new descriptor and so on... Of some relavance to those debugging above process... # hs_desc, hs_desc_content -

Re: [tor-talk] Intel ME / AMT + NSL vs Tor Nodes

On 19 Dec 2016 23:05 Roman Mamedov wrote: > > It can mess with your apps, OS and > security in all sorts of interesting ways, and you can NOT be absolutely > certain that it doesn't. No, but you can say the same about any complex system unless you built it yourself. How do you know for sure the

Re: [tor-talk] Intel ME / AMT + NSL vs Tor Nodes

On 12/19/2016 5:05 PM, Roman Mamedov wrote: On Mon, 19 Dec 2016 18:20:41 - "podmo" wrote: I could ...turn AMT off entirely. Unfortunately that's only what it wants you to believe. With the capabilities it has, and with its code being entirely closed source and

Re: [tor-talk] Intel ME / AMT + NSL vs Tor Nodes

On Mon, 19 Dec 2016 18:20:41 - "podmo" wrote: > I could ...turn AMT off entirely. Unfortunately that's only what it wants you to believe. With the capabilities it has, and with its code being entirely closed source and unaudited, for a truly secure system you can't rely

[tor-talk] Tor 0.3.0.1-alpha is out!

(Also, Tor 0.2.9.8 and Tor 0.2.8.12 are out. If you didn't know, you should subscribe to tor-announce an/or read the Tor blog!) You can find the Tor 0.3.0.1-alpha source on the website at the usual place. It's an alpha, so please expect plenty of bugs, and be ready to report them. Packages

Re: [tor-talk] NoScript problems after TBB 6.08 update

On 12/19/2016 12:41 PM, podmo wrote: On December 18, 2016 10:07 PM, Joe Btfsplk wrote: Never mind. The last NoScript 2.9.5.2 update included in TBB 6.08 over rode some of my settings. It changed the option "Allow HTTPS scripts globally on https documents" from unchecked to checked. FWIW,

Re: [tor-talk] NoScript problems after TBB 6.08 update

On December 18, 2016 10:07 PM, Joe Btfsplk wrote: > Never mind. The last NoScript 2.9.5.2 update included in TBB 6.08 over > rode some of my settings. > It changed the option "Allow HTTPS scripts globally on https documents" > from unchecked to checked. > FWIW, mine (Linux) didn't do this. Am on

Re: [tor-talk] Intel ME / AMT + NSL vs Tor Nodes

On 12/18/2016 10:22 AM, Milton Scritsmier wrote: > Not all Intel chipsets support AMT (check Intel's website for which ones > do, but most consumer PC/laptop chipsets don't), and for every version > of ME firmware there are two releases, one for chipsets with AMT support > and one for chipsets

[tor-talk] Flashproxy has been Deactivated by Stanford? Why?

Hello everyone, Today I was trying to embed a Flashproxy on my personal website, but after I inserted "https://crypto.stanford.edu/flashproxy/embed.html;, I failed to see the "Internet Freedom" icon displayed, nor any code was executed. Later, after inspected the code inside the HTML iframe

Re: [tor-talk] Massive Bandwidth Onion Services

On 19 December 2016 at 16:19, Allen wrote: > I got that point, that your service will have 60+ intro points. ...in six distinct descriptors, each containing 10 intro points, each of _those_ attached to one tor daemon. also said "people accessing the service onion address

Re: [tor-talk] Massive Bandwidth Onion Services

On 19 December 2016 at 15:42, David Goulet wrote: > Second, same occurs with modifying that RendPostPeriod from the default > value > of an hour to a custom time time. It makes you a bit more noticeable > because > you have a different behavior then anyone else. > > (And

Re: [tor-talk] Massive Bandwidth Onion Services

I got that point, that your service will have 60+ intro points. You also said "people accessing the service onion address at lunchtime will receive/cache different descriptors from those who access it some hours later", which lead me to believe that a single client will not "see" all of those 60+

Re: [tor-talk] Massive Bandwidth Onion Services

On 19 Dec (09:04:46), Allen wrote: > AFAIK, HiddenServiceNumIntroductionPoints >= 3 is also for the benefit > of the client, so if intro point #1 doesn't work for the client, it > can try to connect at intro point #2, and then finally at intro point > #3 before giving up. So let's say my Tor

Re: [tor-talk] Massive Bandwidth Onion Services

On 19 December 2016 at 14:04, Allen wrote: > AFAIK, HiddenServiceNumIntroductionPoints >= 3 is also for the benefit > of the client, so if intro point #1 doesn't work for the client, it > can try to connect at intro point #2, and then finally at intro point > #3 before giving

Re: [tor-talk] Massive Bandwidth Onion Services

AFAIK, HiddenServiceNumIntroductionPoints >= 3 is also for the benefit of the client, so if intro point #1 doesn't work for the client, it can try to connect at intro point #2, and then finally at intro point #3 before giving up. So let's say my Tor client looks up your Tor hidden service

Re: [tor-talk] Massive Bandwidth Onion Services

As an aside, this is what I am currently using as a daemon config. Comments welcome. I'm trying not to use Guards because again it would be rude to hammer them with vast data flows when instead the pain can be spread around a bit more; given that my target deployments are unlikely to be truly

[tor-talk] Massive Bandwidth Onion Services

I would post this to the tor-onions list, but it might be more generally interesting to folk, so I'm posting here and will shift it if it gets too technical. I'm working on load-balanced, high-availability Tor deployment architectures, and on that basis I am running 72 tor daemons on a cluster