How to block specific HTTPS traffic?

Question

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?

Solution 1

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.

Solution 2

https site block with intrusion prevention(inline) system like snort and suricata is dead simple.

Both above IPS can use same signatures.

Here are some IPS rules for domain, port, ip address and file extension block.

http://kb.simplewallsoftware.com/help-faq/answers/useful-suricata-rules/

Comments

[Rado]

You should still be able to block the URL from being requested. It is not encrypted

[Diogo]

Hmmm, you are right, I just tested with wireshark.... Thank you.

[user1686]

@Rado: When HTTPS is proxied, it usually uses HTTP CONNECT, in which case part of the URL is encrypted; only the domain name is not. (Enough for blocking, though.)

[Rado]

@grawity, good to know. There's really no way to encrypt the whole url, after all, the proxy needs to know where to route the traffic to. I suppose anything other than port and ip (or domain name) is handled by the destination so it makes sense to be encrypted. I suppose the only way to encrypt the destination is to use a second https proxy so all 3rd party proxies should be black listed as well

[Rado]

Good old man-in-the-middle attack used for not as illegal practices

[Scott Chamberlain]

Umm, if you are running a corporate network with sensitive resources you need to protect bad things coming in and sensitive things from going out. To do that you need to inspect all traffic that goes in and out. To do that you have two options, intercept SSL connections and re-sign with a new cert, or block all SSL connections. Which would you rather have?

[G-Man Says 'Reinstate Monica']

The question “it is possible to block HTTPS traffic for specific sites?” has already been adequately answered. The question didn’t ask “What are the addresses I would need to block in order to block Facebook?”, so this does not provide an answer to the question. … … … … … … … … … … … … … … … … … … … … … … Also, doesn’t 31.13.64.0/18 cover the next 24 entries (through 31.13.96.0/19)?