|
Home > Archive > Anonymous Servers > June 2007 > OmniMix v.1.2.2 Uno - Anon Mail S - additional Hosts and settings?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
OmniMix v.1.2.2 Uno - Anon Mail S - additional Hosts and settings?
|
|
| Nomen Nescio 2007-06-18, 7:13 pm |
| In OmniMix v.1.2.2 Uno, under the 'Anon Mail S' tab, the default host is
listed as 'mail.bananasplit.info' on Port 2525, with a remailer name of
'banana'.
Are there other entries that can be put into this tab? If so, how do we
figure out what the host, port and remailer name of these are?
As a feature request, if there are additional servers that can be used on
that tab, can I request that the OmniMix author create the same sort of
interface as is on the 'Anon' tab, under Remailer >> News, and Remailer >>
Mail (the '...' buttons), including a '0' (random) option?
Thanks
| |
| Jules Striker 2007-06-18, 7:13 pm |
| To Christian:
Why not make a simple to use install, similar to QS, for the benefit of all of
us who are not as computer-savvy as you?
TIA
On Mon, 18 Jun 2007 22:40:02 +0200 (CEST), Nomen Nescio <nobody@dizum.com>
wrote:
>In OmniMix v.1.2.2 Uno, under the 'Anon Mail S' tab, the default host is
>listed as 'mail.bananasplit.info' on Port 2525, with a remailer name of
>'banana'.
>Are there other entries that can be put into this tab? If so, how do we
>figure out what the host, port and remailer name of these are?
>As a feature request, if there are additional servers that can be used on
>that tab, can I request that the OmniMix author create the same sort of
>interface as is on the 'Anon' tab, under Remailer >> News, and Remailer >>
>Mail (the '...' buttons), including a '0' (random) option?
>Thanks
| |
| Christian Danner 2007-06-19, 7:14 am |
| Hi Jules!
Jules Striker wrote:
>Why not make a simple to use install, similar to QS, for the benefit of all of
>us who are not as computer-savvy as you?
Are you aware that meanwhile the complete OmniMix system (including
Mixmaster, GnuPG and Tor) is shipped in the form of a single setup
file?
With a double click and 10 single mouse clicks you're able to install
the whole system. 7 further clicks and your first dummy mail is sent:
- 'Use 'Anon Mail S Host'' checkbox to bypass the mail host config
- 'Start' button to restart the servers with that changed parameter
- 'State Ext' tab
- 'Update State Data' button to get current remailer statistics
- 'Misc' tab
- 'Dummy' tab
- 'Send Dummy Message' button to test the anon mail output
Of course an individual configuration is a bit more complex.
Or do you have something different on your mind?
Kind regards
Christian
--
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
| |
| Christian Danner 2007-06-19, 7:14 am |
| Hi!
>In OmniMix v.1.2.2 Uno, under the 'Anon Mail S' tab, the default host is
>listed as 'mail.bananasplit.info' on Port 2525, with a remailer name of
>'banana'.
The bananasplit mail host like all other remailer associated SMTP
hosts is restricted to delivering mail to nothing but its own
remailer, which is why OmniMix is able to modify the remailer chain
accordingly.
>Are there other entries that can be put into this tab? If so, how do we
>figure out what the host, port and remailer name of these are?
Of course there are other options. http://www.noreply.org/tls lists
the access data of remailer related SMTP servers. But be prepared, at
first sight it's a bit confusing.
>As a feature request, if there are additional servers that can be used on
>that tab, can I request that the OmniMix author create the same sort of
>interface as is on the 'Anon' tab, under Remailer >> News, and Remailer >>
>Mail (the '...' buttons), including a '0' (random) option?
As the data provided by Noreply not always guarantee a reliable
connection, you still have to do some testing on your own, which is
why an automated parsing of that list done by OmniMix or, going beyond
that, a random selection of the SMTP server would be no good. Besides,
you may be interested in using hidden services as well, so that you
have to make sure that Tor is running, which takes a few seconds to be
available after starting it. To sum it up, such an automatism would
jeopardize reliability.
The question is what you're trying to accomplish. There usually is no
reason for a frequent alteration of the entry point. One reliable
gateway is sufficient, the access data of a second one at hand for
backup reasons. If you need more security then route the connection
through Tor or simply add another ramdom remailer.
The only way to make the manual switching between (anon) SMTP hosts
more comfortable would be an additional list like the User Account or
Hashcash list including all items of the '(Anon) Mail S' tab. But
that's already on my to-do list. I'm not sure whether this will be
realized before or after the migration to a data storage in XML
format.
Kind regards
Christian
--
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
| |
| Borked Pseudo Mailed 2007-06-19, 7:14 am |
| In article <1b9773e95aeae1a5467fdcc36ee47635@pseudo.borked.net>
Christian Danner <---@---.---> wrote:
>
Hi Christian. Every post made with Omnimix results in:
X-Invalid: ##
being in the headers of the post or email. This unfortunately
partitions all users of Omnimix from users of the more popular
QS and JBN2 users. As anonymity in the remailer network relies
on hiding amongst other users, anything that reduces the amount
of users to hide in isn't good.
Can you remove this? Its in the headers of every poster in here
that uses Omnimix, and your posts too. As there is no source code
I can't see exactly why its happening, but I am assuming that you
aren't using the '##' body headers syntax properly and are instead
adding it in the headers instead of the body?
Sorry for my bad english.
| |
| Christian Danner 2007-06-19, 1:14 pm |
| Hi!
>Hi Christian. Every post made with Omnimix results in:
>X-Invalid: ##
>being in the headers of the post or email. This unfortunately
>partitions all users of Omnimix from users of the more popular
>QS and JBN2 users. As anonymity in the remailer network relies
>on hiding amongst other users, anything that reduces the amount
>of users to hide in isn't good.
Good heavens! You're absolutely right. Many thanks for that important
hint.
>Can you remove this? Its in the headers of every poster in here
>that uses Omnimix, and your posts too.
AFAICS it began with version 0.9.8.0, where I changed from Mixmaster
2.0 to 2.9. I'm not aware of any different syntax requirement or
tolerance of irregularities, but will look what can be done. As a
first step with this message I removed the introducing '##' line
without replacement.
> As there is no source code
>I can't see exactly why its happening, but I am assuming that you
>aren't using the '##' body headers syntax properly and are instead
>adding it in the headers instead of the body?
Nothing mysterious. The 'Log' list tells you the parameters of the
Mixmaster call:
14:10:59.686 0 Calling Mixmaster (parameters: ' -m -c 4 -l
banana,*,*,borked om\0.mxt') ...
which means
mix.exe -m -c 4 -l banana,*,*,borked om\0.mxt
and the 'Raw Data' list shows the text transferred with the message
file 0.mxt:
------------------------------------------------------------
##
From: Christian Danner <---@---.--->
To: mail2news@dizum.com, mail2news@m2n.mixmin.net
Newsgroups: alt.privacy.anon-server
References: <782dff81b0e640b236b915e4e94b98a3@dizum.com>
<p9td73t6vqoook7hqvhmeu31hvha1ceon5@4ax.com>
<1b9773e95aeae1a5467fdcc36ee47635@pseudo.borked.net>
<f2d763cdbaa186a29f17a58a61d64212@pseudo.borked.net>
Subject: Re: OmniMix v.1.2.2 Uno - Anon Mail S - additional Hosts and
settings?
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi!
>Hi Christian. Every post made with Omnimix results in:
<snip>
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
..
------------------------------------------------------------
>Sorry for my bad english.
As we all non-natives are about our command of English. ;-)
Kind regards
Christian
--
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
| |
| George Orwell 2007-06-19, 1:14 pm |
| Christian Danner wrote:
> The question is what you're trying to accomplish. There usually is no
> reason for a frequent alteration of the entry point. One reliable
> gateway is sufficient, the access data of a second one at hand for
Nonsense. Mixmaster is designed to use random entry points for a reason,
and restricting your entry node to a single remailer completely defeats
it. It opens you up to easy traffic analysis.
| |
|
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Tue, 19 Jun 2007 16:45:09 +0200 (CEST), George Orwell wrote in
Message-Id: < a38d060904c1f23c6068ec2956c9dc91@mixmast
er.it>:
> Nonsense. Mixmaster is designed to use random entry points for a reason,
> and restricting your entry node to a single remailer completely defeats
> it. It opens you up to easy traffic analysis.
Interesting. Can you expand on this please?
As Mixmaster traffic is easily identified, it would appear not to matter
whether you send it to one remailer or many. Hardcoding the exit could
potentially reveal information, but I don't see how the entry does.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGd/ lwlKZ6CY7Vd0MRCsTsAKD+0k4xCsQM85HUKKZs7n
OZIC9VeQCfXFxl
6iQF0zM3RDaCYf7FGRRic4Y=
=vHkk
-----END PGP SIGNATURE-----
--
pub 1024D/8ED57743 2003-07-08 Bananasplit Operator
Key fingerprint = 796F 67E0 E890 A0BB BDAE EBB4 94A6 7A09 8ED5 7743
uid Admin <admin.bananasplit.info>
| |
| George Orwell 2007-06-19, 1:15 pm |
| Zax wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Tue, 19 Jun 2007 16:45:09 +0200 (CEST), George Orwell wrote in
> Message-Id: < a38d060904c1f23c6068ec2956c9dc91@mixmast
er.it>:
>
>
> Interesting. Can you expand on this please?
> As Mixmaster traffic is easily identified, it would appear not to matter
> whether you send it to one remailer or many. Hardcoding the exit could
> potentially reveal information, but I don't see how the entry does.
If you're hard coding a consistent entry node that node knows about all
traffic you're sending. Assuming they're able to see exit traffic,
such as posts to a newsgroup, that node can collate the number and times
of messages with the the number and times that posts reach Usenet. That
alone could be enough to out users under some circumstances, and combined
with some of the other things that partition you like SMTP negotiations,
header order, different "features" of various clients, etc., the chances
that a remailer operator could divine your real identity increase
dramatically.
It may not work so well with privately delivered messages, but how could
hard coding a "permanent" entry node not be considered diminished
security in any case? Obfuscating and spreading knowledge of your activity
is tantamount to Mixmaster's design. Not only are random entry points
chosen to keep one operator from knowing about all traffic, if you use
multiple chains with the 'copies' directive a random selection is used for
each message, which further obfuscates activity by effectively making the
message that appears at the other end even more random in nature as far as
latency and traffic analysis goes.
Knowledge of injected traffic absolutely is valuable. It's the reason
random node selection and dummy traffic generation exist. Or would you
suggest that these things are themselves nothing but the random whims of
Mixmaster's developers? ;-)
| |
|
| On Tue, 19 Jun 2007 19:31:09 +0200 (CEST), George Orwell wrote in
Message-Id: < 0693262209894b2d871236a8ccc848a0@mixmast
er.it>:
> If you're hard coding a consistent entry node that node knows about all
> traffic you're sending.
I see your point. Rather than just seeing some entry traffic, the entry
node now knows all of it. In effect the operator has the ability to
correlate entry traffic with a common destination such as a.a.m.
Conversely, from the point of view of the theoretical 'Global
Adversary', it makes little difference as we assume they can see all
this traffic anyway.
> Knowledge of injected traffic absolutely is valuable. It's the reason
> random node selection and dummy traffic generation exist. Or would you
> suggest that these things are themselves nothing but the random whims of
> Mixmaster's developers? ;-)
No, I agree with you, random entry points are a good thing. Sometimes I
think we lean too far towards theoretical attacks and global adversaries
and don't focus enough on the simple things like snooping operators (of
one or multiple remailers). I still think the best defence in virtually
all cases is to run your own public remailer node. This is the instance
where hard-coding the entry point is certainly a good thing. 
--
pub 1024D/8ED57743 2003-07-08 Bananasplit Operator
Key fingerprint = 796F 67E0 E890 A0BB BDAE EBB4 94A6 7A09 8ED5 7743
uid Admin <admin.bananasplit.info>
| |
| Christian Danner 2007-06-19, 7:13 pm |
| George Orwell wrote:
>Christian Danner wrote:
>
>
>Nonsense. Mixmaster is designed to use random entry points for a reason,
What reason? Please be more explicit. And explain why it is also
designed to allow the definition of a single entry remailer for all
chunks if it's all that bad.
>and restricting your entry node to a single remailer completely defeats
>it. It opens you up to easy traffic analysis.
Do you really believe you're able to confuse anyone by selecting entry
remailers on a random basis?
First of all, before your messages come up at random entry remailers
they still have to go through one single MUA or MTA. So if those
capable of performing traffic analyses are after you, by observing one
of your remailer related SMTP servers they get knowledge of the
sender's ip address, which leads to all other remailer connections, no
matter whether the starting point of your messages is Mixmaster
itself, your local Sendmail/ Postfix MTA, OmniMix, your ISP's SMTP
host or whatever. From the traffic analysis POV it may even be
advantageous to send all chunks through an encrypted connection to a
single remailer in order to make it (slightly) more difficult for an
adversary who doesn't have direct access to the SMTP server to figure
out the number of copies you put on their way.
That's why your strategy has to be a different one as long as you
attain to get some kind of anonymity already at the entry remailer
level:
- Use a separate Tor instance to communicate with the remailer's SMTP
server
- Change your Tor exit node periodically
- Send random copies of dummy messages in random intervals
all of which the OmniMix system is capable of without any user
intervention.
Best would be to send each chunk at a different time through a
different Tor exit to a different SMTP server ... I regret, Mission
Impossible for a proxy server that has to stay connected with the
client until the work is done.
BTW, I'll announce when OmniMix v1.2.3 with a fix of that nasty
'X-Invalid: ##' bug is available. It seems to be cured now.
Regards
Christian
--
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
| |
| Cyberiade.it Anonymous Remailer 2007-06-19, 7:13 pm |
| Zax wrote:
> On Tue, 19 Jun 2007 19:31:09 +0200 (CEST), George Orwell wrote in
> Message-Id: < 0693262209894b2d871236a8ccc848a0@mixmast
er.it>:
>
>
> I see your point. Rather than just seeing some entry traffic, the entry
> node now knows all of it. In effect the operator has the ability to
> correlate entry traffic with a common destination such as a.a.m.
> Conversely, from the point of view of the theoretical 'Global
> Adversary', it makes little difference as we assume they can see all
> this traffic anyway.
I agree, however what this does in effect is make a "Global Adversary" out
of a single remailer operator. Attacking users no longer requires the
ability to monitor a broad number of points or connections any more,
assuming of course you're going after posts/messages sent through the
remailer network to "common areas" like Usenet. I'd wager this is a pretty
large percentage of remailer traffic, possibly the majority.
It doesn't seem like it would be to much of a problem to peruse Google
data regarding where mail is going, in fact they make it a one click deal
to get a profile for a single remailer. At the very least you could
quickly glean statistics about which groups get the most remailer traffic
and monitor those groups from any server. If you're privy to all the
traffic being sent by some number of users I don't think it would take too
long at all to start putting at least some messages and senders together.
The obvious solution from my point of view is to design client software
that rotated direct submission of mail among the various remailers that
accept it. I understand, though, that the list at Noreply is sometimes
inaccurate. I'd imagine it's difficult to actually maintain such a list
with any detail.
Tor is of course useful in this context too, but from my experience even
making connections to nonstandard ports is hit and miss. It seems there's
an ever growing number of exit nodes white listing very narrow port
ranges. Perhaps if remailer operators could agree on some sort of
"standard" port in the 8000 range to configure as an SMTP listener...?? It
would certainly make writing software that rotated among servers a lot
easier to write. It would be pretty easy to code some sort of "fall back"
scheme if a programmer had a list of known nodes that accepted mail
directly, and a single port to play with.
Just some thoughts.
>
> No, I agree with you, random entry points are a good thing. Sometimes I
> think we lean too far towards theoretical attacks and global adversaries
> and don't focus enough on the simple things like snooping operators (of
Snooping operators shouldn't be much of a problem as long as they're
not allowed to run multiple nodes surreptitiously, and the remailer
network is used properly (not hard coding chains, a little dummy traffic,
etc.). That's not to say evil operators should be tolerated when they're
discovered mind you, just that the software is designed to make their
lives "difficult". I would say users hard coding entry/exit nodes is a
bigger problem overall.
> one or multiple remailers). I still think the best defence in virtually
> all cases is to run your own public remailer node. This is the instance
> where hard-coding the entry point is certainly a good thing.
Absolutely, however it's probably beyond the means of most users to run a
remailer. Both technically, and as a matter of practicality because of
things like asynchronous connections with pitiful upload bandwidth and
provider Terms Of Service agreements.
| |
| Borked Pseudo Mailed 2007-06-19, 7:13 pm |
| Christian Danner wrote:
> George Orwell wrote:
>
>
> What reason? Please be more explicit. And explain why it is also
> designed to allow the definition of a single entry remailer for all
> chunks if it's all that bad.
Mixmaster isn't designed to allow all your mail to be sent to a single
entry node Christian, any more than it's designed to allow you to send
mail with your name, address, and phone number in it. It's designed to
allow users to select specific remailers and build custom chains. That
feature can be abused just like the "feature" that doesn't scan message
text for phone numbers can.
>
> Do you really believe you're able to confuse anyone by selecting entry
> remailers on a random basis?
Of course you can. Spreading that information out among the widest
possible range of nodes is the reason Mixmaster chooses random entry
nodes. That, is what it's "designed to do".
> First of all, before your messages come up at random entry remailers
> they still have to go through one single MUA or MTA. So if those
No, it doesn't. I routinely send mail through a number off different
servers. And even if your "single server" theory were true, it's irrelevant
unless you both subscribe to the idea that one weakness justifies another,
and discard the possibility that a remailer entry node is an even more
ideal place from which to observe traffic than an ISP. The latter
assumption especially, is a false one. Remailer operators not only don't
need warrants to observe traffic, they're in a position of seeing a lot
more traffic of that type.
> capable of performing traffic analyses are after you, by observing one
> of your remailer related SMTP servers they get knowledge of the
> sender's ip address, which leads to all other remailer connections, no
> matter whether the starting point of your messages is Mixmaster
> itself, your local Sendmail/ Postfix MTA, OmniMix, your ISP's SMTP
This is all true, but it doesn't change a thing. You're trying to argue
that because there might be one point of weakness it's OK to ignore
another. That just doesn't make any sense.
I submit that it's far less secure to allow a single remailer operator to
have access to all your traffic, than it is to let your ISP know where
you're sending remailer messages, because a remailer is an easier target
to compromise. It's also much easier for a remailer operator to add or
subtract latency to mail based on submitting IP address than it is for an
ISP to do the same. In fact, if a remailer operator held up a series of
messages for 24 hours and observed public forums for threading of messages
they could probably identify the sender with 100% accuracy. Always sending
yoru mail through a single entry node makes this sort of attack child's
play. All your randomly selected chains and exit nodes are worthless at
that point, because the entry node has the ability to do away with any
benefit individual latency and randomness brings to the table.
> host or whatever. From the traffic analysis POV it may even be
> advantageous to send all chunks through an encrypted connection to a
> single remailer in order to make it (slightly) more difficult for an
> adversary who doesn't have direct access to the SMTP server to figure
> out the number of copies you put on their way.
It may make it (slightly) more difficult for an adversary to monitor en
route, but it makes your traffic (highly) vulnerable to being monitored
at the entry node. All of it. Not just an occasional message or a copy of
a message as multiple chains are built with identical exit AND entry
nodes, but every single message and every copy of them.
The multiple chains are where you take a real hit, because under normal
operations Mixmaster builds multiple chains with randomly selected entry
nodes for each copy. This is a distinct advantage not only against evil
remailer operators, but evil ISP's. That design feature certainly does
"confuse" attackers because they have multiple channels to monitor, and
the messages themselves could have come from any of them when they've
reached the other end. There's no way to tell.
> That's why your strategy has to be a different one as long as you
> attain to get some kind of anonymity already at the entry remailer
> level:
The strategy is to use as many entry nodes as possible, in a random
fashion. That's how the software was designed. The fact that you can
force it to do something less secure isn't justification for doing it.
> - Use a separate Tor instance to communicate with the remailer's SMTP
> server
> - Change your Tor exit node periodically
> - Send random copies of dummy messages in random intervals
Those are all good practices.
They still don't justify using other less secure methods, even in
conjunction with them.
> all of which the OmniMix system is capable of without any user
> intervention.
It also, apparently, restricts itself to a single entry nodes SMTP
submission (I don't use it). That creates a point of attack that might
even transcend Tor's ability to provide anonymity due to the fact that Tor
is real time and more or less ineffective against traffic analysis at this
level.
> Best would be to send each chunk at a different time through a
> different Tor exit to a different SMTP server ... I regret, Mission
> Impossible for a proxy server that has to stay connected with the
> client until the work is done.
Actually it would be sufficient to simply rotate among entry nodes that
accepted mail directly just like Mixmaster itself rotates entry nodes when
used "normally". Last I checked there's a handful of remailers that allow
direct submission, so it should be easy to build the same sort of
randomized multiple copies like Mixmaster does.
| |
| drsnoid@remailer.metacolo.com 2007-06-20, 1:14 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article < ba30b3b87c051cfee3ac005a50ac135a@remaile
r.cyberiade.it>
Cyberiade.it Anonymous Remailer <anonymous@remailer.cyberiade.it> wrote:
>
> Zax wrote:
>
>
> I agree, however what this does in effect is make a "Global Adversary" out
> of a single remailer operator. Attacking users no longer requires the
> ability to monitor a broad number of points or connections any more,
> assuming of course you're going after posts/messages sent through the
> remailer network to "common areas" like Usenet. I'd wager this is a pretty
> large percentage of remailer traffic, possibly the majority.
>
> It doesn't seem like it would be to much of a problem to peruse Google
> data regarding where mail is going, in fact they make it a one click deal
> to get a profile for a single remailer. At the very least you could
> quickly glean statistics about which groups get the most remailer traffic
> and monitor those groups from any server. If you're privy to all the
> traffic being sent by some number of users I don't think it would take too
> long at all to start putting at least some messages and senders together.
>
> The obvious solution from my point of view is to design client software
> that rotated direct submission of mail among the various remailers that
> accept it. I understand, though, that the list at Noreply is sometimes
> inaccurate. I'd imagine it's difficult to actually maintain such a list
> with any detail.
>
> Tor is of course useful in this context too, but from my experience even
> making connections to nonstandard ports is hit and miss. It seems there's
> an ever growing number of exit nodes white listing very narrow port
> ranges. Perhaps if remailer operators could agree on some sort of
> "standard" port in the 8000 range to configure as an SMTP listener...?? It
> would certainly make writing software that rotated among servers a lot
> easier to write. It would be pretty easy to code some sort of "fall back"
> scheme if a programmer had a list of known nodes that accepted mail
> directly, and a single port to play with.
<spam>
Hi,
My kludgey add-on for Quicksilver use does some of these things. It's a
snap to use once you figure out what it's doing and modify its txt files to
reflect current conditions and personal desires.
http://drsnoid.cotse.net/gatepick2/gatepick2.htm
Its best use is with QS 1.4b24.
First, you create and save a template (with Tor as the drop-down proxy)
similar to this:
Fcc: outbox
Paste
your
shit
here
Newsgroups:
Subject:
The you need to get Sockscap (or Freecap if you can beat it into working)
and add stunnel to it. Your stunnel conf could be something like
[BANANA_SMTP]
accept = 123
connect = fleegle.mixmin.net:465
delay = no
[PANTA_SMTP]
accept = 124
connect = remailer-debian.panta-rhei.eu.org:465
delay = no
[CSIDE_SMTP]
accept = 125
connect = cside.dyndns.org:465
delay = no
[DIZUM_SMTP]
accept = 126
connect = smtp.zedz.net:465
delay = no
[CRIPTO_SMTP]
accept = 127
connect = mail.ecn.org:465
delay = no
[ANON_SMTP]
accept = 128
connect = osiris.978.org:465
delay = no
[CYBERIAD_SMTP]
accept = 129
connect = mail.cyberiade.it:465
delay = no
[GEORGE_SMTP]
accept = 130
connect = mail.mixmaster.it:465
delay = no
[FRELL_SMTP]
accept = 131
connect = mail2.frell.eu.org:465
delay = no
It is necessary to visit noreply tls every once in awhile to keep you list
fresh!
Then for gatepick2's hosts.txt file, you have made these entries:
127.0.0.1:123 > banana
127.0.0.1:124 > panta
127.0.0.1:125 > cside
127.0.0.1:126 > dizum
127.0.0.1:127 > cripto
127.0.0.1:128 > anon
127.0.0.1:129 > cyberiad
127.0.0.1:130 > george
127.0.0.1:131 > frell
So then when you go to use QS and gatepick2, you start Sockscap & stunnel
via Sockscap, open your QS template, start gatepick2 and get rid of the bad
routes (gatepick is kind of Usenet specific but there's no reason it can't
be used for email) and paste gatepick's output over the obvious section of
your template:
Fcc: outbox
Host: 127.0.0.1:128
From: wpnfdval@example.com
Chain: anon,*,*,banana; copies=4
To: mail2news@dizum.com
Newsgroups:
Subject:
A subsequent click might give you the result
Fcc: outbox
Host: 127.0.0.1:126
From: mvdnv@google.com
Chain: dizum,*,*,dizum; copies=2
To: mail2news@m2n.mixmin.net
Newsgroups:
Subject:
etc.
It takes a wee bit of maintenance but you have exactly what you're wanting -
Tor, tls, random smtp entry points, random final remailer and random
mail2news - with just a little bit of hassel.
</spam>
Personally I don't have any difficulty using Tor with ports 465 and 2525,
just wish more remailers offered them. 587's pretty dicey and obviously 25
you can use succesfully only once in a blue moon. I really like your idea
of remailers agreeing upon and opening some weird port strictly for direct
submission via Tor. The more the merrier.
drsnoid
-----BEGIN PGP SIGNATURE-----
Version: N/A
iQA/ AwUBRnhcYpc5FWApPF04EQKwmwCgjvsbtYpbowb9
MhBJLdomV1AXbVUAoMbR
3gl6EXDxE0ATQQl4AILuAXwq
=R/XZ
-----END PGP SIGNATURE-----
| |
| drsnoid 2007-06-20, 1:14 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article < b1f99cccd1b0df4043941cbe535f222a@remaile
r.metacolo.com>
drsnoid@remailer.metacolo.com wrote:
<spam>
> Hi,
> My kludgey add-on for Quicksilver use does some of these things. It's a
> snap to use once you figure out what it's doing and modify its txt files to
> reflect current conditions and personal desires.
> http://drsnoid.cotse.net/gatepick2/gatepick2.htm
> Its best use is with QS 1.4b24.
>
> First, you create and save a template (with Tor as the drop-down proxy)
> similar to this:
>
> Fcc: outbox
> Paste
> your
> shit
> here
> Newsgroups:
> Subject:
As usual, after reading my post I noticed an error. With this template do
NOT choose Tor as a proxy, for Sockscap set up for Tor will be handling
this for you. Choose "No Proxy" for this application.
drsnoid
-----BEGIN PGP SIGNATURE-----
Version: N/A
iQA/ AwUBRniCR5c5FWApPF04EQJgFgCgqQ5skYSP+ifX
DVtXcdg2tTuogs8An1oM
Bvmgz7ae6+T8fhv+w5ANoG2Y
=IoDt
-----END PGP SIGNATURE-----
~~~~~~~~~~~~~~~~~~~~~
This message was posted via one or more anonymous remailing services.
The original sender is unknown. Any address shown in the From header
is unverified. You need a valid hashcash token to post to groups other
than alt.test and alt.anonymous.messages. Visit www.panta-rhei.eu.org
for abuse and hashcash info.
| |
| Christian Danner 2007-06-20, 7:14 am |
| Borked Pseudo Mailed wrote:
>Christian Danner wrote:
>Mixmaster isn't designed to allow all your mail to be sent to a single
>entry node Christian, any more than it's designed to allow you to send
>mail with your name, address, and phone number in it. It's designed to
>allow users to select specific remailers and build custom chains. That
>feature can be abused just like the "feature" that doesn't scan message
>text for phone numbers can.
Each Mixmaster node sees itself as a part of the mix network no matter
whether it's a local installation or publicly accessible. Would it
always send to a single destination then you had some kind of JAP,
which fortunately isn't the case with a random remailer selection in
the middle of the chain.
>
>No, it doesn't. I routinely send mail through a number off different
>servers.
And in which way do you hand over the chunks? With which tool? From
which origin? Maybe some MUA with the ip address you got from your
ISP?
> And even if your "single server" theory were true, it's irrelevant
>unless you both subscribe to the idea that one weakness justifies another,
>and discard the possibility that a remailer entry node is an even more
>ideal place from which to observe traffic than an ISP. The latter
>assumption especially, is a false one. Remailer operators not only don't
>need warrants to observe traffic, they're in a position of seeing a lot
>more traffic of that type.
IMHO no big deal as long as it comes from one of hundreds of Tor
exits.
>I submit that it's far less secure to allow a single remailer operator to
>have access to all your traffic, than it is to let your ISP know where
>you're sending remailer messages, because a remailer is an easier target
>to compromise. It's also much easier for a remailer operator to add or
>subtract latency to mail based on submitting IP address than it is for an
>ISP to do the same. In fact, if a remailer operator held up a series of
>messages for 24 hours and observed public forums for threading of messages
>they could probably identify the sender with 100% accuracy.
Ok, that's a relevant argument, a hostile entry remailer adding more
latency than your own spread in order to characterize certain
messages.
>The multiple chains are where you take a real hit, because under normal
>operations Mixmaster builds multiple chains with randomly selected entry
>nodes for each copy. This is a distinct advantage not only against evil
>remailer operators, but evil ISP's. That design feature certainly does
>"confuse" attackers because they have multiple channels to monitor, and
>the messages themselves could have come from any of them when they've
>reached the other end. There's no way to tell.
So how to accomplish this:
- single message chunks destined for multiple entry remailers
- sent directly to the respective SMTP host
- by ways of an SSL / TLS secured connection
- routed through Tor
OTOH you have
- Tor exits blocking port 25
- not all remailers equipped with SMTP hosts supporting alternate
ports / SSL secured connections
- Mixmaster not capable of selecting entry nodes from a given list
So you'd have to implement some fall back strategy:
For each chunk
1) consider / try sending it directly through Tor/SSL, if not possible
2) consider / try sending it directly, if impossible as well
3) assign the task to your ISP's SMTP host
That's the only way to get it out of your computer within a reasonable
period of time. I'm not sure whether a maximum of 10 copies resulting
in n x 10 chunks sent to a maximum of currently about 2 dozens
remailers / SMTP hosts doesn't overstretch the patience of any client
connection.
The alternative would be to go back to the basics and always choose
option 3), maybe through Tor enlisting an anonymously created
freemailer account.
>
>It also, apparently, restricts itself to a single entry nodes SMTP
>submission (I don't use it).
..... and the option of sending to multiple entry remailers but using a
single MTA.
>
>Actually it would be sufficient to simply rotate among entry nodes that
>accepted mail directly just like Mixmaster itself rotates entry nodes when
>used "normally". Last I checked there's a handful of remailers that allow
>direct submission, so it should be easy to build the same sort of
>randomized multiple copies like Mixmaster does.
You mean for each message one single random entry remailer with direct
submission. That's a realistic strategy with a different set of
dis/advantages compared to multiple entries with a single SMTP host
taking care of the delivery.
For implementing an automatism I'd have to parse the Noreply list,
select a target considering the availability of Tor, then figure out
which items meet latency and reliability preconditions. A lot of ifs
and whens, but maybe practicable.
Christian
--
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
| |
| Anonymous 2007-06-20, 1:17 pm |
| George Orwell <nobody@mixmaster.it> wrote:
> It may not work so well with privately delivered messages, but how could
> hard coding a "permanent" entry node not be considered diminished
> security in any case?
Tor does exactly the same thing to *strengthen* security.
It was determined that a random choice of entry nodes diminishes overall
security in the presence of an attacker who controls several nodes.
Restricting your set of entry nodes yields a higher percentage for the
attacker *if* he is in your set but leaves him out of the loop completely
if he is not.
| |
| Cyberiade.it Anonymous Remailer 2007-06-20, 1:17 pm |
| drsnoid wrote:
> <spam>
You should "spam" your products a little more often. I'd forgotten about
Gatepick. ;-)
And yes, it absolutely does seem to do what's being discussed here,
albeit "manually". It would be marvelous if your work were married with
something like Steve's News2Remail which ran as a daemon and accepted
normal messages from standard clients, then infused with the ability to
automatically parse the TLS list and manage config files. The remailer
"killer app" in my humble opinion.
> It takes a wee bit of maintenance but you have exactly what you're
> wanting -
> Tor, tls, random smtp entry points, random final remailer and random
> mail2news - with just a little bit of hassel. </spam>
It doesn't seem like it would be that much of a hassle once it's set up.
You could almost run on autopilot with the configs until you got an error
I think, because QS shouldn't blindly discard messages that can't be
delivered.
> Personally I don't have any difficulty using Tor with ports 465 and
> 2525, just wish more remailers offered them. 587's pretty dicey and
I never use to until about 6 months ago or so. Mail to the "S" ports went
through pretty much flawlessly. Maybe it's a Tor version thing, or just
dumb luck, but I seem to be having an increasing number of problems
submitting Mixmaster messages directly via tor. Oddly enough it seems to
be worse at certain times, when other Tor traffic seems to improve. Go
figure.
> obviously 25 you can use succesfully only once in a blue moon. I really
Indeed. I wouldn't even waste my time.
> like your idea of remailers agreeing upon and opening some weird port
> strictly for direct submission via Tor. The more the merrier.
If they chose something that looks like a typical "off color" HTTP port
like 8080 or something I think the chances of it being blocked by Tor
exits would be less. And it would look much like just another SSL enabled
web proxy to casual observers. ;-)
That's just my take on it, of course.
| |
| Borked Pseudo Mailed 2007-06-20, 1:17 pm |
| Anonymous wrote:
> George Orwell <nobody@mixmaster.it> wrote:
>
>
> Tor does exactly the same thing to *strengthen* security.
No. Tor uses trusted entries as a compromise solution to problems that
mostly don't exist in networks that aren't real time. Tor also isn't
susceptible to the "added latency" attacks remailers are susceptible to,
because any such attacks would be blatantly obvious.
But thank you for reminding us that Tor's developers fully acknowledge the
fact guard nodes are a compromise, and limiting the number of entry
nodes even to a subset of the whole reduces security.
| |
| Non scrivetemi 2007-06-20, 1:17 pm |
| Christian Danner wrote:
>
> Each Mixmaster node sees itself as a part of the mix network no matter
> whether it's a local installation or publicly accessible. Would it
> always send to a single destination then you had some kind of JAP,
> which fortunately isn't the case with a random remailer selection in
> the middle of the chain.
I'm sorry, but I don't understand this paragraph at all. You seem to be
starting to ask a question, then make a statement out if it. Maybe it's
just me but the point of what you're trying to say is somehow lost in the
translation. :-)
>
> And in which way do you hand over the chunks? With which tool? From
> which origin? Maybe some MUA with the ip address you got from your
> ISP?
What "chunks"? Mixmaster generates individual messages for each copy in a
chain. Each of those copies is in turn sent to whichever randomly chosen
remailer that appears in it's individual chain, as a "normal" email
message.
I take it a step further by varying my mail transport method for each set
of copies, between several SMTP servers in various locations, both with,
and without Tor and other methods. And there's really nothing preventing me
from either generating multiple "single copy" messages and sending them
differently, or even accessing Mixmaster's pool and randomly sending
messages through various channels rather than sending complete "sets" of
messages all through the same channel. It would be that much more secure
in fact.
I dandy Idea, I think I'll take a run at it.
>
> IMHO no big deal as long as it comes from one of hundreds of Tor
> exits.
No, it's "less of a big deal". Adding security to one facet of your
anonymous traffic doesn't justify screwing up another. Even if you're
using using Tor certain messages could be partitioned and controlled en
masse by an evil operator if that operator was given control of all your
messages.
>
> Ok, that's a relevant argument, a hostile entry remailer adding more
> latency than your own spread in order to characterize certain messages.
Thank you.
>
> So how to accomplish this:
>
> - single message chunks destined for multiple entry remailers
> - sent directly to the respective SMTP host
> - by ways of an SSL / TLS secured connection
> - routed through Tor
Again, Tor helps. Nobody's denying that. But Tor is a band aid over
another weakness in this scenario. And tor is demonstrably weaker then the
remailer network by it's real time nature, so you are in essence using
weaker security to bolster up stronger security you've weakened horribly
by misusing it.
It makes no sense at all. What you should be doing is using Mixmaster
properly, as it was designed to be used, and adding on Tor as an
additional margin of security.
> OTOH you have
>
> - Tor exits blocking port 25
> - not all remailers equipped with SMTP hosts supporting alternate
> ports / SSL secured connections
> - Mixmaster not capable of selecting entry nodes from a given list
>
> So you'd have to implement some fall back strategy:
Or a third party program which randomly selected the missing pieces of the
puzzle from it's own lists, dictated proper chains to Mixmaster, and
handled transport. ;-)
>
> .... and the option of sending to multiple entry remailers but using a
> single MTA.
Sorry, I was only going by what you're saying in this thread.
>
> You mean for each message one single random entry remailer with direct
> submission. That's a realistic strategy with a different set of
> dis/advantages compared to multiple entries with a single SMTP host
> taking care of the delivery.
What disadvantages? You're taking Mixmaster's designed in randomness, and
removing one of the single points of compromise that exists just prior to
the effects of that random selection coming into play.
Randomly rotating direct delivery is nothing but a win-win proposition.
Add Tor to that mix and it's a win-win-win deal. :-)
> For implementing an automatism I'd have to parse the Noreply list,
Yes, that's the point exactly. Using that list and/or drsnoids, and perhaps
some internal, periodical tests to verify it's data (potentially good
"dummy" traffic). Then randomizing your direct submission entry nodes so
that one operator doesn't have sole ownership of all your anonymous
traffic.
> select a target considering the availability of Tor, then figure out
> which items meet latency and reliability preconditions. A lot of ifs
> and whens, but maybe practicable.
It's a piece of cake. ;-)
Actually, even the Tor "availability" issue is a pretty easy one to
address. There's existing code that parses the router list, and given a
Host:Portrange combination spits out every exit node that allows access to
to that particular combination. I believe it's even up as a CGI script on
one of the Tor developers' web sites or another, or use to be.
It's definitely doable. It just takes convincing some existing software's
author it's worth doing, or finding the time to code it yourself. ;-)
| |
| Christian Danner 2007-06-21, 7:13 am |
| "Non scrivetemi" wrote:
>Christian Danner wrote:
>
>
>I'm sorry, but I don't understand this paragraph at all. You seem to be
>starting to ask a question, then make a statement out if it. Maybe it's
>just me but the point of what you're trying to say is somehow lost in the
>translation. :-)
Please excuse my pidgin English. ;-)
It was still about the 'not designed to allow ... a single entry node'
statement and I intended to express that in this respect it matters
whether you're talking about a publicly available remailer with
external messages for mixing at hand or the private instance you run
as a simple gateway. But I think we don't have to spend more time on
this question.
>
>What "chunks"? Mixmaster generates individual messages for each copy in a
>chain. Each of those copies is in turn sent to whichever randomly chosen
>remailer that appears in it's individual chain, as a "normal" email
>message.
Different from Type 1 remailers Mixmaster splits messages if they
exceed a certain size so that each sent packet, I call it chunk, is of
20480 bytes in raw size (prior to its base64 encoding). So each single
'copy' may be transformed into multiple 'chunks', each of which is
sent through an individual remailer chain. That's why I advise against
using a prime number of copies, as for a usual short messages that
indicates that either the original message fits into one single chunk
or you sent only one copy.
>I take it a step further by varying my mail transport method for each set
>of copies, between several SMTP servers in various locations, both with,
>and without Tor and other methods. And there's really nothing preventing me
>from either generating multiple "single copy" messages and sending them
>differently, or even accessing Mixmaster's pool and randomly sending
>messages through various channels rather than sending complete "sets" of
>messages all through the same channel. It would be that much more secure
>in fact.
I suppose with 'each set of copies' you mean the complete set of
chunks / packets resulting from one single original message whereas
'complete "sets" of messages' are the Mixmaster traffic of one
individual as a whole. But what do you mean by 'multiple "single copy"
messages'? For each chunk an individual method of delivery to the
entry remailer (different SMTP server, with/out Tor etc.)?
>
>No, it's "less of a big deal". Adding security to one facet of your
>anonymous traffic doesn't justify screwing up another. Even if you're
>using using Tor certain messages could be partitioned and controlled en
>masse by an evil operator if that operator was given control of all your
>messages.
You're absolutely right - in theory. But the tread is about OmniMix,
and with my project I'm interested in strategies that can be realized
with a proxy server that isn't allowed to buffer messages, may only
have access to the Internet for a short period of time (dial-up
connection or let's even say wardriving) and shouldn't have to be
touched periodically in order to do its usual work. As usability is
important to attract more users 'install and forget' would be best,
which IMHO is a realistic goal.
>
>Thank you.
My pleasure. :-)
>
>Again, Tor helps. Nobody's denying that. But Tor is a band aid over
>another weakness in this scenario. And tor is demonstrably weaker then the
>remailer network by it's real time nature,
FACK. But we discuss valuable methods to get to the entry remailer
first, where then the more reliable processing takes place. So
remailers aren't an option here. ;-)
> so you are in essence using
>weaker security to bolster up stronger security you've weakened horribly
>by misusing it.
>
>It makes no sense at all. What you should be doing is using Mixmaster
>properly, as it was designed to be used, and adding on Tor as an
>additional margin of security.
>
>
>Or a third party program which randomly selected the missing pieces of the
>puzzle from it's own lists, dictated proper chains to Mixmaster, and
>handled transport. ;-)
>
>What disadvantages? You're taking Mixmaster's designed in randomness, and
>removing one of the single points of compromise that exists just prior to
>the effects of that random selection coming into play.
If you take the alternatives from above:
1) All chunks of a message sent to a single randomly selected
remailer, maybe through Tor
2) Each chunk with an individual random entry remailer, all of them
delivered by a single external MTA (as not every remailer is equipped
with an SMTP host), thus no Tor (as long as you don't use an anon
freemailer account, but that's a different story).
Scenario 1) offers some kind of low level anonymity at the entry but
allows the entry remailer to hold back messages. Scenario 2) offers no
anonymity but it's harder for an adversary to perform delay attacks.
Thus a different spectrum of weaknesses.
>Randomly rotating direct delivery is nothing but a win-win proposition.
>Add Tor to that mix and it's a win-win-win deal. :-)
>
>
>Yes, that's the point exactly. Using that list and/or drsnoids, and perhaps
>some internal, periodical tests to verify it's data (potentially good
>"dummy" traffic). Then randomizing your direct submission entry nodes so
>that one operator doesn't have sole ownership of all your anonymous
>traffic.
>
>
>It's a piece of cake. ;-)
>
>Actually, even the Tor "availability" issue is a pretty easy one to
>address.
Tor is already a part of the OmniMix installation. The program itself
includes a Tor controller, which is able to automate the complete
handling of a dedicated Tor instance.
> There's existing code that parses the router list, and given a
>Host:Portrange combination spits out every exit node that allows access to
>to that particular combination. I believe it's even up as a CGI script on
>one of the Tor developers' web sites or another, or use to be.
Do you mean individual Tor exits dependent on the remailer? That won't
work with OmniMix, which has to process several messages
simultaneously.
BTW, I'm not sure from which moment on a requested new Tor chain
definitely is used. Does it matter whether there still are open
connections that run through the old chain? I don't think a Tor
instance is able to handle different chains at the same time.
Therefore the best (realistic) strategy I can imagine is the frequent
request of a new Tor identity / exit (already implemented) combined
with a random selection of the (single) Mixmaster entry node on a per
message basis. You'd still have to deal with the mentioned delay
attack, but there's no longer a single entry remailer getting your
complete anon correspondence.
A machine readable file somewhere on the Internet listing all working
connections in a format like
- last check (UTC)
- remailer token
- email address
- host address
- port
- encryption methods ('none' / 'ssl' / 'tls')
- ssl fingerprint (to prevent MITM attacks)
e.g.
200706210820<tab>anon<tab>mixmaster@anon.978.org<tab>osiris.978.org<tab>465<tab>ssl<tab>89E044F45E40A9688D01569675E491EA<cr><lf>
200706210824<tab>banana<tab>banana@mixmaster.mixmin.net<tab>fleegle.mixmin.net<tab>2525<tab>tls<tab>2EA891634E64BC89DCC0DF0BC4AF7201<cr><lf>
200706210831<tab>banana<tab>banana@mixmaster.mixmin.net<tab>fleegle.mixmin.net<tab>465<tab>ssl<tab>2EA891634E64BC89DCC0DF0BC4AF7201<cr><lf>
....
would be of great help.
>It's definitely doable. It just takes convincing some existing software's
>author it's worth doing, or finding the time to code it yourself. ;-)
We shall see.
Regards
Christian
--
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
| |
| Cyberiade.it Anonymous Remailer 2007-06-23, 1:13 pm |
| Christian Danner wrote:
Sorry for the late reply, I got caught in a real mess here.
>
> Different from Type 1 remailers Mixmaster splits messages if they
> exceed a certain size so that each sent packet, I call it chunk, is of
> 20480 bytes in raw size (prior to its base64 encoding). So each single
> 'copy' may be transformed into multiple 'chunks', each of which is
Two things.
The mixmaster packet size really means nothing at all to clients. Yes, if a
message is large enough it's split up into "chunks", but when the message
is sent they all go to the same remailer at the same time. The connection
is made, and the pool is flushed. It's obvious that the "chunks" are all
the same message. Packet size doesn't become a real factor until the
message reaches the entry node's pool, so from the client's perspective we
can ignore the 20480 thing completely.
Second, I was referring to things in terms of mixmaster's config and
command line options. Sending messages with "--copies=x" or the equivalent
setting/config, where multiple messages with different chains leading to
the same exit node are generated. By hard cosing an entry node you not
only partially defeat the purposes of sending multiple copies, you (again)
hand all your traffic to a single entry node and give him clues about your
usage patterns.
> sent through an individual remailer chain. That's why I advise against
> using a prime number of copies, as for a usual short messages that
> indicates that either the original message fits into one single chunk
> or you sent only one copy.
This wouldn't matter a bit if multiple copies are sent to different entry
nodes like they are meant to be. And individual packets will always go to
the same remailer, regardless of whether there's an odd, even, or prime
number of them.
>
> I suppose with 'each set of copies' you mean the complete set of
> chunks / packets resulting from one single original message whereas
> 'complete "sets" of messages' are the Mixmaster traffic of one
> individual as a whole. But what do you mean by 'multiple "single copy"
> messages'? For each chunk an individual method of delivery to the
> entry remailer (different SMTP server, with/out Tor etc.)?
I was suggesting that instead of generating messages with --copies=5 for
example, one could run "mixmaster --copies=1 ..." five times concurrently
over the same message, using the same exit node for all, and mixing up
transmission methods for each "send".
Alternately, one could access Mixmaster's pool (remember were talking about
clients where the pool is flushed automatically every time a message is
sent anyway), and "randomize" the way individual packets/copies are
transmitted to their respective entry nodes. If a message was large enough
to be broken down into 3 packets let's say, one could be sent through Tor
as a direct submission, one could be sent through a normal ISP mail
server, and one through an SSL conneciton to something like Gmail.
This would cover up quite a bit of information about who was senting what
messages as far as teh entry node was concerned, and help thwart the "huge
added latency" attack we were talking about.
>
> You're absolutely right - in theory. But the tread is about OmniMix,
> and with my project I'm interested in strategies that can be realized
> with a proxy server that isn't allowed to buffer messages, may only
> have access to the Internet for a short period of time (dial-up
> connection or let's even say wardriving) and shouldn't have to be
> touched periodically in order to do its usual work. As usability is
> important to attract more users 'install and forget' would be best,
> which IMHO is a realistic goal.
You could do this and still have revolving "direct delivery" entry nodes,
if you had a reliable source of statistics regarding which nodes were
good.
>
> FACK. But we discuss valuable methods to get to the entry remailer
> first, where then the more reliable processing takes place. So
> remailers aren't an option here. ;-)
Right, but that's no excuse for nudging users in the direction of using
the remailer network itself in a less secure way. AS it stands now, unless
users are torifying OmniMix they're essentially handing over control of
everything they do to a single operator. Not even a set of trusted "guard
nodes" like Tor implemented, but a single, mostly unscrutinized, person.
And even with Tor in the mix they're doing the same, albeit with that band
aid. There's many things to consider there. Tor can't insulate you from
certain things, and a snoopy operator might still be able to partition a
user by observing certain "fingerprints" a client might have and patterns
of usage. A "user fo client X who always sends messages at 4:13PM" type
thing, but much more complicated of course.
Hard coding an entry node is just a bad, bad thing in my opinion.
Maintaining anonymity is tough enough without purposefully handing over a
key bit of information to a single entity. The software is designed to
spread that information as thinly as possible within it's scope of
influence, and I hold fast to the ideal that this is the way it should be
used. We should be working towards enhancing that scattering of knowledge
to the winds rather than trying to consolidate it, even in the name of
"usability".
>
> If you take the alternatives from above:
>
> 1) All chunks of a message sent to a single randomly selected
> remailer, maybe through Tor
>
> 2) Each chunk with an individual random entry remailer, all of them
> delivered by a single external MTA (as not every remailer is equipped
> with an SMTP host), thus no Tor (as long as you don't use an anon
> freemailer account, but that's a different story).
You're missing option three.
3) Each copy of a message sent to it's respective, randomly selected entry
node in the most secure possible way possible for each specific node.
Torified direct SSL/TLS submission if possible, falling back through a
couple lesser paths to the standard ISP SMTP server if necessary.
> Scenario 1) offers some kind of low level anonymity at the entry but
> allows the entry remailer to hold back messages. Scenario 2) offers no
> anonymity but it's harder for an adversary to perform delay attacks.
> Thus a different spectrum of weaknesses.
Scenario 3 removes control of all knowledge from any and all parties
involved, save for the originator of the message. Just as life should
be. ;-)
>
> Tor is already a part of the OmniMix installation. The program itself
> includes a Tor controller, which is able to automate the complete
> handling of a dedicated Tor instance.
Then the job is half done. All you really need is a reliable source of
direct submission stats and a few lines of code that selects from among
the known good direct submission remailers as randomly as possible. Or
even better, detects randomly generated chains for the opportunity, and
takes advantage of it.
The latter might be against your design philosophy, and I understand that,
but the former is in perfect harmony with what you're trying to accomplish.
Even rotating among a couple direct submission servers would be preferable
to sending everything through one.
> BTW, I'm not sure from which moment on a requested new Tor chain
> definitely is used. Does it matter whether there still are open
> connections that run through the old chain? I don't think a Tor
> instance is able to handle different chains at the same time.
It will handle it fine. In fact if there's one thing that's plagued users
since Tor went public (in one way or another whether they realize it or
not), it's Tor freely eating resources to establish new connections for
each new request.
> Therefore the best (realistic) strategy I can imagine is the frequent
> request of a new Tor identity / exit (already implemented) combined
> with a random selection of the (single) Mixmaster entry node on a per
> message basis. You'd still have to deal with the mentioned delay
> attack, but there's no longer a single entry remailer getting your
> complete anon correspondence.
That would be a big improvement in my opinion. Similar to Tor's trusted
entry node scheme, not quite as secure due to the real time nature of Tor
and the easier detection of added latency and other shenanigans, but it
would at least "share the wealth" as it were. ;-)
> A machine readable file somewhere on the Internet listing all working
> connections in a format like
Why not parse Noreply and maintain the list yourself, at the client if
possible? It could be part of some sort of dummy traffic scheme.
> - last check (UTC)
> - remailer token
> - email address
> - host address
> - port
> - encryption methods ('none' / 'ssl' / 'tls')
> - ssl fingerprint (to prevent MITM attacks)
This should be stored internally in any case. It's OK to compare to a
public posting, but if you rely on the public version for anything you're
setting yourself up for a broad compromise.
| |
| Christian Danner 2007-06-24, 1:14 pm |
| Cyberiade.it Anonymous Remailer wrote:
>Christian Danner wrote:
>
>Sorry for the late reply, I got caught in a real mess here.
Never mind. Hope it turned out well.
>
>Two things.
>
>The mixmaster packet size really means nothing at all to clients. Yes, if a
>message is large enough it's split up into "chunks", but when the message
>is sent they all go to the same remailer at the same time. The connection
>is made, and the pool is flushed. It's obvious that the "chunks" are all
>the same message. Packet size doesn't become a real factor until the
>message reaches the entry node's pool, so from the client's perspective we
>can ignore the 20480 thing completely.
Not at all.
Here's a OmniMix log excerpt from sending a larger message in one
single copy ...
14:56:23.871 0 Processing message with Mixmaster ...
14:56:23.891 0 Waiting for Mixmaster access permission ...
14:56:23.901 0 Calling Mixmaster (parameters: ' -m -c 1 -l *,*,*,*,*
om\0.mxt') ...
14:56:25.984 0 Mixmaster encryption completed
14:56:25.984 0 Try to retrieve files from the pool
'G:\Program\Delphi\Projects\OmniMix\mix\
pool'
14:56:33.145 0 Got 14 chunks for 1 copy
.... and what Mixmaster had to say
Mixmaster Reply (Task 0):
Chain:
banana,awxcnx,paranoia,borked,dizum
pboxmix,zerofree,borked,cyberiad,dizum
austria,borked,cyberiad,awxcnx,dizum
paranoia,cyberiad,cripto,metacolo,dizum
austria,borked,paranoia,zerofree,dizum
cyberiad,austria,metacolo,borked,dizum
cyberiad,cripto,paranoia,george,dizum
austria,paranoia,cripto,metacolo,dizum
cyberiad,pboxmix,paranoia,borked,dizum
cyberiad,paranoia,austria,zerofree,dizum
metacolo,cyberiad,pboxmix,paranoia,dizum
zerofree,cripto,austria,metacolo,dizum
george,paranoia,metacolo,borked,dizum
cripto,metacolo,pboxmix,cyberiad,dizum
So each chunk gots its individual chain, not only each copy.
>
>I was suggesting that instead of generating messages with --copies=5 for
>example, one could run "mixmaster --copies=1 ..." five times concurrently
>over the same message, using the same exit node for all, and mixing up
>transmission methods for each "send".
With all those 'copies' you need a truly sympathetic recipient. ;-)
>Alternately, one could access Mixmaster's pool (remember were talking about
>clients where the pool is flushed automatically every time a message is
>sent anyway), and "randomize" the way individual packets/copies are
>transmitted to their respective entry nodes. If a message was large enough
>to be broken down into 3 packets let's say, one could be sent through Tor
>as a direct submission, one could be sent through a normal ISP mail
>server, and one through an SSL conneciton to something like Gmail.
>
>This would cover up quite a bit of information about who was senting what
>messages as far as teh entry node was concerned, and help thwart the "huge
>added latency" attack we were talking about.
Confusion isn't always helpful. Sending only parts of a message
through Tor makes it much easier to localize the originator.
>
>You could do this and still have revolving "direct delivery" entry nodes,
>if you had a reliable source of statistics regarding which nodes were
>good.
.... concerning the remailer and the dedicated SMTP host.
>Right, but that's no excuse for nudging users in the direction of using
>the remailer network itself in a less secure way. AS it stands now, unless
>users are torifying OmniMix they're essentially handing over control of
>everything they do to a single operator. Not even a set of trusted "guard
>nodes" like Tor implemented, but a single, mostly unscrutinized, person.
That's not the case. Once more, with OM you currently have the
following options:
- Delivery to multiple entry nodes through some SMTP server without
Tor
- Delivery to the SMTP host of a single entry nodes with Tor involved
This doesn't include setting up an anonymous freemailer account and
accessing it through Tor, which I also mentioned already. Then you'd
have both, Tor and multiple remailer entry nodes. But that's not the
standard situation.
>And even with Tor in the mix they're doing the same, albeit with that band
>aid. There's many things to consider there. Tor can't insulate you from
>certain things, and a snoopy operator might still be able to partition a
>user by observing certain "fingerprints" a client might have and patterns
>of usage. A "user fo client X who always sends messages at 4:13PM" type
>thing, but much more complicated of course.
Sure, but those are different questions.
>Hard coding an entry node is just a bad, bad thing in my opinion.
>Maintaining anonymity is tough enough without purposefully handing over a
>key bit of information to a single entity. The software is designed to
>spread that information as thinly as possible within it's scope of
>influence, and I hold fast to the ideal that this is the way it should be
>used. We should be working towards enhancing that scattering of knowledge
>to the winds rather than trying to consolidate it, even in the name of
>"usability".
That's your POV which I appreciate.
>
>You're missing option three.
Referring to your thoughts in discussing the current status I didn't
miss anything.
>3) Each copy of a message sent to it's respective, randomly selected entry
>node in the most secure possible way possible for each specific node.
>Torified direct SSL/TLS submission if possible, falling back through a
>couple lesser paths to the standard ISP SMTP server if necessary.
Exactly what I already mentioned as a potential future improvement.
>
>Then the job is half done. All you really need is a reliable source of
>direct submission stats and a few lines of code that selects from among
>the known good direct submission remailers as randomly as possible. Or
>even better, detects randomly generated chains for the opportunity, and
>takes advantage of it.
>
>The latter might be against your design philosophy, and I understand that,
>but the former is in perfect harmony with what you're trying to accomplish.
>Even rotating among a couple direct submission servers would be preferable
>to sending everything through one.
Sure.
>
>It will handle it fine. In fact if there's one thing that's plagued users
>since Tor went public (in one way or another whether they realize it or
>not), it's Tor freely eating resources to establish new connections for
>each new request.
Which doesn't necessarily mean a different chain.
>
>Why not parse Noreply and maintain the list yourself, at the client if
>possible? It could be part of some sort of dummy traffic scheme.
I have no idea of how the Noreply data are gathered and whether all
parameter combinations are thoroughly tested. If it's a complete
pinger that also checks whether the transmitted data are really
processed, then that's the way to go.
>
>This should be stored internally in any case. It's OK to compare to a
>public posting, but if you rely on the public version for anything you're
>setting yourself up for a broad compromise.
Testing the availability is a process consuming time and other
ressources, which doesn't have to be done by each client on its own.
Why do you think this is different from remailer statistics?
Christian
--
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm
| |
| Anonymous 2007-06-24, 7:13 pm |
| Christian Danner wrote:
[some snippage]
>
> Never mind. Hope it turned out well.
Short story - one of the staff working at an office where I have a loose
agreement regarding network maintenance decided it was a good idea to give
their log in information to someone on the night cleaning crew. That
person did some bad things, embarrassed the business, and the fallout was
a few firings and a complete rebuild of the network from scratch.
I think I would have rather dealt with the firings. ;-)
>
> Not at all.
>
> Here's a OmniMix log excerpt from sending a larger message in one
> single copy ...
>
> 14:56:23.871 0 Processing message with Mixmaster ...
> 14:56:23.891 0 Waiting for Mixmaster access permission ...
> 14:56:23.901 0 Calling Mixmaster (parameters: ' -m -c 1 -l *,*,*,*,*
[...]
> ... and what Mixmaster had to say
>
> Mixmaster Reply (Task 0):
> Chain:
> banana,awxcnx,paranoia,borked,dizum
> pboxmix,zerofree,borked,cyberiad,dizum
[...]
> So each chunk gots its individual chain, not only each copy.
This is how it's suppose to work, how Mixmaster is "designed" to work, but
it can not work that way if you're using direct delivery via a remailer's
SMTP daemon. Those messages must have the first remailer in every chain
and copy be the entry node you're direct delivering to.
I think you know this, and I'm confused as to why you'd offer Omnimix
output from a "normal" run as evidence to support your direct delivery
assertions.....???
>
> With all those 'copies' you need a truly sympathetic recipient. ;-)
I was talking about Usenet mostly, where a final M2N/remailer delivery
point should be using hashes or what not to burn duplicates.
I agree it would be annoying in private mail or where dupe checking
failed. I also agree that's going to be a lot. It was really just a "what
if" type suggestion leading to this:
>
> Confusion isn't always helpful. Sending only parts of a message
> through Tor makes it much easier to localize the originator.
Not at all. It adds more randomness and hence complexity to the delivery
mechanism. It makes it that much harder to collate a single packet with a
given message. It takes random chains, fixed packet size, pooling, and
random latency a step further. It only makes it harder for an attacker to
do their job by forcing them to watch and attack more channels.
> ... concerning the remailer and the dedicated SMTP host.
>
>
> That's not the case. Once more, with OM you currently have the
> following options:
I understand the current options, what I'm suggesting is a third or
fourth, and better options. Even with Tor involved an evil entry node
operator can learn information that Mixmaster is designed to prevent them
from learning. Especially regarding larger messages with multiple packets.
The "ideal" if there is one, would be to allow mixmaster to generate
proper chains and deliver them accordingly, directly, through Tor. The
"compromise" in this case is essentially an implementation of Tor "guard
nodes", where a client rotated direct delivery (via Tor or otherwise) among
as many possible entry nodes as is feasible. The "win-win-win" situation
where you get maximum possible benefit without adding so much complexity
you break things.
>
> Sure, but those are different questions.
They're all the same issue. How to best deliver your Mixmaster traffic
to the remailer network.
>
> Exactly what I already mentioned as a potential future improvement.
Potential? :-)
Suffice to say I think it should be a priority. We both agree that there's
major consequences to always direct delivering to the same entry node. Tor
certainly addresses some of those consequences, but obviously not all of
them. A user could still be partitioned in various ways, and that might
cause a breach of security that spans multiple usages rather than one. An
attacker can replay traffic at will in this scenario, and even using Tor
each message is "whole and complete" from their point of view. Each
message can be resent, and uniquely identified from end to end.
This is the very reason randomly generated chains exist. To prevent this
sort of attack. It remove the possibility that a single operator can
replay, or "delay attack" traffic by giving several operators a mostly
useless piece of the message and guaranteeing delivery even if a node
holds their traffic, through redundancy.
Forcing a hard coded entry node flies in the face of all of that, and it
doesn't matter whether or not Tor is used. You've demolished almost
everything Mixmaster does to fight replay and latency attacks.
>
> Which doesn't necessarily mean a different chain.
Yes it does. Tor builds new chains for each connect request unless you
specifically tell it not to.
>
> I have no idea of how the Noreply data are gathered and whether all
> parameter combinations are thoroughly tested. If it's a complete
> pinger that also checks whether the transmitted data are really
> processed, then that's the way to go.
I agree 100%, and don't know how that data is compiled either. Good data is
essential. Which is why I'd prefer to collect it myself if at all possible.
Use Noreply as a starting point and send pings via direct delivery
to verify.
>
> Testing the availability is a process consuming time and other
> ressources, which doesn't have to be done by each client on its own.
> Why do you think this is different from remailer statistics?
Agreed, it's another compromise. Which leads me right to my next point of
developing a special "Echolot" to compile reliable direct submission
statistics, or even using Echolot itself restricted to direct delivery.
Each client testing their own nodes would be "perfect", and many could
manage it. Some could not.
| |
| Borked Pseudo Mailed 2007-06-24, 7:13 pm |
| In article <22610df07266a6c3695839e6427ade58@ecn.org>
Anonymous <cripto@ecn.org> wrote:
>
>
> I was talking about Usenet mostly, where a final M2N/remailer delivery
> point should be using hashes or what not to burn duplicates.
>
> I agree it would be annoying in private mail or where dupe checking
> failed. I also agree that's going to be a lot. It was really just a "what
> if" type suggestion leading to this:
Actually, the final remailer is what burns the duplicates, not the
mail2news server. If you use copies you should never end up with more
than one mail actually exiting from the remailer network regardless of
whether it is destined to usenet or an email address.
>
> Yes it does. Tor builds new chains for each connect request unless you
> specifically tell it not to.
It doesn't, it uses the same chain circuit for multiple connect
requests until a certain time limit has expired which is 10 minutes by
default. You can modify that by changing the MaxCircuitDirtiness
config option.
There is also a NEWNYM controller command to tell Tor to not use any
circuits that have been used before or are currently being used.
>
> I agree 100%, and don't know how that data is compiled either. Good data is
> essential. Which is why I'd prefer to collect it myself if at all possible.
> Use Noreply as a starting point and send pings via direct delivery
> to verify.
You take the remailer address, look up the MX record from DNS, connect
to the address revealed by the MX lookup, check for TLS with starttls,
try and connect to the other ports (465, 587, 2525)...
Windows 2000 and above make it easy to look up MX records, but
you're destined to have to manually code a DNS protocol client if you
want to keep compatibility with Windows 98/95/ME.
|
|
|
|
|