Scanning SSL Data
Web servers have a need to secure some data to and from clients, usually the type of data are passwords, forms for submitting personal information such as bank details and so on. Websites can make use of data encryption using SSL certificates. When a URL begins with “https” as opposed to just “http” it is encrypting that data to and from the end user. This means data is scrambled when in transit and protected from anyone else being able to view that data. When the packet arrives to its destination data is finally decrypted.
However it is crucial today organisations are able to scan this content for either malicious threats or confidential data leakage. What we mean by confidential data leakage is data an employee should not be sending out such as company a financial statement, etc. This is because encrypted traffic can easily contain malicious files, or an end user may be sending confidential information via an encrypted channel. The problem is this content can not be scanned as it is encrypted.
However we can overcome this issue using a man in the middle approach. Using an SSL content scanner we can create a trust with the client and another trust with the destination web server, allowing the scanner to be able to decrypt, scan and re encrypt content.
How it works
A client’s connection to a secure https site is intercepted by the man in the middle gateway which is the SSL content inspection feature (usually a gateway firewall or a dedicated web security gateway).
The gateway sends its certificate along with its public key to the client. The client would need to trust this certificate. This can be done manually from the client by clicking the broken padlock key in your browser and installing the certificate in to the “Trusted Root Certification Authorities”, or you can do this for all clients using Active Directory Group Policies. If the client does not trust this certificate, you can still continue to the secure web page but it would get a certificate error that the page can not be trusted. This is because the certificate used would be the web gateway’s vendor self signed certificate and NOT one that is publicly known by client browsers. At this point a secure connection has been created between the client and gateway.
Now the gateway makes a connection to the secure destination website. A secure connection is created by using the destination server’s certificate and public key.
The gateway is now able to decrypt, scan and re-encrypt content from and to the client as it has the related private key of the client’s public key.
The only other concern is do we really want a web gateway solution decrypting our data? What if it’s our bank details? There is a remedy for this. SSL content scanners now have the ability to apply exceptions, so these can be either specific URLs or categories, such as financial sites. With an exception like this every secure site will be scanned other than financial sites. Also users can be warned with a warning page if their content is being inspected.
Finally it is not just limited to web traffic only, when we say web we technically mean HTTP and HTTPS. Network firewalls, depending on the vendor have the ability to scan IMAP, SMTP, POP3 and other protocol traffic as well.
For further reading, there's some excellent electronic ebooks available for download from eBooks.com