There are plenty of reasons that a company might want to try and decrypt SSL sessions to stop outbound malware botnet connections that are decrypted, or to stop a rogue insider from sending out sensitive corporate information but be prepared to hear employees whose data traffic is decrypted complain loudly about their privacy being invaded.
"Your users will freak out," said David Guretz, director of security at Jump Trading, the Chicago-based financial services firm that specializes in algorithmic trading technologies, who spoke about the topic of SSL decryption at the Palo Alto Networks users conference in Las Vegas.
He said Jump Trading's management decided SSL decryption needed to be done in order to watch for any signs that the company's valuable intellectual property might be exiting via the network. The company's Palo Alto next-generation firewall (NGFW) is able to do SSL decryption by opening up SSL traffic through an inspection process. But that didn't mean that Jump Trading's employees went along with SSL decryption process without complaining about loss of privacy. Guretz said he found the process of bringing in SSL decryption required explaining what was going on to employees, as well as garnering all the support possible from legal and human resources divisions.
"Be prepared to answer questions. If you didn't involve your legal, your SSL decryption will fail," he said. Because Jump Trading had a mandate from the executive level to undertake SSL decryption in order to protect intellectual property, it wasn't a hard transition, he added.
But it was necessary to make clear to employees in the US that they shouldn't have an expectation of privacy when using the corporate network, and across Europe where privacy regulations are tougher, it was only slightly different.
Signed policy statements have been the norm so that employees officially acknowledge the reality of SSL decryption. But Jump Trading has no interest in decrypting employee use of certain online services, such as banking, because there's no security rationale that pertains, Guretz explained. By being as clear as possible to employees why certain SSL-encrypted streams are being decrypted to protect the business, it's possible to go "from freak out to fair" in terms of employee reactions, he said. "We discuss this with them."
The Palo Alto Networks NGFW uses a certificate-copying mechanism to open up TLS 1.1 sessions (TLS 1.2 for outbound is not yet supported but the process negotiates down to TLS 1.1) that basically works like a corporate-operated man-in-the-middle attack. Keyword-based detection based on source-code extensions, for example, can be on the alert for an escaping intellectual property, though the Palo Alto NGFW is not said to represent full-featured data-loss prevention.
Mike Jacobsen, director of product management at Palo Alto Networks, said SSL decryption can be done on both an inbound and outbound basis in terms of SSL-encrypted traffic, but there are a few things to be aware of.
SSL decryption adds significant processing overhead so there's a limit that needs to be measured for the environment in question about how much SSL decryption can be done at one time via specific Palo Alto firewalls. That underscores what will likely be the need to do SSL decryption selectively based on where the greatest risk is.
The Palo Alto certificate-copying process that is used in some instances of SSL decryption will present the user with the well-known screen warning that the certificate is not trusted but they can override that. However, Jacobsen acknowledged that encouraging employees to override fake certificates is not really something companies relish doing. In lieu of that, it's possible to dynamically present a splash page that tells the user that an SSL decryption process is occurring, Jacobsen pointed out.
According to recent Palo Alto research based on its customers' usage, about 20% of traffic in the enterprise network is SSL encrypted traffic.