Transport Layer Security

[r14c]

Currently peer-to-peer communication occurs over insecure sockets. Wrapping these sockets in SSL is done via ssl.wrap_socket, the resulting object has most of the same methods as a standard socket.

Each peer could generate and self-sign a certificate and be configured to accept any certificate that it is presented. (We don't really care who we're connecting to as long as its over a secure channel, for now)

[fiatflux]

Is there reason to be concerned that this would vitiate the ability to hide behind multiple IP addresses, e.g. via tor rerouting? An ssl cert is a pretty darn strong signature. (For multiple uses of the term "signature"!)

[r14c]

Since we'd be generating and self-signing them anyway we could have them expire and replaced every few hours (and on-demand) that way you aren't identifiable by your cert but communication is secure.

This could be implemented so peers connecting via Tor (and anyone else who connects with yellow status) wouldn't need to present a certificate, they would just need to accept the one presented by their peer.

[ghost]

Sounds reasonable. I assume that this might also help to avoid BM traffic being explicitly recognised and blocked.

[fiatflux]

@xj9, I like the no-cert option for Tor users. It's not satisfactory to Tor users, of course, to regenerate certs even a hundred times a second (since overlap between sessions is fairly likely). Speaking of which, I think we're already vulnerable to tracking between Tor circuit switches since an open socket on one one Tor circuit will continue the same communication on the new Tor circuit. It's trivial to notice, for instance, when acks come from a new IP. I'm not familiar enough with Tor to know if there's a "right way" to mitigate these sorts of attacks.

[DivineOmega]

Perhaps it would be worth generating a new self signed SSL certificate for each new connection to prevent any form of identification via its signature?

[fiatflux]

That sure would help a bit, but there can still be overlap between Tor circuits, eh? How can we terminate the connection, TLS or not, when Tor creates a new circuit?

[DivineOmega]

I do not think Tor attempts to route open connection over multiple circuits. My belief was that once a connection was open it stayed on the same circuit until it was closed. I am not certain how it could work any other way.

Am I misunderstanding something?

[fiatflux]

D'oh. As you can tell I hadn't actually thought about how that could happen. In that case I like your idea for a new cert per connection tinfoil-hat mode.

[DivineOmega]

Great. I would probably put forward the idea that tin foil hat mode, as you put it, should be the default and primary way we go ahead with this. :-)

[fiatflux]

Always :-)

[r14c]

Yellow status peers can only make outgoing connections (this includes Tor users and anyone traversing NAT) so they don't actually have to worry about generating new certs because TLS supports server-only authentication.

It could even be the norm that the peer initiating the connection only has to validate the cert presented by the peer being connected to but not present a cert in return.

@DivineOmega I like the idea of per-connection certs.

[DivineOmega]

@xj9 I like your idea of the server element being responsible for the generation of SSL certification, and the client element being responsible only for verification of the SSL certificate presented to it.

[Dokument]

I like the idea of the server being responsible for the certification as well.I am also for the idea of generating a new cert for every connection, when the connection dies, delete the cert.

[Atheros1]

By 'server' do we mean the node receiving the incoming connection? If so, could we have the node sending the outgoing connection be responsible for generating the cert? I would prefer to not put that load on the nodes being kind enough to allow many incoming connections.

[Dokument]

I took it to mean the node initiating the connection. So if I am connecting to you, I generate a certification.

[DivineOmega]

@Atheros1 Yes, by 'server' I meant the code which handles incoming connections. You make a good point however, the server's are generally more busy due to increased numbers of connections. In this case, although it is unusual, as you suggest for performance reasons, it may be better making the 'client' code to generate new certificates (one per connection) and the 'server' will merely verify them.

[r14c]

I've created a rough implementation of this, the problem I'm running into is allowing non-secure connections. Everyone drops me because I'm trying to negotiate a TLSv1 connection when they expect whatever it is that Bitmessage uses. (Its just a raw socket, right?)

[DivineOmega]

@xj9 Perhaps wait until after the initial handshake is complete. You could then use a different protocol version to determine whether or not to wrap the secure socket.

[Atheros1]

@xj9 The 'version' message used to initiate a connection contains 8 bytes of 'services' of which we currently use none. If you want, we could have the least significant bit mean that the node supports SSL. Though it would be a little more difficult for oppressive governments to block it if the connection was SSL throughout, including the version message, and would likely be simpler to implement. I would be Okay (and happy) eventually putting code in master which sends out only SSL connections. We can accept both SSL and non-SSL incoming connections.

[tameit]

Comming from #648 @styoyo:

