-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Threat model of python-obelisk #16
Comments
Also, as a side-node, is the communication between the obelisk server and client encrypted and authenticated? And based on what model? |
Hi @dionyziz. You can think of Obelisk as a full P2P node with another protocol. It's model is that of a peer. Because the protocol differs its susceptibility to DOS may differ. You should always assume that any Bitcoin node you connect to is hostile - attempting to do whatever it can to steal your money and privacy. In your context, necessary threat modeling can only be done at the client - the code that the user actually controls and can verify. We have produced a new protocol design for next generation Obelisk that places a high priority on privacy. This means that it makes it more efficient for callers to protect their privacy, not that the server is more secure or private. At the end of the draft there is a short discussion on client security models. More information can also be found on the Bitcoin wiki. Fake transactions can definitely be given to a caller. Only an SPV or full chain client can detect invalid transactions and only the full chain client can detect missing valid transactions. There is no way to prevent this without trusted code (and hardware for that matter) verifying the chain. |
Obelisk client-server communications are carried over ZMQ and have the option to use Curve ZMQ. This is a modern and efficient privacy layer that is much simpler than SSL/TLS and uses elliptic curve keys. Like SSL/TLS it can be used to strongly identify a server (using knowledge of its public key) and encrypt communications in a session. Clients can be authenticated as well, but key distribution is always the issue in client authentication, and in the world of Bitcoin there isn't generally much call for it, and can also complicate servers and hinder scalability. So encrypted - yes, if you want. Authenticated - yes, if the server publishes a public key it can be authenticated. |
@dionyziz I should emphasize that above I am referring to Obelisk and not specifically to DW or Python-Obelisk. |
HI @evoskuil, Do you (or anyone) know if Python-Obelisk provides authentication and encryption though? I didn't find anything relevant in the docs or in the tests about this. |
@sophron AFAIK, no. The library communicates via ZeroMQ, in which several options are available. To my knowledge, none of them are used. (Need confirmation, though.) |
@sophron Let's see if we can PR this? On Mon, Sep 22, 2014 at 8:48 AM, Noel Maersk [email protected]
|
I don't know. These don't seem all that production ready at all. I know there is a lot of progress being made on CurveZMQ though not sure on a release. |
CurveZMQ is an external library meant for use with ZMQ 3. Curve is integrated into ZMQ 4. See home page: Implemented in ZeroMQ 4.x for point-to-point security. Obelisk supports secure transport using ZMQ 4, which is based on CurveCP and NaCl (via libsodium). |
Yeah I saw that earlier and will be testing it out with OpenBazaar soon. I will report back my findings. |
As python-obelisk is a core part of OpenBazaar, I wanted to inquire about the threat model behind the obelisk protocol and how much of it is inherited in the python-obelisk client. In particular, how much trust does the python-obelisk client give to the obeliskd, and what is the server capable of doing under these assumptions?
Clearly, a malicious obeliskd could deny service. However, is it possible that they fake transactions, transaction amounts, and generally respond with inaccurate data in a way that the client isn't able to detect?
Thanks for your input.
The text was updated successfully, but these errors were encountered: