Fundamentally, all SOAP communication occurs as HTTP over various, configurable TCP ports. Ideally, this communication should be encrypted, as the data transmitted between the Agent, Manager, and FW is going over the same set of networks that any malware would traverse.
One bad scenario involves the malware on the Agent attempting to attack the Manager SOAP client, running on the host. This threat is fairly small, because the Manager itself never runs any type of SOAP server on the host directly. Instead, the Agent hosts the SOAP server, requiring the Manager to contact it as a SOAP client.
However, it may be possible for malware act as a "spoof" Agent SOAP server, in which case the Manager would be unable to distinguish which server to trust — the spoofed one or the real Agent one.
Task: By switching all SOAP::Lite calls to use certificate-based HTTPS mutual authentication, we reduce (but not eliminate) the threat this situation imposes. Malware could still (possibly) attempt to gain access to the private key component of the certificate used by the Agent SOAP server; however, this would require a fairly advanced degree of exploitation. Overall, the cost/benefit analysis can be summed up as follows:
Pros:
- Increased security between Agent and Manager communications
- Strong authentication; by default, it will be difficult for malware act as a spoofed Agent SOAP server
- Strong encryption; by default, it will be difficult for malware to intercept/analyze any SOAP communication
Cons:
- Requires setting up (or using) a PKI
- Each SOAP server must have a unique/valid SSL certificate
- The Manager SOAP client must have a unique/valid SSL certificate
- All SOAP parties must be configured to validate a subset of authorized client/server certificates
- May have to enable CRL lookups or OCSP responders, if leveraging an external PKI
