问题
Let's take the scenario of 3 equitable organizations, i.e., each organization runs peers and should be equally involved in the ordering process.
For me, it feels quite natural to configure those 3 organizations to have an orderer node and some peers, each. However, this setup is highly discouraged. Quote from the FAQ:
Question: Can I have an organization act both in an ordering and application role?
Answer: Although this is possible, it is a highly discouraged configuration. By default the /Channel/Orderer/BlockValidation policy allows any valid certificate of the ordering organizations to sign blocks. If an organization is acting both in an ordering and application role, then this policy should be updated to restrict block signers to the subset of certificates authorized for ordering.
In another SO question, one answer gave a little more detail on this topic:
First, it's very easy to misconfigure your policies and reduce the security of the system significantly. The ordering service and the application operate based on the principle of separation of powers. It is important that ordering nodes cannot fabricate authenticate transactions, and it is likewise important that application transactors cannot fabricate blocks.
And continues with:
Second, because the MSP definition must appear in both sections of the channel config, you end up with two identical copies of the MSP definition, which must be kept exactly in sync. Since both MSPs have the same ID, if the contents are not exactly the same, then it creates an ambiguity in evaluating identities.
I scratched my head for the whole night thinking about which attack vectors and actors could expose a potential security risk for my organization or the whole network, if this setup is not properly configured.
Unfortunately, I can only think of one scenario: If there would be a vulnerability in the orderer binary, another organization's orderer could exploit this to create transactions with my organization's identity.
Question: What attack vectors can be exposed, if you have peers and orderers in a single organization and it's not configured correctly? Who would be the actors? Clients, admins, other organizations of the network, complete outsiders?
Bonus question: What is the proposed alternative in the given scenario? Should each participating organization been split into a separate peer and orderer organization? Like Company1PeerOrg, Company1OrdererOrg, Company2PeerOrg,...?
回答1:
Question: What attack vectors can be exposed, if you have peers and orderers in a single organization and it's not configured correctly? Who would be the actors? Clients, admins, other organizations of the network, complete outsiders?
For normal transaction flows, there are essentially three party types which are required to sign before the transaction may commit.
First, is the submitter, or client, who requests the endorsements, creates the transactions, and sends it to ordering. In general, clients fall into the category of Application Writers. They are authorized to invoke peer APIs, and orderer Broadcast.
Second, is the peer(s), which execute the transaction, and produce the transaction result. The peer knows the world state at the time of execution, and the business logic associated with the invoked chaincode. The peer signs the result of execution to attest that the business logic was executed correctly. Peers generally fall into the category of Application Reader, as they need to see all transactions in order to keep their world state current (so they may execute in aid of producing new transactions).
Finally, is the orderer(s), which establish a total order for the transaction, put it into a block, and then sign to attest that consensus was achieved on the order, and that the peers may consider this transaction's order to be final. Orderers fall into the category of Orderer Reader and Writer, as they replicate existing chains, and append to them.
So, onto your question, what can go wrong if these roles get conflated. If an identity is miscrafted, or policies are miscrafted such that a single identity can satisfy all of these roles, then it becomes possible for that identity to craft a double spend attack.
Loosely architected, because this identity qualifies as a client, it can create two valid looking transactions, one that sends $5 to Alice, and another that sends that same $5 to Bob. Ordinarily, the transactions are sent to ordering, receive total order, and the first one wins. However, because this identity can act as an orderer, it can produce two valid-looking blocks with the same block number, each one containing one of the transactions. Now, without a valid TLS server cert, the client has no way to inject the block into the system as an orderer, but, if the identity is a peer, then it can now try to inject the block into the network via the gossip facilities. If two different peers can be tricked into adopting the two different falsified blocks, then those peers will each be under the impression that the tx they saw is valid. And, you have now produced a double spend. (Of course the network will eventually detect the fabricated block, and this can be attributed, but the damage has been done.)
There are potentially other novel attacks, but hopefully this demonstrates how having a single identity fulfill all three roles is problematic. In Fabric v1.0, the only roles were "Admin" and "Member". So at this time, it was absolutely critical that the ordering org, and the application org not overlap. Then the role of "Peer" was introduced, and finally later "Orderer". These new roles make it easier to craft policies to keep your network secure, but it's still safer to split these organizations at the CA level than at the role level.
Bonus question: What is the proposed alternative in the given scenario? Should each participating organization been split into a separate peer and orderer organization? Like Company1PeerOrg, Company1OrdererOrg, Company2PeerOrg,...?
Yes, simply having a logical ordering organization and application organization for each member is recommended.
来源：https://stackoverflow.com/questions/62465126/why-is-it-highly-discouraged-to-be-an-application-and-orderer-organization-at-th