Re: [tor-talk] Resource to check if an exit node is considered spammy?

[Geoff Down]

On Sat, Feb 6, 2016, at 09:35 PM, blo...@openmailbox.org wrote:
> Is there a resource that can tell me whether e-mails from the IP of a 
> particular exit node are likely to be flagged by the recipient mail 
> server as spammy.
> 
> I've noticed that sometimes mail gets sent to the spam folder. Sending 
> the very same email from a different exit node goes to the inbox.
 Several sites, e.g. http://www.dnsstuff.com/tools , offer a Spam
 Blacklist Lookup.

-- 
http://www.fastmail.com - Choose from over 50 domains or use your own

-- 
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] Using SDR

[Sean Lynch]

On Fri, Feb 5, 2016 at 7:23 PM coderman  wrote:

> On 2/5/16, Sean Lynch  wrote:
> > ... Radio is being used right now to provide anonymity, but it's being
> used[1]
> > to hide endpoints similar to the duct-taped payphone trick depicted in
> > Hackers, in order to avoid attacks like the one used to capture Ross
> > Ulbricht without giving him a chance to wipe his computer (they snuck up
> > behind him and pinned his arms, but they would have just rushed him had
> > that not been possible). If you use a device like the ProxyHam and you
> sit
> > somewhere where you can see it, there's a reasonable chance you'd spot
> > someone who's trying to find you, giving you a chance to hit your panic
> > button and escape.
>
> this assumes you're keeping it under constant supervision, of course :P
>

Indeed. Having a spotter there is probably the best solution.


> > The older, lower-tech version of this trick is to use a high-gain antenna
> > like the Cantenna or a Yagi to use a public wifi AP from a stealthy,
> > defensible location. The problem with this is that this presents no
> > challenge to RDF (radio direction finding) equipment designed for WiFi.
> > That's the big advantage of the ProxyHam, since whoever is looking for
> you
> > probably won't know in advance what frequency you're using. And solving
> > that problem in a general way requires MUCH more expensive gear than just
> > locating WiFi clients.
>
> one of my favorite tricks, but rather rude in spectrum,
>  is setting high power amplifier to maximum. DF tends to see this
> signal arriving from all around...  *grin*
>
> this introduces it's own trade-offs, of course.
>

This is why you use an attenuator. I wouldn't think law enforcement DF
equipment would be fooled by such a thing, since for example FCC will often
be looking for people who are outputting too much power, which on the ham
bands is going to be multiple kilowatts (I think they've mostly given up on
CB except when it starts interfering with licensed users).


> > It MAY be possible to use SDR to achieve LPI while still remaining within
>
> if you're building LPI, you don't give a fuck about the FCC (compliance).
>  by definition, if they've found you, you fucked up!
>

Perhaps, but I'm not about to suggest that anyone break the law.

> Actually, that gives me an idea: MIMO precoding[2] (versus spatial
> > multiplexing, which is useless for your purposes). MIMO precoding
> devolves
> > to beam-forming in the absence of reflectors like buildings, but in an
> > urban environment, you get a complex combination of signal paths,
> >
> > MIMO precoding requires a "training" phase where they discover one
> another
> > by transmitting some easily "locked-onto" signal so that each receiver
> can
> > find the other transmitter independently.
>
> it is now possible for a professional's budget to accodomate the SDR
> equipment necessary to do this type of phase sync'ed active beam
> forming MIMO transmission, and not all methods require the training
> phase. in fact, omission of this (by out of band training, in a sense)
> in a method of "keying" phased delivery of UWB MIMO in a way more
> likely to achieve LPI.
>

How do you train out of band? By modelling the environment? That's an
interesting thought, and I suspect Google Earth has enough data to be able
to do it in a lot of places. Are you aware of free or inexpensive software
packages for doing this?


> synthetic aperature millimeter wave vision systems are also pushing
> along this boundary, for cross-pollination of suitable phased sync'ed
> UWB MIMO signal processing.
>

Aren't you just talking phased array for something like this though? Or do
you mean using phase information from the receive antennas to reconstruct
the environment rather than using phasing at the transmit side to steer
your beam? That's a very interesting idea since it can give you a 360
degree view with no need to steer your beam, in the same way that some
blind humans can use clicks to get a picture of their entire environment.
(I use humans and not bats because I think bat sonar is pretty directional,
whereas human ears can localize sound quite precisely without any need to
turn one's head.)


> i could go on, if you're curious, but perhaps on another list? :)
>

This is definitely an area I'm interested in, so I'd love to hear more of
your ideas, as may Jeremy, so if it's beyond what is generally tolerated on
this list, private email would be fine, or if you have a list in mind I'd
be happy to subscribe if I'm not already.
-- 
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] Why does Facebook claim my Russian exit node is in Colombia?

