I researched TorCoin. I feel like I know a fair amount
about Tor and BitCoin.
What worries me most about Tor is that people do not
realize how trivially an exit relay can MITM your traffic.
The value proposition of Tor is NOT keeping all your traffic
safe. It's anonymizing your traffic from end to end, so
that nobody who sees your data knows both where it came from
and where it's going. They can still see the data itself.
For all intents and purposes, traffic from Exit -> Internet
is plaintext. The relay operator can MITM it. Tor is only
safer than a VPN or proxy because the exit relay does not
know your identity. It can still access the data you
transfer through it. [4]
Anyone can start a Tor exit relay, and setting up a MITM
proxy on it is trivial. Siphoning bitcoin transactions
is equally trivial. Just listen for the proper traffic patterns.
You should not be transferring any business-critical
data over Tor. It's a great tool for protecting your
identity, but not your data.
With HTTPS, you're relatively safer, since you'll get
an alert if a relay is MITM'ing you and modifying the
certificate. But with plain HTTP, you won't even
know when you're getting MITM'd.
I will preface this reply by saying that I am not very familiar with Tor.
Would using a VPN together with Tor be able to provide 'the best of both worlds', so to speak? Would you be able to encrypt your data via a VPN node and use Tor through that encrypted connection?
I assume this would solve the matter of your traffic being visible to whoever is running the Tor relay, but it be possible for the VPN operator to (potentially and hopefully hypothetically) still perform an MITM attack on your traffic?
And lastly, is there a truly practical way to be not only anonymous but also secure (i.e. encryption)?
I'm not worried about the transactions themselves, as
they appear on the blockchain. What worries me is the
"meta transactions", if you will. The Bitcoin ecosystem
is full of off-blockchain transactions. For example,
mining pools use their own communication mechanisms, which
the BGP attack this summer exploited. Also, dozens of
exchanges, marketplaces, and services rely on HTTP API's
for transacting. Even if the blockchain is not vulnerable,
the external transactions that reference it certainly could be.
Imagine how many "send X bitcoin from wallet Y to wallet Z"
requests route over HTTP. Quite a few.
So yeah, not "trivial" as I said. But certainly not impossible.
(Welcome to HN! I'm glad my mistake brought you out of the woodwork.)
However, I still believe nothing is fundamentally broken. Any important protocol should be using SSL - especially when operating over TOR. Lapses like this are still simply user error.
As a side note about "Anyone can start a Tor exit relay, and setting up a MITM proxy on it is trivial".
Tor project has a project that sends out probes to identify rouge nodes, so the trivial and obvious form of MITM that changes data en-route are equally trivial caught and blacklisted. People should still be aware that sending secret data in plaintext on any network is a bad idea tm, but any security analyst need to incorporate the whole picture.
" Many of these details do not appear
in any specifications and were obtained by a careful analysis
of the corresponding source code. This is especially true for
Bitcoin for which there exists no official documentation except
for the original white paper [14] and Bitcoin Wiki[3]."
Also, the Bitcoin Wiki itself is a fairly comprehensive source of documentation (and covers most of the information in the "official" documentation). It even includes an informal protocol specification[1]. It's been around for a very long time.
That said, the information they're referring to is Bitcoin's Tor support (like recognizing OnionCat addresses). I don't think there is much documentation on this specific topic. However, Bitcoin is an open source project and I'm sure any related documentation contributions would be welcome.
You have no idea how deep that rabbit hole goes. Bitcoin Core is referred to as a "reference implementation", which means "you should implement all bugs referenced by Bitcoin Core in transaction verification, or you have your choice of being kicked off the Bitcoin consensus immediately, which is bad, or at any point of an attacker's choosing, which is catastrophic."
In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable.
Another interesting case is when bitcoind 0.8 changed the underlying database from BerkeleyDB to LevelDB. Due to different database lock limits, bitcoind 0.7 couldn't process a block that bitcoind 0.8 could. For 6 hours, there was a fork where old clients were using a totally different blockchain than new clients, because of this single block they couldn't handle. This is what patio11 means, that you have to be bug-for-bug compatible with the reference implementation.
> In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable.
That was in 2010. Most of the users take certain level of risk, also different kinds of people have different risk appetite. If you really think this is still a relevant risk, then probably you shouldn't use cryptocurrencies at all. Stay with the safe and proven almighty dollar.
The right mindset to understand the requirements of Bitcoin client design is, I think, that of someone trying to clone an online game client (e.g. Starcraft) in a way that doesn't experience network state desynchronization. You can do whatever you like in your client UI-wise, but the "rules engine" of your implementation absolutely must reduce an incoming event stream into the same world state as the reference implementation.
For this kind of problem, the easiest solution (when possible) is to extract the "rules engine" component of the reference implementation into a library, and then have every other client just use it (and maybe contribute to its development) instead of trying to write something bug-for-bug compatible with it.
When you think about it, web browser rendering has much the same implementation-consensus problems as Bitcoin. And what do we see there? Everyone sort of converging toward just using the "rules engine" known as WebKit.
That's the way a blockchain works though. If there is a bug in the client that 99% of people use then of course you'll have forking blockchains. And all of this matters less anyway, because clients can fallback to blockchain.info if there is a fork detected, and just warn the user that the client may have a bug.
The point is that it is a trusted enough party. If the client gets a suspicious block it can check against that party as a way of seeing if the client itself may have a bug.
Saying I was writing a bitcoin client I would never use some 3rd party as a fallback. As soon as a blockchain fork is detected you stop all transactions and wait for it to be solved by the miners. No other way around it.
Everything known about Bitcoin comes from people directly reading the source code. That's all that was originally released next to the paper. Everything since then has been based on careful review of the source code and writing additional documentation from that understanding.
Edit: the documentation (that your reply is referring to) exists now because people spent the time reading the source code. This documentation didn't exist originally.
The part that seems odd to me is that with all these developers, students, researchers, and curious users nobody documented it according to the paper. Which as stated by another user doesn't seem to be the case.
Documentation produced that way is actually consistent with the statement you first quoted. I think what is happening here is that the researchers, being properly careful, verified what the software does, rather than trust to descriptions by others.
If there had been a formal specification, I imagine they would have both analyzed the specification for vulnerabilities, and checked the code for correct implementation.
Tor and Bitcoin hide fundamentally different things in their pseudonymity specs. It's like people think Tor is magic anonymity peanut butter they can spread on whichever project they wish.
In fact Bitcoin design does not contain elements hinting that anonymity was ever a goal. People using Bitcoin over Tor might just want to circumvent censorship aka Tor as glorified proxy.
If I understand the paper correctly, you can't rely on Tor for that either. You can disable other Bitcoin peers on the Tor network:
> It turns out that by exploiting a Bitcoin built-in reputation based DoS protection an attacker is able to force specific Bitcoin peers to ban Tor Exit nodes of her choice.
Section VII lists some countermeasures.
Very happy to see academics having an increasing interest in this area.
There is a project that uses stenography to hide the Tor protocol from inspection. I need to tie up a few loose ends to some of my branches for it (I am not the originator, just a contributor) but have gotten caught up in schoolwork these last few months. Any assistance is appreciated!
Cool, I'll check it out. I was thinking more along the lines of hiding messages in the Tor protocol itself, rather than hiding Tor traffic (which is desperately needed.)
This is interesting in that it highlights a number of problems that every peer-to-peer network that wishes to use something like Tor for privacy needs to take into account.
I also wasn't aware that Tor hidden services can be "blackholed" so easily (it sounds like this is probably well known to regular Tor users, though).
This reminds me of the recent (~2 months ago) addition of a new, very fast Tor relay (faster than any other relay at the time) that only relayed Bitcoin traffice [0].
Wonder if that has anything to do with this research, or if someone else has independently arrived at the same result?
What worries me most about Tor is that people do not realize how trivially an exit relay can MITM your traffic. The value proposition of Tor is NOT keeping all your traffic safe. It's anonymizing your traffic from end to end, so that nobody who sees your data knows both where it came from and where it's going. They can still see the data itself.
For all intents and purposes, traffic from Exit -> Internet is plaintext. The relay operator can MITM it. Tor is only safer than a VPN or proxy because the exit relay does not know your identity. It can still access the data you transfer through it. [4]
Anyone can start a Tor exit relay, and setting up a MITM proxy on it is trivial. Siphoning bitcoin transactions is equally trivial. Just listen for the proper traffic patterns.
You should not be transferring any business-critical data over Tor. It's a great tool for protecting your identity, but not your data.
With HTTPS, you're relatively safer, since you'll get an alert if a relay is MITM'ing you and modifying the certificate. But with plain HTTP, you won't even know when you're getting MITM'd.
More Resources:
[1] http://security.stackexchange.com/questions/34804/how-safe-i...
[2] https://blog.torproject.org/category/tags/mitm (includes links to research papers)
[3] https://www.petsymposium.org/2014/papers/Winter.pdf
[4] Emphasis on "for all intents and purposes." Not a true statement universally.