proxy - How to block specific HTTPS traffic?

According to HTTPS description:

Hypertext Transfer Protocol Secure (HTTPS) is a combination of Hypertext Transfer Protocol (HTTP) with SSL/TLS protocol. It provides encrypted communication and secure identification of a network web server.

And to SSL/TLS:

The TLS protocol allows client-server applications to communicate across a network in a way designed to prevent eavesdropping and tampering.

Since most protocols can be used either with or without TLS (or SSL) it is necessary to indicate to the server whether the client is making a TLS connection or not. There are two main ways of achieving this, one option is to use a different port number for TLS connections (for example port 443 for HTTPS). The other is to use the regular port number and have the client request that the server switch the connection to TLS using a protocol specific mechanism (for example STARTTLS for mail and news protocols).

From this explanations we can understand that HTTPS traffic uses 443 TCP port with encryption, I mean, it is not possible for a proxy to interpret the traffic and block unwanted sites because it is encrypted.

At my company, people usually use https:// to access facebook, hotmail and another websites that are blocked by corporative proxy. So, I was wondering, it is possible to block even https trafic for specific sites using a proxy or another techique beyond and integrated with the actual proxy solution? It is possible to filter or block specific sites over https layer?

Answer

Although the example you cite in your question is trivial to achieve with a proxy because the URLs are not encrypted, and therefore easy to add to a blacklist, it IS possible to inspect HTTPS traffic going through a proxy.

Enterprise deployments usually achieve this by deploying an internally trusted certificate to their entire installed end user machines. Connections to the proxy server are done via this certificate (whether the users realise it or not), where the proxy software can decrypt the payload, inspect it and decide on its validity. The onward connection to the end site is done with "real" certs.

This is a bit of a sad state of affairs really, as it breaks the trusted model of SSL and TLS - but I know for a fact it's done - as it happens where I work.