[Sean Lynch]

Geolocation data for IPs is of varying quality. Facebook's likely comes
from a combination of commercial and open/free sources, along with some
machine learning based on features of people coming from those IPs. For the
most part, I doubt Facebook is trying to look at/parse the whois data
directly, since often the address of the owner of a block has nothing to do
with the actual location of a block.

On Tue, Feb 2, 2016 at 3:28 PM  wrote:

> Can someone please explain why services like Facebook and Gmail are so
> wrong when they attempt to geo-locate exit nodes.
>
> As an example, I set ExitNodes to {ru} and logged into my Facebook. This
> locked my account. When I logged in Facebook told me there was a
> suspicious login. It claimed the IP address of the exit node in Russia
> resolved to Colombia! I checked the IP address with WHOIS - it's in
> Russia.
>
> Can anyone tell me why exit nodes are frequently placed in a totally
> wrong location by companies like Facebook which must have complex
> algorithms to detect where their customers are from.
>
> Is it something to do with the exit node as I can't imagine how Facebook
> could get it so wrong.
> --
> 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

[tor-talk] Resource to check if an exit node is considered spammy?

[blobby]

Is there a resource that can tell me whether e-mails from the IP of a 
particular exit node are likely to be flagged by the recipient mail 
server as spammy.


I've noticed that sometimes mail gets sent to the spam folder. Sending 
the very same email from a different exit node goes to the inbox.

--
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] [Tails-dev] Persistent Tor start in Tails vs location aware Tor entry guards (LATEG)

[intrigeri]

Hi,

[can you please decide what mailing-list this discussion should happen
on, and then we can stop cross-posting over 4 mailing-list?]

Patrick Schleizer wrote (02 Jan 2016 22:36:13 GMT) :
> But I think location aware Tor entry guards (LATEG) are wrong headed.
> The topic of LATEG is so difficult to explain to the user, that as you
> plan, you cannot add it the the UI. Perhaps buried under an advanced
> setting, but that's not worth so much. So it cannot be manual by
> default. Only automatic.

I agree.

> Which brings me to the issue.

> There is a reason, why Tor picks a Tor entry guard and sticks to it. By
> changing it more often than Tor would do, you are subverting the reason
> for using Tor entry guards in the first place. In a sense, you are to a
> small degree thereby becoming a Tor developer, and modifying Tor's relay
> choosing algorithm.

I think I see what you mean, and indeed it's the kind of things about
which my self-confidence is pretty low, and I'd personally rather
avoid fiddling with things I don't understand.

But the thing is: by using random guards every time Tails starts, we
are _already_ making the very same kind of decisions. Only, we are
making it very badly, and this has been going on for too many years
already.

Let's face it: as distro integrators, in the current state of things,
we have to make a decision to compensate for the fact that Tor's guard
selection wasn't designed with our threat model in mind.
Keeping things as-is would be a decision. Using fully persistent entry
guards (not location aware), like Tor Browser users get currently,
would be another decision. We cannot escape it, so we're trying to
make this decision in a way that's much better for the vast majority
of Tails users.

> I wonder, if the whole LATEG thing would not be much better implemented
> in Tor itself. If so, then any (further) research of the entry guard
> topic would still apply to Tails, and not to Tor only.

With my (lazy by design) distro integrator's hat, I can only agree:
the more work is done by little-t-tor, the less I have to deal with
myself, and the more is shared cross-distro. Yay.

However, taking a step back, I'm not sure it makes a whole lot of
sense: to be location-aware, tor would have to gain knowledge about
new concepts, and interface with OS services, that it can currently
happily ignore so far; add to this that tor is multi-platform;
I expect it's not an easy problem to deal with at this specific place,
but again: if someone solves it, I certainly won't complain :)

> The documentation advice for advanced users caring about AdvGoalTracking
> could be to use obfuscated [private] bridges and to alternate
> them per travel location.

Right, I think it's important that people who what more control can
get it this way, and IIRC our current best proposal does not prevent
anyone from doing this.

> Or perhaps you might be able to explain in tor-launcher /
> anon-connection-wizard [1] [2] [3] the LATEG / AdvGoalTracking issue.

If the configuration GUI has good facilities to document a broad and
complex problem, yay, bringing the doc closer to the software is
probably a winning strategy.

>> [...] By adding the SSID, we prevent attackers from being able to
>> spoof only the MAC address of the router to reuse a given Tor state;
>> they also have to spoof the SSID which is visible to the user and might
>> be detected as malicious. [...]

