Blocking https:// on Cisco ASA

[andy_4578]

Is any body able to advise as to why the CSC module cant block URL requests on port 443 and so many other vendor equipment can?

We only sell and recommend ASA firewalls but it's becomming a problem when the CSC module cant block https and other vendors such as Watchguard can, is this likely to change in the future?

Is the only way to currently block 443 traffic to use regular expressions?

[mirober2]

Hi Andy,

The reason that the CSC can't filter HTTPS traffic is because it is a transparent proxy, meaning that it is simply a middle man in the TCP connection. Since HTTPS traffic is encrypted by SSL, the CSC has no way of seeing the packet's payload, and thus it can't tell what website you are trying to access with the GET request. Since HTTP is transmitted in clear-text, the CSC is able to see the URL in the payload and make a filtering decision.

Products that are able to filter HTTPS traffic actually require the client to connect directly to the proxy/filtering server. In these scenarios, the client talks to the filter, and the filter talks to the web server. This way, the filter is able to decrypt the packet from the client, make a filtering decision, and then create a 2nd SSL connection to the web server.

Unfortunately, the only clear-text part of an HTTPS packet that is filterable by the ASA is the destination IP address. You could create an ACL that blocks certain destination IP addresses, but keep in mind that these are subject to change by the site's administrator. If your clients use an internal DNS server that you control, you could have it return an invalid response (127.0.0.1) for their DNS queries to sites you want to block, but they could simply change their DNS server settings or browse by IP instead of name.

-Mike

[andy_4578]

I see what your saying, but the initial request, i.e when you type the URL in IE (https://www.egg.com) and press enter, that traffic has not been encrypted yet as it hasnt spoken to the destination server to exchange keys so the CSC module should be able to read the URL.

See the following link which confirms quite a lot of handshaking occurs before any encryption takes place

http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html

[mirober2 · Accepted solution]

Hi Andy,

That's not exactly correct. The actual GET request to the web server (i.e. the packet that tells the server what URL the client is requesting) is completely encrypted and there is no way for a host in the middle to see that. The SSL handshake happens before the GET request is sent.

The "www.amazon.com" example that the site you referenced is showing is part of the SSL handshake, not the HTTPS GET request, and that is representing the server's name in the SSL certificate, not the URL being requested.

So, for example, if I browse to https://encrypted.google.com/#hl=en&q=cisco, my browser will be passed a certificate for the encrypted.google.com web server and you'll see this in the SSL handshake. However, the actual URL that I browsed to will not be readable by anyone except the client and the server.

Hope that helps.

-Mike