Uploaded image for project: 'Fabric'
  1. Fabric
  2. FAB-7559

Move ordering service endpoints into OrdererOrg groups

    Details

    • SDK Impact:
      No
    • System Test Impact:
      Yes
    • Documentation Impact:
      Yes
    • Release Note Required:
      Yes
    • Release Note:
      Hide
      Starting from version v1.4.2, it is possible and highly recommended to define orderer endpoints at the organization level and not at the global channel level. If at least one organization has an ordering service endpoint defined at an organizational level - all orderers and peers will ignore the channel level endpoints when connecting to ordering nodes.
      Starting in v2.0 orderer endpoints must be specified at the organization level and not at the global channel level.
      Show
      Starting from version v1.4.2, it is possible and highly recommended to define orderer endpoints at the organization level and not at the global channel level. If at least one organization has an ordering service endpoint defined at an organizational level - all orderers and peers will ignore the channel level endpoints when connecting to ordering nodes. Starting in v2.0 orderer endpoints must be specified at the organization level and not at the global channel level.

      Description

      Summary

      Move ordering service endpoints from channel global configuration into the organization specific OrdererOrg channel configuration, so that orderer organization(s) can manage their own endpoints, and so that clients know which organization's TLS certs to use per orderer node.

       

      Background

      Currently, the ordering service endpoints are encoded in:
      channel_group.values.OrdererAddresses with a modification policy of /Channel/Orderer/Admins which by default (I think) is majority of admins.

      In a production environment the peer uses TLS to connect to the orderers and always loads the TLS root CAs of all the orderer organizations (since they are not defined per organization but globally).

      This has several issues:

      • If an organization wants to change its ordering service endpoint (due to, for instance - a firewall / NAT rule change) it needs to do out-of-band collaboration for signature collection and human authorization.
        While in contrast - to do an anchor peer config change you need only to collect signatures of your own organization ( Jason Yellick please correct me if I'm wrong).
      • In the current (v1.0, v1.1) adversary model, the ordering service organization isn't byzantine so this is not an existing security vulnerability but it could be a problem in later releases when the trust assumptions would change (i.e when BFT consensus will be introduced).
        If we would want to support use cases in which an ordering service node can be byzantine, it makes no sense (in my opinion) that the peer would just select a random ordering node to pull blocks from and persist the connection forever, because the ordering node may simply not send the peer blocks and thus starve it, so I think that peers should either:
        • Connect for a limited duration to an ordering node, and after a time period expired - switch to a different ordering node, or:
        • Just have each peer connect to ordering nodes of its organization.
      • However, I think that even if we do one of the above, the current channel config would then expose the peers to starvation attacks:
        • Imagine 4 organizations- AliceOrg, BobOrg, CynthiaOrg, DanaOrg with corresponding 4 (f=1, n=4) ordering service nodes (Alice, Bob, Cynthia, Dana) that run BFT consensus and with corresponding CAs: (AliceCA, BobCA, ...)
        • The channel config has 4 ordering service endpoints:
          • alice.AliceOrg.com
          • bob.BobOrg.com
          • ...
          • ...
        • AliceOrg is an adversary of the rest of the organizations, and she wants to starve the channel from blocks without them being able to detect that something is amiss.
          AliceOrg makes AliceCA create TLS certificates with SANs that match not only alice.AliceOrg.com but also bob.BobOrg.com, cynthia.CynthiaOrg.com, dana.DanaOrg.com and updates the TLS server certificate of alice (the ordering node of AliceOrg).
        • Next, Alice performs either a BGP hijack or a DNS poisoning or any other infrastucture-directed attack and makes the peers of all organizations to always connect to alice.AliceOrg.com.
          The TLS handshake the peers would perform would succeed, because they would trust the certificate presented by them by alice.AliceOrg.com orderer node because it would contain all SANs of all organizations of the channel, and would be signed by a CA (AliceCA) that is in the (per channel) root CA certificate pool of the peer.
        • Had the ordering service endpoints been configured per organization, the peer could only load the TLS root CA certificate of the corresponding organization, and then in case Alice performed the network traffic hijack, the TLS handshake would have failed when connecting to alice.AliceOrg.com ordering node, and the peers would complain in the logs that ordering service nodes could not be contacted for a long time, and the infrastructure team could be alerted in such a case.

      So, I suggest that for v1.2 we move the endpoints to be configured in a new place, under each organization, and in case they are not configured at that place we could perhaps fallback to the old location

      Opinions? Jason Yellick , Kostas Christidis , Gari Singh Artem Barger
      Elli Androulaki Alessandro Sorniotti Angelo De Caro ,
       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jyellick Jason Yellick
                Reporter:
                yacovm Yacov Manevich
              • Votes:
                1 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Git Source Code