As compared to traditional client-server applications, distributed blockchain applications like Corda interact directly with each other by establishing a P2P connection. Corda nodes connect to the database, which has sensitive information. In enterprise production deployments, it’s a considerable risk to establish a P2P connection with the counter-party directly. One option is to place the Corda node in a DMZ. P2P connection is also a threat to the node’s sensitive information. Corda Firewall addresses these concerns.
Corda Firewall is an application-level firewall that acts like a proxy(Bridge) and a reverse proxy(Float) server. Corda Firewall is a piece of software that provides an additional layer of security. Corda Firewall consists of two components — Bridge (takes care of outbound messages) and Float (takes care of inbound messages).
Component 1: Bridge
The bridge component of the Corda Firewall takes care of the outbound messages. It can be configured to run within the node, or it can run outside the node. If the node wants to send a message to a peer sitting in a different organization, instead of connecting directly to the peer, the node can be configured to send messages to a bridge, which in turn forwards it to the peer. A durable outbound queue is created within the Artemis server for each peer. The Bridge establishes a secured TLS encrypted connection with the remote peer (direct or via a SOCKS proxy), acts as a consumer, consumes the message from the out queue, and sends the message to the remote peer sitting outside the nodes network. The peer consumes this Artemis message, checkpoints it and sends an acknowledgement to the source. The source node permanently consumes the message from the out queue after it receives the acknowledgement. The connection from Bridge to the outside world is AMQP 1.0/TLS 1.2.
Component 2: Float
Float acts as a listener for the incoming AMQP packets from its peers. It forwards these to the Bridge over TLS/AMQP and is responsible for sending acknowledgments back to the peers. Instead of directly receiving the messages from the outside world, the Float acts as a shield to the node for inbound traffic. The Float should be placed in the DMZ. It performs the initial handshake with the peer by exchanging the certificates, validates each message/packet before sending it to the node. It performs validations like it checks if the message size is higher than that defined by the current node and drop the packet without forwarding it to the node. This way only the genuine messages reach the node. Float can eventually be made more secure by adding more specific packet drop logic if required. The firewall component also performs auditing of every message received on the Float and the Bridge.
Component 3: Socks Proxy
In production systems, the node sits behind the firewall and is not allowed to connect to the outside world directly, or the firewall blocks the AMQP port. In blockchain systems, where a node has to establish a P2P connection with the peer, the Bridge can be connected to a SOCKS proxy, which in turn connects to the peer. SOCKS 5 provides additional support for security.
Component 4: Http Proxy
Http Proxy connects to Doorman and Network Map via HTTPS get requests.
Component 5: Artemis Broker
Artemis Broker is used to creating inbound and peer specific multiple outbound queues. The Bridge establishes a TLS link with the peer, consumes a message from this outbound queue, sends it to the peer, and removes it from the queue when it gets an acknowledgment from the peer. The inbound queue is used to store the inbound messages from the peers. Artemis broker, by default, is embedded within the node. It can be configured to set up Artemis out of the process as well.
Benefits of Corda Firewall
- Acts as a shield/proxy for the node, providing protocol break and can be placed in the DMZ. The Float prevents the Node and Artemis server from being exposed to the peer nodes.
- Peer node to float, float-bridge tunnel, internal node to bridge connection is TLS encrypted. Float bridge tunnel uses a different set of TLS certificates and does not use the node’s certificates. Since the data passing through the DMZ device is sent over encrypted TLS channels, this data is not leaked if ever the Float is compromised.
- Corda Firewall supports CRL, and if configured, each certificate in the certificate path is checked against a CRL.
- From an audit perspective business critical events at the Bridge and the Float are logged to a file. Future implementations will be enhanced to post data to an enterprise service.
- Messages are dropped at the Float and logged if they do not satisfy the validations; hence only valid messages pass to the internal network.
- Corda Firewall bridge can connect to the outer world via a SOCKS 4/5 proxy server. SOCKS 5 supports additional security. Also, having Bridge lets the node not have a public IP address.
- A connection is initiated by the bridge control to the external Float, establishing a bi-directional connection. The connection is never initiated by the DMZ device to the internal network, but is initiated by the Bridge.
- Float and Bridge are stateless and do not save any information.
- Artemis Broker can be taken out of the node. Thus one Artemis can be used by multiple nodes.
- Corda Firewall has a facility to enable TLS signing using HSM.
Corda Firewall PKI
TLS authenticated channel is set up at three places
truststore.jks contains the Corda network root ca certificate used at the time of node registration. truststore.jks is dynamically transferred to the float by the bridge and is stored only in memory. truststore.jks is used for mutual authentication between nodes and bridge/float.
sslkeystore.jks contains node’s TLS certificate, and is used by the establishing a secured TLS connection between nodes and bridge(and float).
bridge.jks and float.jks contains a new set of TLS certificates used to set up a TLS tunnel between bridge and float and trust.jks contains a root certificate.
Corda Firewall Configurations
The Corda node can be run as a simple single process that is compatible with peers running the Corda firewall. There are multiple ways in which you can configure Corda Firewall depending on your requirements. You have to consider various factors like security requirements, network infrastructure requirements, on-premise, or cloud deployments for deploying Corda into production. I have listed down a few of the possible deployment options.
Option 1 : Simple Self-Contained Node, No Firewall
For development purposes, you can quickly get started with this approach which has an embedded bridge. There is no explicit configuration required for this approach and is suitable for development purposes only.
Option 2 : Hot-Cold HA Nodes with Embedded Artemis, Hot-Warm HA Bridge and Hot-Warm HA DMZ Float
In this type of deployment, you can configure a hot-warm HA bridge and float along with a hot-cold HA node. In this type of deployment, Artemis sits inside the node.
Option 3 : Hot-Cold HA Nodes with External Artemis, Hot-Warm HA Bridge and Hot-Warm HA DMZ Float
In this type of deployment, you can configure a hot-warm HA bridge and float along with a hot-cold HA node. In this type of deployment, the Artemis sits outside the node which allows multiple nodes to share one Artemis.
Enterprise P2P blockchain deployments can pose serious threats to internal assets when adequate measures are not taken. It is important to understand the ultimate goal of your deployment and take into account all the factors related to network infrastructure, security requirements by the organisation, HA requirements, on premise or cloud deployment etc. Corda takes critical steps and has designed Corda Firewall to ensure underlying assets are protected from protocol level attacks, network attacks, DOS like attacks etc.
You can read more about Corda Firewall here.
Thanks to Matthew Nesbit and The Corda Team
Thanks for reading — Sneha Damle, Developer Evangelist (R3).