Since HTTPS traffic is encrypted in transit how does a web security gateway analyse it?
Products which purport to be able to filter SSL-encrypted traffic usually do so by doing a man-in-the-middle attack, just like an active attacker would do. The "security product" sits on the Web proxy, through which the connection is performed. It intercepts the flow, and generates on-the-fly a custom certificate with the name of the target site; the client effectively establishes a SSL tunnel with the proxy, not with the intended target site. Simultaneously, the proxy connects to the target site, and forwards data in both direction.
This can work only because the automatically generated certificate is signed relatively to a special certification authority controlled by the proxy, and installed as a "root CA" in the relevant store in the client machines. This requires that whoever installs the proxy has administrative control of the client systems.
Apart from such "security products", such an institutional MitM setup is found in products which claim to "speed up the Internet" (i.e. they grab the data, compress it, and send it to a specific gateway which uncompresses it).
Note that such a system cannot work with bi-authenticated SSL connections (the kind where the client also has a certificate): the client-generated signature cannot be converted by the proxy into a signature which will convince the server (because, among the data signed by the client, is the server certificate as the client saw it, i.e. the one automatically generated by the proxy).
Another way to analyze SSL-encrypted traffic, not on the client side but on the server, is to have a product which has a copy of the server private key, and ensure that the server does not use the "DHE" cipher suites. Under these conditions, it suffices to grab a copy of the packets to decipher the tunnel. Of course, this is for connections to one specific server, and it requires some cooperation of the said server (the server private key is, after all, private to the server).