If all this can be simply avoided by using encryption between peers like AES with DH Key Exchange - why isn't it just implemented and that is it.

Unfortunately IMO it is not that simple. DH Key Exchange has a man-in-the-middle attack. If, like suggested here nodes just sign their certificates themselfes "verification of the SSL certificate" is as far as I can tell useless because the attacker can just generate and sign his on certificate and the receiving node can not tell the difference. Or am I missing something?

Obviously it cannot make anything worse if we will use encryption between peers. All peers should upgrade to latest version and talk encrypted to other peers.

Adding encryption may leed to a false sense of security. In this case it would prevent a passive eavesdropper from determining the source of a message. For an attacker who man-in-the-middle attacks every connection of a node it would still be possible.

[godel9]

tameit: So, what are you saying? That we should do absolutely nothing to protect anonymity? Because it seems to me that without protection of public key look-ups Bitmessage is well and truly pwned.

EDIT: on a more constructive note, take a look at TARZAN's implementation of a peer-to-peer PKI for potential ideas.

[stevedekorte]

It's not clear to me how SSL secures you against a man in the middle since the "man" may well be running any number of the nodes you are connected to. The only real protection I can see is either posting with Tor or developing some form of onion routing within the Bitmessage network itself (and even those options are only probabilistically secure with some assumptions about how much of the network is compromised/malicious). Am I missing something?

[godel9]

stevedekorte: It wouldn't protect against sophisticated MITM, but it would make it more difficult. And it would at least reduce the threat of passive traffic analysis as an attack vector. Adding SSL means the attack goes from monitoring a single node's traffic to MITM attacks on EVERY peer connection with that node, which is an order of magnitude harder.

onion routing would theoretically work, but you NEED to look at the literature. There are papers on this very subject dating back to the early 80s, and ignoring them does the entire BM community a great disservice. Great examples of peer-to-peer protocols for encryption and anonymity include TARZAN and MorphMix. Take a look at http://www.cs.dartmouth.edu/~ccpalmer/classes/cs55/Content/resources/JohnsonKapadiaSurvey.pdf for more information.

EDIT: to be clear, onion routing would make sense for delivering public key requests and the like, but sockets between peers MUST have some form of TLS.

[louy2]

Excuse me if I am wrong, but if my message is encrypted in whole so that only my recipient understands the data related to it (as long as the private key is intact) and the system is designed so that all clients receives all messages, what's the point of using other certificates along with TLS? All clients are MITM anyway in a P2P system like BM.

[stevedekorte]

This only hides the origin if the nodes you post the message to can safely be assumed to neither be adversaries or compromised by adversaries. AFAICS, the only solution here is an onion system for posting which only assumes some percentage of the network is not compromised (the deeper the onion, the higher that percentage can be). We can use Tor for now, but how about building an onion router into the BM network itself?

[stevedekorte]

@millerkil, they can't directly but it is a hint and if they have some set of nodes these can accumulate to point to strong suspect IPs which could then be targeted for warrants. I'd agree SSL is helpful. Would you agree that an onion router would also be even more helpful? e.g. If you had to bet your life on the anonymity of your communications and had to choose using a system that only supported one of these, which would it be? In either system, I'd agree delays are important. I'd also agree that SSL and delays are the right place to start - my only point is that they aren't sufficient.

[stevedekorte]

@millerkil, I agree better Tor support is sufficient for now and would be more useful than SSL. The problem atm is that it looks like using Tor isn't limited to posts and that seems like it might be a performance/scalability issue.

[godel9]

@millerkil @stevedekorte peer-to-peer object sharing would not actually get anything from using Tor, other than obscuring the location of a node's peers, which does not help against this vulnerability. Even if you used Tor, you would still need SSL to encrypt the conversation. Onion routing is not some magic word you can throw around to fix every vulnerability. Onion routing provides anonymity: not encryption.

I have to be honest, I'm very disappointed in the lethargy in the BM community. Thanks to this vulnerability, which has been known for nearly a year, I can break the anonymity of a BM node with fucking Wireshark! And this is just one of several severe vulnerabilities that have been uncovered, and the BM community doesn't seem to care

[godel9]

@millerkil Messages are already encrypted, but other objects (like public key requests and public key responses) are not, which leads to some very simple attacks through passive traffic analysis. Simply monitor the objects entering and leaving a node: an object sent out by the node that did not first enter the node must have originated there.

If Tor provides complete two-way anonymity, why even bother using the peer-to-peer scheme of BM? You could just use Tor hidden services to directly send the message to the recipient without making it propagate through the peer-to-peer network. Using Tor in addition to SSL only serves to obscure the peer list of a given BM node, which I haven't seen used in any attack vector model. If you can explain an attack against BM that using Tor would protect against I would be very interested in hearing about it.

