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

  1. tcp-ip – Two nodes communicate trough a tcp-ip connection.
  2. tls – The traffic is wrapped inside a tls channel.
  3. message layer – The nodes sends encrypted messages to each other. The messages are forwarded from node to node until it reaches the destination node.
  4. 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.

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment