Because SSL is designed to prevent third parties intercepting data, the only way to access the content of an SSL communication is to implement a ‘man-in-the-middle’ proxy. To do this, the NBA is connected between a client computer and the internet-based web server. A proxy server on the NBA intercepts and terminates client requests to open SSL sessions. A proxy client on the NBA then creates a second SSL session to the web server.
The trust relationship between the client and web server now becomes one trust relationship between the client and NBA, and a second trust relationship between the NBA and web server. To establish this trust, you generate a ‘master’ trusted root certificate on the NBA. You must then install this master certificate onto each client so that the client trusts the NBA. At the same time, the NBA holds a set of root certificates, similar to those installed in most browsers, enabling it to verify the connection between itself and the web server.
When the NBA intercepts an SSL communication, the NBA decodes the SSL communication and applies NBA policy. If NBA policy is configured to decrypt and analyze the communication, the NBA processes all data on that session just as if it were unencrypted, allowing CA DataMinder policy to be applied. This CA DataMinder policy processing returns an 'allow' or 'block' result. If the result is 'allow', the NBA re-encrypts the communication before forwarding it to the web server.
Decryption and re-encryption is performed by the decoder, a module within the NBA that incorporates a proxy server and proxy client.
NBA Uses Proxy Server and Client to Decode SSL Traffic
A client application (1), such as a web browser or email client, attempts to connect to a target server application, such as a web server or SMTPS server (3). The client holds a copy of the NBA master certificate (2a).
The proxy server on the NBA (2) intercepts the client request to open an SSL session. At the same time, the proxy client on the NBA creates an SSL session to the target web server (3). The target server issues a certificate signed by a certificate authority (3a). The NBA holds a store of common root certificates from certificate authorities (2d) and uses one of these root certificates to verify the connection to the target server.
The NBA then returns a certificate to the client using details from the target server's certificate (3a). The NBA signs this certificate with its own master certificate (2a). The client then uses its NBA master certificate to verify the connection to the NBA.
Having established an encrypted link between the client and the target server, the NBA proxy server decodes the SSL communication (2b). Decoded data is passed to NBA policy filters for decryption and analysis (2c). When analysis is complete, and policy processing returns an 'allow' result, the proxy client re-encrypts the communication and forwards it to the target server application.
|
Copyright © 2014 CA.
All rights reserved.
|
|