Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage


I think that there are factors that people tend to overlook and it leads to frustration and questions such as: "I can do X easily in my cloud environment, why is it so complex to do it in Fabric?"
  1. Blockchains are often deployed in a non fully trusted environment where parties might even be competitors, and have incentives to be covertly malicious.
    This means that you can't assume the existence of a system that has a centralized administration.

    Sure, you can deploy Fabric in a setting where you have an organization that is trusted to perform some functions correctly (did anyone say Crash Fault Tolerant consensus ? ) if the parties in the network agree to it,
    however you wouldn't want a Blockchain project to depend on such a thing because it would severely limit its usefulness and would reduce the business problems it can solve.

    As a direct consequence, there are some things that are easily done in the cloud but are much more complex to do in Fabric, an obvious example would be - you need the consent of several parties to approve policies, and a non obvious example would be, that if you got a "discovery protocol" message from a party (say party A), it is possible that you can't just naively forward it to party B (as is implemented in many cloud native products), because it might be that party B should not even know the fact that you have a business relation with party A in the first place.
  2. It's true that nowadays it is very common to containerize everything and run it on Kubernetes, however to maximize adoption, Fabric should be deployable in every setup: Bare metal, docker compose / swarm, k8s, and the next cloud orchestration engine that is going to come out next year as well.

    Now, since not every user is a security expert, Fabric has to have built in security to protect itself so it can run in the simple primitive deployments where you don't have an Istio mesh to control which containers can communicate and which can't.

    So, these security mechanisms are sometimes not easy to integrate with your advanced environment, but there are efforts to make Fabric more cloud friendly (such as the server-side chaincode model, and the latest external builders which is supposed to give administrators more flexibility in how the chaincode is being run) .
- Yacov

From:        "Brian Behlendorf" <bbehlendorf@...>
To:        fabric@...
Date:        10/31/2019 09:19 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...

Would libp2p be helpful here?  I had a conversation with someone about how other blockchain projects use it to abstract away some of the issues with using gossip for networking between nodes and how it simplifies the dev experience. 


On 10/31/19 11:43 AM, Nye Liu wrote:

Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".

On 10/31/2019 11:38 AM, Alexandre Pauwels wrote:
You should be able to leverage coredns rewrites to avoid hairpinning traffic.


On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:
Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g.

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.


On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:
I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@...wrote:
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...>wrote:

If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.

10/31/2019 03:27 PM
[EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        

Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
Do you have solution for such issue?
Thank you all

Brian Behlendorf
Executive Director, Hyperledger
Twitter: @brianbehlendorf

Join to automatically receive all group messages.