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: Alessandro Sorniotti <ale.linux@sopit.net>

The assorted singletons in the peer code are a constant obstacle to
writing testable code.  This CR removes the sysccprovider singleton and
instead takes the interface implementation as context when necessary.

Change-Id: Iffc690c6649ff80cc9e43970cb47a2b179564734
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

Modifies  tests to use dynamic ports rather
than statically configured ones where possible

Change-Id: I8d46dc70b7fc5b7e41a882b8ba3cdaada7704c40
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

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: Matthew Sykes <sykesmat@us.ibm.com>

Production and test should not be co-mingled in the same files.

The mock initialization functions are currently referenced by code
outside of the peer package and can't be moved to an _test.go file
right now without introducing compilation errors.

Change-Id: I179c21f9268d464b4a8d583066e5f122b2141dc4
Signed-off-by: Matthew Sykes <sykesmat@us.ibm.com>

A simple change which renames a few fields
so that SecureConfig can be used by clients
as well as servers.

Change-Id: I2f8a7a947eb3b568e45efa6c0ad34beec85c7853
Signed-off-by: Gari Singh <gari.r.singh@gmail.com>

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: Gari Singh <gari.r.singh@gmail.com>

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: Gari Singh <gari.r.singh@gmail.com>

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: Gari Singh <gari.r.singh@gmail.com>

Since grpc.WithTimeout deprecated in current version
which fabric used. Following comments using context and
grpc.DialContext instead of grpc.WithTimeout.

Change-Id: I648cb19246146f6ec75065ed8395529bcbc85650
Signed-off-by: grapebaba <281165273@qq.com>

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: Gari Singh <gari.r.singh@gmail.com>

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: Gari Singh <gari.r.singh@gmail.com>

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: Gari Singh <gari.r.singh@gmail.com>

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: Gari Singh <gari.r.singh@gmail.com>

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: Gari Singh <gari.r.singh@gmail.com>

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: Gari Singh <gari.r.singh@gmail.com>