SSL implementation and credential provisioning
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. Deep Security Manager treats all connections to agents
Both agent and manager use two different security contexts to establish the secure channel for HTTP requests:
- 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.
Once the secure 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 secure channel provides authentication, confidentiality through encryption, and integrity. 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.
It is not recommended to perform SSL/TLS decryption of communications between Deep Security products. Any device or middleware should be configured for TLS passthrough. For instance, if a firewall performs SSL inspection, it decrypts and then re-encrypts the communication, altering the certificate in the process. This alteration causes the certificate to differ from the original one provided. As a result, when the communication from Deep Security Agent reaches Deep Security Manager, the altered certificate is deemed unauthorized.