If your filtering software is implemented as a (possibly transparent) HTTP proxy, then the only way you can filter HTTPS connections is to do Man-in-the-Middle SSL inspection. This is a somewhat tricky and intrusive technique, but some filtering proxies do support it. The way it basically works is this:
Whenever the proxy intercepts an SSL handshake, it doesn't forward it to the target site but responds to it directly, using its own self-signed certificate that claims to be valid for the target site.
Once the SSL connection is established between the proxy and the browser (which thinks it's talking to the target site), the proxy creates its own SSL connection to the target site.
The proxy then receives the HTTP request over SSL from the browser, filters it and forwards it to the target site. It then does the same with the response from the target site to the browser.
Of course, since the certificate sent by the proxy to the browser in step 1 is not actually valid for the target site, and in particular hasn't been signed by a trusted CA, the browser would normally abort the connection and show the user a big alert about an untrusted certificate.
The trick, however, is that you, as the network administrator, need to add the proxy's signing certificate into the browser's list of trusted root certificates. That way, the browser will, in fact, trust the fake certificates returned by the proxy.
Of course, the user could remove the proxy's cert from the browser's trusted list, or just use their own browser that is not configured to trust the proxy. But this just means that they'll get a security alert and be unable to connect to HTTPS sites; it won't help them actually bypass the proxy.
All that said, I would seriously advise you to think carefully before using such tricks to undermine the SSL trust infrastructure, and to only do it if you feel that it's absolutely necessary. Even then, I'd recommend only applying it to a few specific sites that you want to filter, and to leave HTTPS connections to other sites alone. Your users might not care that you're snooping their Google searches — but they will not want you snooping their online banking, for example.
On the other hand, if your filtering software runs on the user's computer, e.g. as a browser extension, then it should have no trouble filtering HTTPS requests just as easily as plain HTTP; by inserting itself between the browser UI and the network backend, it can rewrite HTTPS requests before they are encrypted.
(This is, for example, how the HTTPS Everywhere plugin for Firefox works: it intercepts HTTP requests and rewrites them into HTTPS requests, sometimes modifying the URLs in other ways also. There's no reason why this wouldn't work just as well in the other direction too.)
However, there are two issues with this approach. The first is that different browsers have different extension APIs, and not all of them are equally convenient for such request rewriting. (For example, Chrome's extension API is apparently particularly badly suited for it, due to its asynchronous design.)
The second issue is simply that there's an easy way to get around a filter implemented like this: just install a browser that the filter doesn't support. Thus, such filtering won't be very effective unless coupled with other restrictions to prevent such workarounds.
