|
|
|
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 a 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 DLP policy to be applied. This CA DLP 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 certicate (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.
SSL traffic is intercepted transparently by the NBA. Therfore the NBA requires no proxy IP addresses to terminate SSL sessions. Neither does it require DNS entries, browser proxy configuration or additional firewall configuration.
The NBA can decode the following protocols:
(Bivio 7000 appliances ony) If a Bivio 7000 appliance is fitted with Cavium CN1615 Security Processor cards, the NBA offloads the computationally expensive cryptographic operations to these devices, freeing the Bivio CPUs from this task and thereby maintaining high performance. The NBA console on Bivio 7000 appliances contains an SSL Decode Statistics page which shows whether the hardware or software decoder is being used.
When a user browses to a secure site, they see a change in the browser address bar. The protocol part of the URL changes to ‘HTTPS’ and a padlock or shield icon usually appears. If the trusted ‘master’ certificate of the NBA is installed on the client machine, the user sees no change in the look or behavior of the site. If the user clicks the padlock or shield icon, they can view the certificate of the web site. This certificate looks very similar to the original certificate from the web site, except that the certificate signer will be ‘CA DLP’ (you can customize this name).
Invalid Certificates
If the user browses to an HTTPS site that presents an invalid certificate, the address bar may turn red and the main content window shows a warning message. This message permits the user to ignore the warning and continue browsing to the site. The same happens if the NBA is decrypting the network traffic. The error in the site’s certificate is replicated in the certificate supplied by the NBA to the client’s browser.
Extended Validation (EV) or High Assurance certificates
Extended Validation (EV) or High Assurance certificates are issued to web sites by certain Certificate Authorities. They are issued to sites only after additional checks to verify the identity of the owner of the site. The browser contains a list of these Certification Authorities. If the root certificate of a particular web site is in the list, the address bar in the browser turns green and shows the Certificate Authority name. When using the NBA SSL decoder, such sites are decoded correctly but displayed with the standard browser address bar (with a white background).
| Copyright © 2011 CA. All rights reserved. | Email CA Technologies about this topic |