[tor-talk] 'resolving or connecting to address '[scrubbed]' at 3 different places. Giving up.' error?

[Moses]

Hi,

I can not connect to Tor after upgrading to 0.3.1.7, the bootstaping is
100% completed, but I still can not connect any website or to any hidden
service. here is the log,


...
[notice] Bootstrapped 100%: Done
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
../src/or/relay.c:839 has n_chan==NULL. Dropping. (on Tor 0.3.1.7
6babd3d9ba9318b3)
[warn] Bug: . (Stack trace not available) (on Tor 0.3.1.7 6babd3d9ba9318b3)
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Heartbeat: Tor's uptime is 5:59 hours, with 27 circuits open. I've
sent 49.08 MB and received 89.40 MB.
[notice] Average packaged cell fullness: 28.663%. TLS write overhead: 5%
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
../src/or/relay.c:839 has n_chan==NULL. Dropping. (on Tor 0.3.1.7
6babd3d9ba9318b3)
[warn] Bug: . (Stack trace not available) (on Tor 0.3.1.7 6babd3d9ba9318b3)
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
../src/or/relay.c:839 has n_chan==NULL. Dropping. (on Tor 0.3.1.7
6babd3d9ba9318b3)
[warn] Bug: . (Stack trace not available) (on Tor 0.3.1.7 6babd3d9ba9318b3)
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
../src/or/relay.c:839 has n_chan==NULL. Dropping. (on Tor 0.3.1.7
6babd3d9ba9318b3)
[warn] Bug: . (Stack trace not available) (on Tor 0.3.1.7 6babd3d9ba9318b3)
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
../src/or/relay.c:839 has n_chan==NULL. Dropping. (on Tor 0.3.1.7
6babd3d9ba9318b3)
[warn] Bug: . (Stack trace not available) (on Tor 0.3.1.7 6babd3d9ba9318b3)
[warn] circuit_package_relay_cell(): Bug: outgoing relay cell sent from
../src/or/relay.c:839 has n_chan==NULL. Dropping. (on Tor 0.3.1.7
6babd3d9ba9318b3)
[warn] Bug: . (Stack trace not available) (on Tor 0.3.1.7 6babd3d9ba9318b3)
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Heartbeat: Tor's uptime is 11:59 hours, with 31 circuits open.
I've sent 107.86 MB and received 185.26 MB.
[notice] Average packaged cell fullness: 30.277%. TLS write overhead: 5%
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Heartbeat: Tor's uptime is 17:59 hours, with 35 circuits open.
I've sent 159.26 MB and received 252.98 MB.
[notice] Average packaged cell fullness: 29.979%. TLS write overhead: 5%
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[[scrubbed].
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.
[notice] Have tried resolving or connecting to address '[scrubbed]' at 3
different places. Giving up.

Any ideas?
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] noise traffic generator?

[Jacki M]

Major features (traffic analysis resistance):
Connections between clients and relays now send a padding cell in each 
direction every 1.5 to 9.5 seconds (tunable via consensus parameters). This 
padding will not resist specialized eavesdroppers, but it should be enough to 
make many ISPs' routine network flow logging less useful in traffic analysis 
against Tor users.

Padding is negotiated using Tor's link protocol, so both relays and clients 
must upgrade for this to take effect. Clients may still send padding despite 
the relay's version by setting ConnectionPadding 1 in torrc, and may disable 
padding by setting ConnectionPadding 0 in torrc. Padding may be minimized for 
mobile users with the torrc option ReducedConnectionPadding. Implements 
Proposal 251 and Section 2 of Proposal 254; closes ticket 16861 
.
Relays will publish 24 hour totals of padding and non-padding cell counts to 
their extra-info descriptors, unless PaddingStatistics 0 is set in torrc. These 
24 hour totals are also rounded to multiples of 1.
Copied for tor-0317-now-released 


