1. 01 May, 2018 1 commit
    • Alessandro Sorniotti's avatar
      [FAB-6381] Secure defaults for txsFilter · 53de0781
      Alessandro Sorniotti authored
      
      
      The aim of this change set is to apply the well-established "Secure by
      default" security principle to the way the validator validates transactions
      in a block.
      
      The current code behaves as follows: create an array of validation codes, set
      by default to "all transactions are valid"; then perform validation which may
      mark transactions as invalid. Furthermore, in other parts of the code, if no
      array of validation codes is yet persent in the block, a new one is
      indiscriminately created (again, marking all transactions as valid). This
      approach is a security anti-pattern because it opens up to attacks where an
      adversary may force the code through a path where the default "tx is valid"
      validation code is maintained even for invalid txes.
      
      This change set ensures that validation code arrays are created and set to a
      new value (TxValidationCode_NOT_VALIDATED) which ensures that a transaction
      that hasn't been validated cannot be mistaken for a valid one.
      
      Change-Id: I5dbb18dd77af3cd14b168042ae660e4e27bf29dd
      Signed-off-by: default avatarAlessandro Sorniotti <ale.linux@sopit.net>
      53de0781
  2. 25 Apr, 2018 1 commit
  3. 07 Apr, 2018 1 commit
  4. 07 Mar, 2018 1 commit
    • Matthew Sykes's avatar
      [FAB-8660] Operations and PeerSupport interfaces · 580d091a
      Matthew Sykes authored
      
      
      This introduces an interface that represents the currently exported
      functions of the peer. An instance of the interface is created during
      package initialization which delegates to the existing functions.
      
      - References to the peer functions in endorser.Support are replaced with a
        reference to the peer singleton.
      - CreatePeerServer is renamed to the more idiomatic NewPeerServer as it
        is a constructor
      - PeerSupportFactory is removed and an instance of PeerSupport is
        provided to endorser.SupportImpl and scc.ProviderFactory
      
      Change-Id: I07ae90092be8349bed60686f7b04a5b9ab02382a
      Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
      580d091a
  5. 05 Mar, 2018 1 commit
  6. 24 Dec, 2017 1 commit
  7. 20 Nov, 2017 1 commit
    • Gari Singh's avatar
      [FAB-7044] Refactor gRPC server config code · f7093140
      Gari Singh authored
      
      
      When creating a new core/comm#GRPCServer instance,
      the only options which are publicly exposed are
      those related to security.  All other config
      such as keepalive and message size settings are
      hard-coded and/or set internally.
      
      This change creates a new top-level ServerConfig
      struct which will be used in future changesets
      to hold various configuration options.  Initially
      it holds SecureOptions (which used to be
      SecureServerConfig).
      
      Change-Id: Ie6cd8c74ea9579504eb2bcba384498fede386cd7
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      f7093140
  8. 29 Oct, 2017 1 commit
    • Gari Singh's avatar
      [FAB-6788] Mutual TLS client connections for peer · d091d575
      Gari Singh authored
      
      
      Most of the plumbing to enable the peer to make
      mutual TLS connections to other peers and to the
      ordering service has been in place for a while
      but some minor refactoring was required in order
      to add support for using mutual TLS with the
      ordering service as well as with peers.
      
      comm.CASupport is also now being used in the
      orderer so it no longer made sense to add
      specific function(s) to it in support of
      client connections which will be made by the
      peer.  So a new type comm.CredentialSupport
      which "extends" CASupport was added.
      CredentialSupport includes a ClientCert field
      and the GetPeer/DeliverServiceCredentials functions
      were moves to this object.
      
      Change-Id: I0abf423a3c48d29408460ca2fe54cf14e7d6039c
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      d091d575
  9. 24 Oct, 2017 1 commit
    • Gari Singh's avatar
      [FAB-6716] Enabled mutual TLS support for orderer · e90b92ba
      Gari Singh authored
      
      
      The orderer currently supports the ability to
      require mutual TLS, however it only uses a
      static list of root CAs to validate client
      certificates.  In order to support the
      dynamic membership capabilities of channels,
      the trusted client roots for the gRPC server
      need to be updated whenever channel membership
      is changed.
      
      Also need to modify a core/peer test as a
      TLS intermediate root was added to the
      sampleconfig for completeness
      
      Change-Id: I4eccfd88ff7b86621b356e9f880062f98c425c60
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      e90b92ba
  10. 19 Oct, 2017 1 commit
  11. 22 Jun, 2017 1 commit
    • Gari Singh's avatar
      [FAB-4904] Modify peer to use MSP tls structure · ea3528e1
      Gari Singh authored
      
      
      With FAB-4626, the X509 MSP impl now separates
      the root/intermediate certs for signing from the
      root/intermediates used for TLS.  This change modifies
      the peer to use the updated TLS certs rather than the
      signing certs.  The following changes were made:
      
      - Use GetTLSRootCerts and GetTLSIntermediateCerts
      functions provided by the msp impl
      - remove the GetRootCerts and GetIntermediateCerts
      methods from the msp impl
      - modify examples/cluster (includes adding a
      separate TLS CA)
      
      Change-Id: I820b658aac9ca43f766a728f0f9b37194d8c7a7a
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      ea3528e1
  12. 08 May, 2017 2 commits
    • Gari Singh's avatar
      [FAB-3732] Fix e2e cli · 70b59b0e
      Gari Singh authored
      While cleaning up before submitting
      https://gerrit.hyperledger.org/r/#/c/9069
      
      
      I accidentally removed a small but important
      change.  This patch fixes that and also adjusts
      the test cases to catch this in the future by
      changing using different counts for app and
      orderer CAs
      
      Patch 2 changes the ports in one of the tests
      since they seem to fail now
      
      Change-Id: Ifdfe6f252c4f7ce7b3938ac322f33430916802b4
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      70b59b0e
    • Gari Singh's avatar
      [FAB-3701] Peer and orderer CAs should be separate · 0c58de67
      Gari Singh authored
      
      
      Prior to this change, there was a TODO in the code
      to separate the trusted roots that the peer should
      use when communicating with peers and orderers.
      Currently they are the same (both internal maps
      include all CAs for both orderer and peer/app
      orgs). With this change, it's no longer the case
      as the code now properly handles this.
      
      - renamed test to match what's actually being
      tested
      - revamped test scenarios to only test the
      functionality as well as increase coverage
      - regenerated crypto material required
      - slight modification to cert generator to
      add SKI to intermediate root certs as it
      is required
      - made sure to cleanup filesystem resources
      
      Change-Id: I20f35dcec9c787c9052fb5d8ef119cd3dbab2d6c
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      0c58de67
  13. 12 Mar, 2017 1 commit
    • Gari Singh's avatar
      [FAB-2745] Update e2e_cli to work with TLS · f8a49c00
      Gari Singh authored
      https://jira.hyperledger.org/browse/FAB-2745
      
      
      
      NOTE: needed to touch multiple parts of the
      system to get TLS working e2e but this seemed
      like the best approach
      
      - changed default compose files to require TLS
      - renamed original compose file to *-no-tls.yaml
      - modified peer to pass peer.tls.rootcert instead of
      peer.tls.cert to client connections and chaincode
      container
      - modified go chaincode to use rootcert and
      fallback to cert
      - fixed some logic in the getTLSCert method
      - modified TLS startup logic for orderer
      - moved casupport to core/comm package
      - modified configtx.yaml to use orderer0 for
      orderer address to match its certificate
      - regenerated orderer.block and channel.tx using
      updated configtx.yaml
      - added singleton CASupport object to the core/comm
      package
      - added flags and supporting code for TLS to CLI
      commands which communicate with an orderer endpoint
      - modified deliverclient to support TLS credentials
      which are dynamically updated via config blocks
      
      Change-Id: Ifd69b08ada90f3d579697c2b7ef027789a799f04
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      f8a49c00
  14. 11 Mar, 2017 1 commit
    • Gari Singh's avatar
      [FAB-2174] Populate TLS trust stores from config blocks · 4844ce83
      Gari Singh authored
      https://jira.hyperledger.org/browse/FAB-2714
      
      
      
      With this change, the peer now obtains the root
      certificates it needs to populate the server and
      client trust stores from config blocks.
      
      The following changes updates were made:
      - core/peer/peer.go - added structure to maintain
      per chain aggegate list of CAs for apps and orderers,
      callback function for the config mgr which will
      update the trust stores from config blocks, and
      a function to obtain the aggregate list of
      root CAs for the peer as a whole
      
      - msp - added methods to get the root and intermediate
      certs from an MSP instance.  We can revisit this if
      there is strong belief in not doing it this way, but it
      is better than parsing the protos multiple times
      
      - common/configtx/test - added helper function to
      generate a config block which accepts MSPConfigs
      
      - some cleanup and slight modifications to utility
      functions needed for the above
      
      Change-Id: I30668428a3c65702e1ebe2774668606ff4d78016
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      4844ce83
  15. 09 Mar, 2017 1 commit
    • Gari Singh's avatar
      [FAB-2714] Enable peer to start with TLS enabled · 1f49bfb0
      Gari Singh authored
      https://jira.hyperledger.org/browse/FAB-2714
      
      
      
      Prior to this change, the peer did not honor the TLS
      setting in core.yaml.  With this change, the peer will
      now read the peer.tls.* settings to determine whether or
      not to start the main peer server with TLS enabled.
      
      This following changes were made:
      - core/comm/testdata/certs/generate.go - needed to
      add usage extension to be able to use server certs as
      client certs
      
      - core/peer/peer.go - added package scoped peerServer variable in
      order to support dynamic updates from config transactions
      
      - peer/node/start.go - loads TLS config and calls function in
      core/peer package in order to create the peer server
      
      The tests do include a test for mutual (client) TLS
      authentication, but this is not yet enabled for the peer
      on start up
      
      Change-Id: I9a6d19b928c36b7500d004a57b7d76e40bb18fd9
      Signed-off-by: default avatarGari Singh <gari.r.singh@gmail.com>
      1f49bfb0