Recently we have had questions about giving SSL visibility to other devices, such as IDS/IPS systems and the like.

SSL visibility is performed by Web Gateway since we invested the SCM market early in the century as Webwasher. SSL Scanning was an essential part to that ever since. Other Layer 3/4 devices are content aware, such as IDS/IPS systems but struggle with the SSL visibility as real-time decryption of a data flow is somewhat difficult and would require them to be more evasive when is comes to traffic and that's something they are not able to do.

The question now is how can you provide visibility into SSL traffic using MWG?

 

It is essentially a 3 step scenario:

  • Decrypt
  • Forward unencrypted over the network
  • Encrypt

 

These 3 steps can easily be implemented in any web gateway policy using a next hop proxy setup.

 

Filtering

 

 

The policy is pretty similar to a general web security policy you would setup. the important thing is that infinite loop detection needs to be disabled, as MWG will send traffic to itself and might therefore assume that a configuration error is causing this.

Rule.png

Forwarding

The real magic the rewrite of HTTPS to HTTP, which can simply be done by setting the URL protocol the HTTP instead of HTTPS.

Rule2.png

The next hop proxy setting can then forward the traffic to the MWG instance itself so traffic leaves the box, in case you set an IP other than 127.0.0.1, and the traffic can be monitored. You could also do the same in a proxy chain for instance. The unencrypted traffic could them be examined by an IDS/IPS and as benefit of the chosen method, an IPS could even be effective, as it has the ability to send a reset and traffic would stop as this is in line with the transaction. This is clearly a benefit in contrast of just a passive leakage port. An IDS could of course monitor as well.

The traffic then then received on a different port than the original Proxy port, and is forwarded again for encryption.

 

Conclusion

The beauty and benefit of such a method is that you can selectively decide which traffic to pass on unencrypted as opposed to leaking all potentially confidential SSL traffic to a mirror port or putting it on the wire.

In several jurisdictions, SSL Scanning is under certain legal requirements and just making all SSL traffic available can cause legal consequence, whereas doing that with some categories only outside of personal email or on-line banking can be OK.

 

Attached you find the sample rule set used in this article. When performing the attached setup, make sure that you factor the additional requests into your sizing, as, as always, a new feature adds additional load onto the boxes. We don't expect a lot of overhead, but an additional request in an additional request, however no scanning is done on these requests, thus the additional load will be small.