Deep Security Manager 10 has reached end of support. Use the version selector (above) to see more recent versions of the Help Center.
Can you describe your SSL implementation and the credential provisioning system between the Agent and Manager?
Deep Security Manager treats all connections to Agents/Appliances in a similar way. If the Agent has not been activated, a limited set of interactions are possible. If the Agent has been activated (either by an administrator or via the agent-initiated activation feature), the full set of interactions are enabled. The Deep Security Manager acts as an HTTP client in all cases, no matter how the connection was initiated. Agents/Appliances cannot ask for data or initiate operations themselves. The Manager requests information such as events and status, invokes operations, or pushes configuration to the Agent. This security domain is highly controlled to ensure that Agents/Appliances have no access to Deep Security Manager or its host.
The Deep Security Agent may initiate communication to Deep Security Manager or it may be contacted by the Manager if the computer object is set to operate in bi-directional mode. Like the Manager, the Agent uses two different contexts for the connection. Before activation, the Agent accepts the bootstrap certificate to form the SSL or TLS channel. After authentication, mutual authentication is required to initiate the connection. For mutual authentication, the Manager's certificate is sent to the Agent and the Agent's certificate is sent to the Manager. The Agent validates that the certificates come from the same certificate authority (which is the Deep Security Manager) before privileged access is granted. As mentioned earlier, once the SSL channel is established, the Agent acts as the server for the HTTP communication. It has limited access to the Manager and can only respond to requests. The communication channel provides authentication, confidentiality (through encryption), and integrity (through the TLS protocol). The use of mutual authentication protects against man-in-the-middle (MiTM) attacks where the SSL communication channel is proxied through a malicious third party. Within the stream, the inner content uses GZIP and the configuration is further encrypted using PKCS #7.