[godel9]

@millerkil I'm confused: is your proposal just to route peer traffic through Tor? If you're just going to use Tor hidden services, what advantage does BM give you over, say, TorChat?

Can we at least agree that the protocol, as it stands, is completely vulnerable? Adding SSL is like a dozen lines of python, I don't understand why people are dragging their feet on this.

[stevedekorte]

Are we agreed that we only need Tor for posting (not for all communication) to protect anonymity and to use a random and significant delay when doing automated responses to solve the security issues raised here? Am I missing something?

[godel9]

@stevedekorte By posting, do you mean sending the actual emails? Because, no, that's not necessary: BM's message propagation scheme is actually theoretically stronger than Tor's, if not as scalable. The delay is more worrisome as it opens the potential for a malicious user to deny service to a given peer. If I keep generating public key requests faster than the peer can respond (which is made easier by introducing delays), I can effectively degrade the service to the point that no one can get that public key. However, I'd be content with using delayed responses as a temporary fix, because a real fix will require a deal more work. And using secure sockets is still a must, because it's essential that you attempt to hide the originator of objects.

[stevedekorte]

@godel9 Consider the case of someone sending many posts to a public channel. Can't a party with enough nodes associate a sender BM address with an IP with reasonable certainty over time? Also, would having the user approve each request (optionally blacklisting any denials) for full public key prevent that attack?

[godel9]

@stevedekorte Yes, that is a valid attack, but then I don't see much point in using BM at all if we are using Tor hidden services. Why not just re-implement TorMail with PGP and BM addresses and call it a day? That would actually be a very powerful system, but it's completely unlike BM.

As for the user approving thing, these isn't much you can do there. There is no way to identify the source of a public key request from the payload itself (check the protocol specification), so by what criteria could a user determine which requests are valid and which are not? If we implemented this, and you suddenly received an abnormally large number of public key requests, what do you do?

[stevedekorte]

@godel9 "Why not just re-implement TorMail" There are many reasons but the biggest is channel support, which I suspect will be seen as the most important feature of BM in time.

[godel9]

@millerkil @stevedekorte My point is why use peer-to-peer propagation of messages if we can access the peer directly with Tor hidden services? The TorMail comment was hyperbolic: what I meant was that there is little point in building an entire peer-to-peer anonymous infrastructure when Tor hidden services already provides it.

At this point, I'm tired of arguing. If you want to implement this Tor support thing, you are more than welcome. I, however, want SSL support (which is trivial) because I think we can all agree the current system is dangerously flawed, and I don't understand why this problem persists.

[stevedekorte]

@godel9 "peer-to-peer anonymous infrastructure when Tor hidden services already provides it" Are you saying Tor supports anonymous public channels? If not, then there is one very important reason why we still need BM regardless of whether we use Tor for posting. I also support your suggestion of adding SSL and I agree that it would be ideal if we could avoid Tor with onion routing within BM but AFAICS we need some form of onion routing because SSL alone won't protect us from address to IP association.

[godel9]

@stevedekorte public channels are just an abstraction over anonymous connections, using a secret sharing algorithm: they can be implemented anywhere you have simple two-way anonymous communication.

[stevedekorte]

@godel9 what is the Tor broadcast, caching and POW mechanism? Or are you talking about reimplementing a system on Tor that has all of these BM features?

[godel9]

@stevedekorte I'm saying I think BM should either be entirely based in Tor or not depend on Tor for anonymity at all. But I'm done: I just want SSL.

[pjf]

Long time lurker, first time poster. :)

+1 for SSL, which I hope is straightforward to implement, and valuable regardless of what others changes are made.

[merlink01]

+1 Why not?

Better Security is always better!!!

[tameit]

@godel9 Can we at least agree that the protocol, as it stands, is completely vulnerable? No. That would depend on your definition of "complete". It keeps messages confidental. It does not authenticate the sender of messages (replay-attacks are possible). Anonymity of a sender (if messages are acknowledges also the receiver) is not claimed to be secure. However since version 4 public-keys and pub-key requests are encrypted. See https://github.com/Bitmessage/PyBitmessage/blob/master/src/class_singleWorker.py l. 297 ff., and l. 883 ff.

[tameit]

@godel9 Adding SSL is like a dozen lines of python, I don't understand why people are dragging their feet on this.

Go ahead, send a pull request. I'm quite sure it will be merged pretty soon.

But then make sure all BM-users use a recent OpenSSL version as yestersdays current version had a bug which may reveal the server/senders secret key: heartbleed.com

[n4rky]

On Tue, Apr 08, 2014 at 01:24:40PM -0700, tameit wrote:

But then make sure all BM-users use a recent OpenSSL version as yestersdays current version had a bug which may reveal the server/senders secret key: heartbleed.com

How are you going to do this? Sabayon, for example, released 1.0.1g, but Debian and CentOS packaged patched versions of 1.0.1e.

David Benfell benfell@parts-unknown.org See https://parts-unknown.org/node/2 if you don't understand the attachment.

[godel9]

@tameit the version 4 changes do nothing to solve the message origination problem. If I want to know what messages a node is making (not just passing on), I examine the messages coming in and the messages coming out and take the logical difference. No amount of message-centered encryption will stop that: you need encryption at the socket layer.

[gits7r]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 4/12/2014 11:27 PM, godel9 wrote:

@tameit https://github.com/tameit the version 4 changes do nothing to solve the message origination problem. If I want to know what messages a node is making (not just passing on), I examine the messages coming in and the messages coming out and take the logical difference. No amount of message-centered encryption will stop that: you need encryption at the socket layer.

— Reply to this email directly or view it on GitHub https://github.com/Bitmessage/PyBitmessage/issues/264#issuecomment-40290928.

If this is recommended and easy to do, why doesn't anyone commit to write those lines of code?

if it provides enhanced security, my vote is hell yes for it. Already more and more people see in Bitmessage a good private and anonymous alternative to regular email.

What I can't understand is how will you implement SSL/TLS in peer to peer network? SSL/TLS by design isn't trustless between peers, third parties are needed so what is the solution (in simple words)? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBCAAGBQJTSaS/AAoJEIN/pSyBJlsRIZYH/A10R46Fp0sq6E9BAyK0ZI7J AibF4m0iVMfpAqXSxbYVZxr2uyU8HApJby4r08lVLbuAuRBmuJnphM/yCFA/v17W kXi48OmvVCAafALIxagUB5nxdKEegSFukkZ5LIRLJjOz3hmjBbPQStncCNu2XoxX xJtqAJdTq0O9xtjVreHzirFWymAcTSxdDFVZStRnf0+F8YciG598DhPFYijB900T 2H3Ad84dFcAMdnoeZyB8BCPqDZEqoKConmZbgTkTxEHKaqqt95yLQvkm4tZx/L41 rWnsnvrPM0ApB2oJ2LM4dOAGF3DaN7D1zkiz8txJ3P1V8j9HTkiZ+B5rUkItLLI= =jWxM -----END PGP SIGNATURE-----

[godel9]

@gits7r The only "trustful" component is the certificate authority. We can manage the distribution of certificates using the peer discovery method. It shouldn't require much work assuming peer discovery is already secure, though I haven't had a chance to look into it yet. If not, we need to secure the peer mechanism to prevent Sybil attacks anyway.

[marcelklehr]

The raw bitmessage protocol (as I understand it)

1. does not prevent a passive adversary from learning that someone is using bitmessage (since the bitmessage protocol is simple to detect)
2. keeps messages confidental
3. does not authenticate the sender of a message (since replay-attacks are possible).
4. does not protect the sender's anonymity (since a passive adversary can do outgoing - incoming = originating)
5. protects the receiver's anonymity (since everyone receives all messages)
6. prevents an attacker from learning the IP address to a BM address (since a passive adversary can learn my pubkey tag, but not the associated BM address if the latter is communicated securely)
7. does not prevent an attacker from learning a node's contacts (since a passive adversary can keep track of version 4 pubkey/getpubkey "tag" fields)

(6 only holds if version 4 pubkey messages are used, since the actual key is encrypted with a key-pair derived from the BM address. This is not a comprehensive list. Receiver anonymity (5) could be compromised by observing an "immediate" acknowledgement reaction using statistical traffic analysis. In order to fix 4 and 7 a Tor-like relay system would have to be employed, which is hard to get right as there's no confidential way to learn random BM addresses, right now, afaik.)

Using TLS between peers only slightly mitigates 1 by wrapping the BM protocol in TLS. However, it won't add any other kind of security, since you can't trust anyone in an open peer-to-peer network: An attacker could connect to you impersonating many peers to get hold of your BM traffic (Sybel attack), or they could use a Man-in-the-middle attack on TLS level -- since you "don't really care who [you]'re connecting to as long as its over a secure channel".

[stevedekorte]

@marcelklehr Exactly. Now what does that list look like if Tor is used by nodes to transmit any messages they created?