> On Oct 6, 2017, at 4:03 PM, Jacki M  wrote:
> 
> TorProject has added some traffic padding in Tor 0.3.1.7 
> 
> And they are working on Adaptive traffic padding 254-padding-negotiation 
> .
> 
>> On Oct 6, 2017, at 12:12 PM, Seth David Schoen > > wrote:
>> 
>> Matej Kovacic writes:
>> 
>>> Hi,
>>> 
>>> there is some interesting project called Noiszy: https://noiszy.com/ 
>>> 
>>> 
>>> It generates fake traffic. It is more "artists" project that real
>>> countermeasure, but I am thinking to implement something like this on my
>>> network with several machines inside.
>>> 
>>> However, the main problem is that Noiszy works too random, and is not
>>> "walking" in websites enough time and enough consistent to give an
>>> impression someone is really browsing something.
>> 
>> There have been a few projects in this space before, like Helen
>> Nissenbaum's TrackMeNot, and at least two others that I'm not thinking
>> of right away.
>> 
>> I agree with your concern that it's currently too easy for an adversary
>> to use statistics to learn if traffic is human activity or synthesized.
>> Another problem is that the sites that the traffic generator interacts
>> with might themselves get suspicious and start responding with CAPTCHAs
>> or something -- which would then also reduce the plausibility of the
>> traffic.
>> 
>> I also wonder if someone has studied higher-order statistics of online
>> activity, in the sense that engaging in one activity affects your
>> likelihood of engaging in another activity afterward (or concurrently).
>> For example, you might receive an e-mail or instant message asking you
>> to look at something on another site, and you might actually do that.
>> On the other hand, some sites are more distracting and less conducive
>> to multitasking than others.  For example, you probably wouldn't be
>> playing a real-time online game while composing an e-mail... but you
>> might play a turn-based game.
>> 
>> There are also kind of complicated probability distributions about events
>> that retain attention.  For instance, if you're doing something that
>> involves low-latency interactions with other people, it's only plausible
>> that you're actually doing that if the other people were also available
>> and interacting with you.  The probability that a given person continues
>> communicating with you declines over time, and is also related to time
>> zone and time of day.  But there's also a probability that someone else
>> starts interacting with you.
>> 
>> Some of these things will probably have to be studied in some depth in
>> order to have a hope of fooling really sophisticated adversaries with
>> synthesized online activity.
>> 
>> -- 
>> Seth Schoen  >
>> Senior Staff Technologist   https://www.eff.org/ 
>> 
>> Electronic Frontier Foundation  https://www.eff.org/join 
>> 
>> 815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
>> -- 
>> tor-talk mailing list - tor-talk@lists.torproject.org 
>> 
>> To unsubscribe or change other settings go to
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk 
>> 
> 

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] noise traffic generator?

[Jacki M]

TorProject has added some traffic padding in Tor 0.3.1.7 

And they are working on Adaptive traffic padding 254-padding-negotiation 
.

> On Oct 6, 2017, at 12:12 PM, Seth David Schoen  wrote:
> 
> Matej Kovacic writes:
> 
>> Hi,
>> 
>> there is some interesting project called Noiszy: https://noiszy.com/
>> 
>> It generates fake traffic. It is more "artists" project that real
>> countermeasure, but I am thinking to implement something like this on my
>> network with several machines inside.
>> 
>> However, the main problem is that Noiszy works too random, and is not
>> "walking" in websites enough time and enough consistent to give an
>> impression someone is really browsing something.
> 
> There have been a few projects in this space before, like Helen
> Nissenbaum's TrackMeNot, and at least two others that I'm not thinking
> of right away.
> 
> I agree with your concern that it's currently too easy for an adversary
> to use statistics to learn if traffic is human activity or synthesized.
> Another problem is that the sites that the traffic generator interacts
> with might themselves get suspicious and start responding with CAPTCHAs
> or something -- which would then also reduce the plausibility of the
> traffic.
> 
> I also wonder if someone has studied higher-order statistics of online
> activity, in the sense that engaging in one activity affects your
> likelihood of engaging in another activity afterward (or concurrently).
> For example, you might receive an e-mail or instant message asking you
> to look at something on another site, and you might actually do that.
> On the other hand, some sites are more distracting and less conducive
> to multitasking than others.  For example, you probably wouldn't be
> playing a real-time online game while composing an e-mail... but you
> might play a turn-based game.
> 
> There are also kind of complicated probability distributions about events
> that retain attention.  For instance, if you're doing something that
> involves low-latency interactions with other people, it's only plausible
> that you're actually doing that if the other people were also available
> and interacting with you.  The probability that a given person continues
> communicating with you declines over time, and is also related to time
> zone and time of day.  But there's also a probability that someone else
> starts interacting with you.
> 
> Some of these things will probably have to be studied in some depth in
> order to have a hope of fooling really sophisticated adversaries with
> synthesized online activity.
> 
> -- 
> Seth Schoen  
> Senior Staff Technologist   https://www.eff.org/
> Electronic Frontier Foundation  https://www.eff.org/join
> 815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
> -- 
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] noise traffic generator?

[Seth David Schoen]

Matej Kovacic writes:

> Hi,
> 
> there is some interesting project called Noiszy: https://noiszy.com/
> 
> It generates fake traffic. It is more "artists" project that real
> countermeasure, but I am thinking to implement something like this on my
> network with several machines inside.
> 
> However, the main problem is that Noiszy works too random, and is not
> "walking" in websites enough time and enough consistent to give an
> impression someone is really browsing something.

There have been a few projects in this space before, like Helen
Nissenbaum's TrackMeNot, and at least two others that I'm not thinking
of right away.

I agree with your concern that it's currently too easy for an adversary
to use statistics to learn if traffic is human activity or synthesized.
Another problem is that the sites that the traffic generator interacts
with might themselves get suspicious and start responding with CAPTCHAs
or something -- which would then also reduce the plausibility of the
traffic.

I also wonder if someone has studied higher-order statistics of online
activity, in the sense that engaging in one activity affects your
likelihood of engaging in another activity afterward (or concurrently).
For example, you might receive an e-mail or instant message asking you
to look at something on another site, and you might actually do that.
On the other hand, some sites are more distracting and less conducive
to multitasking than others.  For example, you probably wouldn't be
playing a real-time online game while composing an e-mail... but you
might play a turn-based game.

There are also kind of complicated probability distributions about events
that retain attention.  For instance, if you're doing something that
involves low-latency interactions with other people, it's only plausible
that you're actually doing that if the other people were also available
and interacting with you.  The probability that a given person continues
communicating with you declines over time, and is also related to time
zone and time of day.  But there's also a probability that someone else
starts interacting with you.

Some of these things will probably have to be studied in some depth in
order to have a hope of fooling really sophisticated adversaries with
synthesized online activity.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] noise traffic generator?

[Matej Kovacic]

Hi,

there is some interesting project called Noiszy: https://noiszy.com/

It generates fake traffic. It is more "artists" project that real
countermeasure, but I am thinking to implement something like this on my
network with several machines inside.

However, the main problem is that Noiszy works too random, and is not
"walking" in websites enough time and enough consistent to give an
impression someone is really browsing something.

For instance, if Noisy just opens a few random sites, this is much
different than if someone will be clicking on some website for some
amount of time, then got to Youtube and watch a couple of movies, than
move on, etc.

So what I am looking for?

1. Something that could be run from bash.

2. Something that would simulate real user, like someone reading news,
someone watching porn, someone browsing Github, etc... Rather that
something generating "accidental clicks" on random websites.

3. This software should have the ability to limit its bandwidth.

Is there any such a software? Can you suggest me something like this?

Regards,

M.
-- 
PGP Fingerprint: 1918 8C72 E5D6 B523 86E1  AC24 C82A C043 3D92 568D
PGP Key:
https://keyserver.ubuntu.com/pks/lookup?op=get=0xC82AC0433D92568D
Personal blog: https://telefoncek.si
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] BridgeDB's Public PGP Key Update Request

[Teruteru]

Hello,

I am unable to use that public key because the PGP public key
(0x8DC43A2848821E32) used by BridgeDB has expired.
Would you please update the expiration date of the key if possible?

Best regards,

--
Teruteru
https://twitter.com/teruteru128



signature.asc
Description: OpenPGP digital signature
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk