Organizations that need to enforce Internet usage policies use gateway security products for fine-grained control. This kind of policies often include a list of web sites users are allowed to visit or not allowed to visit, ban a category of websites altogether, grant time-bound permissions etc. But uncategorized SSL-enabled sites pose potential threats that extend to data leakage or even worse. Examining such sites to enforce policy is a technological challenge. There is no acceptable way to examine the data in transit without breaking the end-to-end encryption that SSL provides.
Browsers are designed to give ample warnings if there is any SSL protocol breach. Among them include unrecognized certificate authorities (CA) and domain mismatch warnings. Users are alerted with pop-up dialog windows explaining the situation. Users must be trained to pay attention to such alerts and to act logically rather than naively pressing OK to proceed with the website. This is required for users’ own safety as well as for organizations’ security.
Reliability of SSL encryption
The reliability of SSL is that it offers in-transit security and it detects if a breach happens in between. Browser expects a well-formed SSL certificate from the website that is issued by a certificate authority known to the browser. If there is any problem, browser will alert the user about it. If there is an alert, and if the website is an important one, ideally, the user should not proceed without knowing what she is doing.
How SSL interception works
There seems to be a trend in the market to provide web security products that offer scanning of SSL traffic. This offering appears to be a boon to network administrators. But it would be a good idea to examine how this solution actually works.
The products that offer SSL scanning intercepts the SSL to examine the content. For this the SSL session is terminated in the web security device that acts as the gateway and another SSL session is initiated from the device for the browser with a certificate issued by the web security device. Here browser will reject the certificate issued by the security device for obvious reasons. In some cases, web security devices’ root certificate is installed in all the browsers in the network to avoid browser warning. In either case user is left with no choice but to accept the wrong certificate, if at all the user wants to proceed with the website.
There are four potential problems in this approach. Each one is either harmful to the user or to the organization and sometimes both.
- As users have to ignore certificate warning every time they visit an SSL-enabled website, it will become habitual to ignore such warnings. The system is in fact training users to ignore browser warnings. When users encounter a man-in-the-middle attack for real, they might fail to ascertain the situation and can become victims of hijacked SSL session.
- Secondly, device’s root certificate is installed in browsers to avoid browser warnings. This creates even high threat to all browsers having that root certificate installed. In case the device’s private key is stolen, anyone who has access to it can forge any website’s certificate and no browser in the network will complain about it.
- Many counties have well defined cyber laws. Breaking an end-to-end encryption may result in violation of applicable laws though it varies from country to country. Legal consultation should be sought before implementing such a solution.
- Fourth problem is that if there is an SSL scanning system running in an organization, it is certain that no SSL session is safe for transaction as it is supposed to be. SSL sessions from the website is terminated at the scanning device for intercepting the content that is being transferred back and forth. Another SSL session with a local SSL certificate is initiated from the gateway and that is what is connected to user’s browser. Here the user technically gets a chance to disown a transaction if she wants to. This is because someone is already intercepted and allegedly eavesdropped/manipulated the transactions. This creates a potential legal situation that the burden of proof falls on the shoulders of the organization. It would have been easy otherwise, with regular SSL session that provides end-to-end encryption.
Best practice is not to break SSL sessions. Prepare a list of SSL websites that organization can permit the users to access from work place. Deny all others. This is not as hard as it sounds. Security is always a convenience vs. protection battle.
Mettle SE doesn’t provide SSL interception as a matter of policy due to the reasons discussed here. But Mettle SE users have got better ways to address this requirement. Mettle SE provides location based access policy mechanism which comes handy in such situations. In Mettle SE it is possible to specify web access policies based on the network. The same user is subjected to different sets of policies based on the network she is located at. Using this mechanism, it is possible to allow access to a limited white listed SSL websites from a high security network and enforce a different policy in a low security network.
There is no means to intercept SSL traffic without breaking the session, offending the browser/client, violating applicable laws. If there is one, SSL is useless. Never ignore the long terms consequence–users will be trained to ignore browser warnings. Also consider the potential legal scenarios introduced by the SSL interception solutions favoring users with malice intent.