public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)
Date: Mon, 6 May 2013 20:04:18 +0200	[thread overview]
Message-ID: <20130506180418.GA3797@netbook.cypherspace.org> (raw)
In-Reply-To: <CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>

Bitcoin p2p seeding requirements hav some ToR similarities, and we went
through the same security considerations with Zero-Knowledge systems freedom
network.  Though bitcoins attacker profile and motivation is different - so
the defense maybe even more demanding.  At least you have no shortage of
nodes and perhaps merchant interest and general good-will to lean on.

At ZKS I proposed we should fix the exit node issue (exit sees where you go
often in the clear) with an apache mod so the freedom aip tunnel (ToR tunnel
equiv) could terminate right on the web site.  (ZKS freedom network is long
dead but some of the ideas I think made it into ToR, eg I hope my end2end
forward anonymity idea that is implemented in Zach Brown's cebolla.)

Anyway I'd have about DNS being of limited value: bitcoins primary
vulnerability IMO (so far) is network attacks to induce network splits,
local lower difficulty to a point that a local and artificially isolated
area of the network can be fooled into accepting an orphan branch as the
one-true block chain, maybe even from node first install time.

(btw I notice most of the binaries and tar balls are not signed, nor served
from SSL - at least for linux).

Therefore as it applies to discover, you want to be able to discover peers
through as many network routes, and even steganographic protocols as
possible.  eg if a popular web server (say apache, or an apache module) put
a steganographic peer discover relay from its own network area, even for a
small bitcoin fee, that would help a lot.  (Steganographic in the SSL sense
would just mean that the peer seed request to /btcseed.cgi would not be
distinguishable to someone highly sophisticated on the inside of the router
all the peers traffic is routed through.  Eg you could easily do this with a
special magic header that overwrites something else or deletes some
unnecessary header so that the request at least is a standard size, and pad
the response to the same size as the site index.html or whatever).  If the
user picks a few SSL sites and cross checks (more for high value) a subset
of peers available on all and uses them as his seed that seems like a better
direction.

In that way an attacker cant control the network without denying service to
popular SSL sites, which would be a warning sign to users, or having at his
disposal a SSL sub-CA cert (like happened with diginotar and gmail).  You
may be able to pin CAs for popular sites.  Obviously to the extent you're
using SSL you want to generally use EDH for forward-secrecy.  And not RC4 :)

Probably anysite that accepts bitcoin payment will be happy to run such a
mod-bitcoin.


With ToR, it has a similar bootstrap problem to bitcoin.  So while that may
help it is also passing the buck, not necessarily solving the problem.  And
as I said I think its possible bitcoin has a higher assurance need in that
the attackers motivated my $$ might put more effort in than the odd
dictatorship trying to pay lip service to preventing people reading pages on
a blacklist.


Given the vulnerability of DNS to poisoning I would not trust it too much. 
I know its just a bootstrap, but ideally you dont want to bootstrap from a
known publicly vulnerable protocol - it invites DNS poison net splits
against new users.


Also to the extent that users local clock is under his control (with
unuthentcated NTP?) he should also treat sudden dramatic changes in luck
(deviations from 10min interval) as suspicious.  

Unfortunately at present because of the first past the post nature of the
bitcoin lottery, reduced variance hashcash cannot be used, so its hard to
infer too much even from quite significant luck changes.

Adam

On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote:
>> Speaking of, off-topic for this discussion, but in the future
>> node-to-node communicate should be encrypted and signed
>
>Yes, I'd like to do this. The threat isn't really ISPs which are
>mostly trustable (the worst they normally do outside of places like
>China is dick about with ads), the big threat is people who use
>untrusted WiFi without realising and end up thinking they received
>money when actually they were just connected to a hotspot running in
>the attackers pocket. I'm rather expecting that kind of thing to
>happen in future.
>
>I think we can converge on the best solution with several iterations:
>
>Iteration 1) Make it clear in the UI that if the phone is connected to
>WiFi, payments from untrusted people should not be accepted. Currently
>the Android app merely says the money won't be spendable for a few
>minutes. It needs to communicate the "may not exist" aspect more
>clearly. If you're connected via a cell tower, the existing wording is
>fine - it's very unlikely your telco is trying to scam you in a
>person-to-person transaction, traffic is encrypted and 3G+ connections
>authenticate the network so you can't be MITMd except by your telco.
>Assuming you have a good list of IPs, of course.
>
>Iteration 2) Give nodes keys that appear in addr broadcasts and seed
>data (whether it be via https or otherwise), and have each node keep a
>running hash of all messages sent on a connection so far. Add a new
>protocol message that asks the node to sign the current accumulated
>hash. Not all messages really need to be signed, eg asking for
>signatures of blocks is sort of pointless at high difficulty levels
>because the structures are self proving and a simple watchdog timer
>that looks for unusually slow progress is probably enough. If the
>client keeps the same accumulated hash then when you encounter
>something you care about the accuracy of, you can ask for a signature
>over all traffic so far.
>
>Iteration 3) Do something about end to end encryption, just delegate
>everything to Tor, or find some other way to obfuscate the origin of a
>transaction (a mini onion network for example).
>
>Last time I looked, Tor wasn't really usable in library form and
>connecting to hidden services is really slow. So it'd be an issue to
>just re-use it out of the box, I think.



  parent reply	other threads:[~2013-05-06 18:04 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-06 14:58 [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes) Mike Hearn
2013-05-06 16:12 ` Peter Todd
2013-05-06 16:20   ` Jeff Garzik
2013-05-06 16:34     ` Mike Hearn
2013-05-06 16:37     ` Peter Todd
2013-05-06 16:47       ` Mike Hearn
2013-05-06 17:19         ` Peter Todd
2013-05-06 17:25           ` Jeff Garzik
2013-05-06 17:42           ` Gregory Maxwell
2013-05-06 17:53             ` Peter Todd
2013-05-06 18:01               ` Gregory Maxwell
2013-05-06 18:19                 ` Peter Todd
2013-05-06 18:32                 ` Adam Back
2013-05-06 19:08                   ` Peter Todd
2013-05-06 19:50                     ` Adam Back
2013-05-06 20:43                       ` Peter Todd
2013-05-06 23:44                         ` Peter Todd
2013-05-07  9:00           ` Mike Hearn
2013-05-09  0:57             ` John Dillon
2013-05-06 18:04         ` Adam Back [this message]
2013-05-06 18:25           ` Gregory Maxwell
2013-05-06 22:51             ` [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets) Adam Back
2013-05-06 23:13               ` Gregory Maxwell
2013-05-07  4:48                 ` Petr Praus
2013-05-07 21:07                   ` Matt Corallo
2013-05-07  9:17                 ` Mike Hearn
2013-05-07 11:07                   ` Adam Back
2013-05-07 12:04                     ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130506180418.GA3797@netbook.cypherspace.org \
    --to=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox