dbWatch Control Center is composed of a set of nodes that speak to each other using a layered protocol.
This document describes these layers and how they interact to achieve security and reliability.
The dbWatch monitor is also a node and has all the behavior described here.
A brief overview of the layers
The protocol consists of these layers
- tcp-ip – Two nodes communicate trough a tcp-ip connection.
- tls – The traffic is wrapped inside a tls channel.
- message layer – The nodes sends encrypted messages to each other. The messages are forwarded from node to node until it reaches the destination node.
- Ephemeral tunnel – Most messages are sent encrypted
The tcp-ip layer
Two nodes talk to each other using tcp-ip. Any node can accept incoming connections on multiple ports and can connect to multiple ports.
This can be configured in the domain configuration dialog or in the config/node/node.connections file.
Example of a node.connections file.
{
"versionCutoff":"",
"listenTo":[
"dbw://localhost:7100"
]
, "connectTo":[
"dbw://cloudrouter1.dbwatch.com:7100"
]
}
Transport Layer Security
Inside the tcp-ip connection we encrypt everything with Tls. Most people know this protocol from how it is used in the web(HTTPS).
There are some differences in the way dbWatch uses it. In addition to keeping the traffic between two nodes hidden the nodes use
tls to transfer proof of routing privileges to each other. Say you have 3 nodes in a chain. One Monitor a cloud router and a instance hub.
Both the Monitor and the instance hub sends certificates when negotiating the tls connection that tell the cloud router which domains they have routing privileges on. If they prove privileges on at least one common domain the cloud router will route between them.
All nodes that are part of the same domain have routing privileges within that domain. The monitor gets these privileges by authenticating to a given domain.
The message layer
The messages contain the following fields.
Field | Description | Size (bytes) |
time to live | Time to live for the message | 1 |
recipient | Recipient address (ip v 6) | 16 |
sender | Sender address (ip v 6) | 16 |
body category` | Category of the message body | 1 |
send time | Time the message was sent | 8 |
certificate id | Certificate ID used to sign the message. | 8 |
is body encrypted | Flag if body is encrypted | 1 |
body length | Length of the message body | 4 |
message body | The content of the message | body length |
signature length | The length of the signature | 4 |
signature | The signature | signature length |
The message layer looks at the fields and routes the message accordingly.
If the recipient is the nodes address the node validates the signature before processing the message.
The signature covers all the fields except for time to live.
Ephemeral tunnel. (Diffie-Hellman)
Since the tls layer only encrypts between two directly connected nodes we have a second encryption layer that encrypts the bodies of most messages.
Before you send a message to a node we perform a Diffie-Hellman handshake to establish ephemeral keys to secure encrypt message bodies.
This key is used to keep all communication between the nodes secret, and also works if someone on a later date gets hold of the servers keys.
Post your comment on this topic.