> I find it unlikely, that users might judge an often changing SSID
> malicious. FreeWifi832458252823523 vs FreeWifi358235892435. How many
> users are going to remember that? I would guess, they would just click
> through whatever hoops required to make the WiFi connect again.

I have no time/energy to think seriouly about it now, and I've been
postponing my reply for a month due to this, so I'll try to be
pragmatic: I'm adding this as a FIXME on our blueprint, and will come
back to it later.

I'm not sure I understand the problem you mean to raise, though.
Can you please elaborate what problem you see if users do exactly this
("click through whatever hoops required to make the WiFi connect
again", which I agree is very likely)?

Thanks!

Cheers,
-- 
intrigeri
-- 
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] Using SDR

[Sean Lynch]

On Fri, Feb 5, 2016 at 10:36 PM jim bell  wrote:

>
>
> *From:* coderman 
> *Sbject:* Re: [tor-talk] Using SDR
> On 2/5/16, Sean Lynch  wrote:
> > The older, lower-tech version of this trick is to use a high-gain antenna
> > like the Cantenna or a Yagi to use a public wifi AP from a stealthy,
>
> Initially, I was confused about this.  To me, a "Cantenna" was Heathkit's
> name (in about 1970 or so) for a dummy-load built from a
> 1 gallon paint can with a non-inductive resistor inside, immersed in
> transformer oil, capable of dissipating 1 Kw or so.
> Showing my age.
> Now, on Google-search, I see it as an antenna built with a tin can.
>
>
Sorry about that. I had initially considered including a reference, but I
figured it was an easily Googlable term. Name collisions hadn't occurred to
me. My radio knowledge is a mix of modern Ham education and 1950s era Ham
education, the latter because those were the books my tiny middle school
had in its library :)
-- 
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] TB 5.5 for OpenBSD

[George]

On 02/06/16 10:14, flipc...@riseup.net wrote:
> Great! i will check it out
> 

Thanks. Let us know if you have any comments or questions offline or via
GitHub.

Note that the Tor Project's update to 5.5.1 is mostly irrelevant for
OpenBSD users.

g



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

[tor-talk] automatic Tor browser updates

[Mirimir]

When automatically updating, does Tor browser check GPG signatures of
downloaded updates before installing them?
-- 
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] OT: Bitmessage

[grarpamp]

On Sat, Jan 30, 2016 at 6:14 AM, Tom A.  wrote:
> Yes take care and look yourself or believe so called experts or
> multiplicators.

Fine example of the classic passive shilling for GoldBug / BitMail, etc.

> I agree that all closed source crypto is obsolete.

Yeah, so is all the non-reproducible binaries of opensource code
above, deleting critiques off your own forums, etc... ahem.

>> Also, since Tom spammed a link to BitMail, it's worth noting that
>> BitMail appears to be developed by the same people who made GoldBug.
>> For those of you keeping score at home, GoldBug falsely claimed to be
>> a project of EFF and CCC.  It would be wise to assume that BitMail is
>> malware or backdoored unless proven otherwise.

Tom's long been associated with their little game.
Search the whole scam out on tor-talk, cpunks, google, etc.

Till y'all step up to the plate... hasta Asta.
-- 
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] TB 5.5 for OpenBSD

[flipchan]

Great! i will check it out

On 2016-02-05 21:38, George wrote:

The Tor BSD Diversity Project just released Tor Browser version 5.5 for
OpenBSD/amd64. For those interested in running it, you need a very
recent -current (snapshot) of OpenBSD/amd64.

Here's the official announce:

TDP Announce for Tor Browser 5.5 for OpenBSD
20160205
The Tor BSD Diversity Project
https://torbsd.github.io/

The Tor BSD Diversity Project (TDP) is proud to announce the release of
Tor Browser (TB) version 5.5 for OpenBSD. Please note that this version
of TB remains in development mode, and is not meant to ensure strong
privacy, anonymity or security.

TDP (https://torbsd.github.io) is an effort to extend the use of the 
BSD

Unixes into the Tor ecosystem, from the desktop to the network.

The 5.5 version is the eighth Tor Browser release from TDP.

To install TB for OpenBSD, please see
http://mirrors.nycbug.org/pub/snapshots/packages/amd64/README-55.txt

TDP is focused on diversifying the Tor network, with TB being the
flagship project. Additional efforts are made to increase the number of
*BSD relays on the Tor network among other sub-projects.

TDP's source code repository resides at http://github.com/torbsd/

TDP is seeking funding to continue and extend its efforts. Please
contact us if interested in assisting TDP, allowing us to dedicate more
time to the project.


--
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