topic SSL Sites bypass URL Category block in General Topics

SSL Sites bypass URL Category block

u7285 — Wed, 28 Sep 2011 10:28:24 GMT

Good Day Guys and Gals

I need ideas on the following issue please! I have a block on all Social networking sites for the company. The Policy works great when the user tries to access http://plus.google.com, but when they use SSL (https://plus.google.com) the user gains full access to the site. Same goes for all other Social networking sites! How do we stop them on SSL?

Thanx in advance!

Re: SSL Sites bypass URL Category block

ssancho — Wed, 28 Sep 2011 11:16:03 GMT

Hi, you need SSL Proxy to unencrypt SSL and analize the traffic. It is very easy to implement.

Regards

Re: SSL Sites bypass URL Category block

bpappas — Wed, 28 Sep 2011 21:40:57 GMT

You could also block these using the URL filtering feature. URL filtering will work on encrypted or unencrypted traffic because it is making the allow/block decision using the unencrypted URL information.

-Benjamin

Re: SSL Sites bypass URL Category block

u7285 — Thu, 29 Sep 2011 06:47:10 GMT

Good Morning Bpappas

Thank you for your reply!

I am actualy using the URL filtering feature, Policy with application filtering and plus.google url in custom deny list, but still it bypasses the PA......

Any other ideas?

Re: SSL Sites bypass URL Category block

bpappas — Thu, 29 Sep 2011 20:58:16 GMT

@kobus.snyders:

if that is happening I would advise you to open a case with your support provider.

-Benjamin

Re: SSL Sites bypass URL Category block

Retired Member — Sat, 01 Oct 2011 04:05:34 GMT

The problem with URL filtering and HTTPS traffic is that with HTTPS you cannot actually see the GET message which URL filtering normally looks at because it is encrypted. So URL filtering can only apply to the URL in the certificate. If that certificate does not have "plus.google.com" then URL filtering will not work on that. It seems https://plus.google.com certificate was issued to "*.google.com". You can see a server certificate in IE by going to File > Properties and then click on Certificates button.

Likely the only way you will be able to reliably identify social media sites would be to use SSL proxy decryption as others have suggested.

-Richard

Re: SSL Sites bypass URL Category block

mgentile — Mon, 03 Oct 2011 16:47:05 GMT

For this specific case, shouldn't blocking the 'google-plus' application achieve the same result?

Re: SSL Sites bypass URL Category block

fnichelson — Tue, 15 Nov 2011 21:32:19 GMT

That is not the case for me, it does block it in chrome but not in IE or Fx? I've also added a url filter but that didnt work iether for google+ Im still testing but I ahve to ahve this closed by the end of the week. I may have to open a case for the Palo techs to help me out on this.

Re: SSL Sites bypass URL Category block

Kali — Wed, 16 Nov 2011 01:52:34 GMT

Hi, have you tried ssl decryption?. it works great with sites that uses ssl/https.

Re: SSL Sites bypass URL Category block

jhickey — Tue, 08 May 2012 00:34:34 GMT

Im nervous to turn on SSL Decryption. Is it reliable ? Do I have to turn it on for all SSL traffic ? I just want the URL information.

Justin

Re: SSL Sites bypass URL Category block

mikand — Tue, 08 May 2012 06:47:54 GMT

You define for which zones and ipaddresses and/or users along with categories you wish to enable ssl decryption for.

In you case perhaps something like:

srczone: clients

dstzone: internet

srcip: any

dstip: any

user: any

categories: (select all categories, dont know if "any" exists yet).

action: decrypt

This way as soon as a ssl handshake is seen the PA will intercept depending on if you set this up as ssl-proxy (common when intercepting outgoing clients) or ssl inspection (common when intercepting incoming clients towards one of your servers which you have the private key for).

Previously there have been issues with 2000-series when there were to many concurrent ssl decryptions (because at 2000-series and below the mgmtplane is involved into creating the faked cert on the fly). I dont know if this has been fixed yet (I think it is).

Also note in order to make this transparent for the clients you need to import the CA cert (well the public part of what you imported into your PA device) as a trusted CA in your clients (can be done through group policy). Also you can use a second cert (and not import this one in your clients) which PA can use for ssl sessions that couldnt be verified (for example if the cert from the server at internet is expired, revoked or such).

Re: SSL Sites bypass URL Category block

essnet — Tue, 08 May 2012 16:37:58 GMT

Usually, Google services are fully compatible with SSL decryption.

If you want to activate it only for Google, create SSL Decryption rules only for the following ranges:

ip4:216.239.32.0/19

ip4:64.233.160.0/19

ip4:66.249.80.0/20

ip4:72.14.192.0/18

ip4:209.85.128.0/17

ip4:66.102.0.0/20

ip4:74.125.0.0/16

ip4:64.18.0.0/20

ip4:207.126.144.0/20

ip4:173.194.0.0/16

Re: SSL Sites bypass URL Category block

MTatty — Tue, 04 Jun 2013 19:59:19 GMT

I found that if you define an application in the rules that also does URL filtering it needs to decrypt the packet to decipher the application. One way is to use http and https ports.

For example your rule to block a website might look like:

srczone: trust

dstzone: untrust

application: web-browsing

action: allow

profile: URL filtering

Change to:

srczone: trust

dstzone: untrust

service: service-http, service-https

action: allow

profile: URL filtering

Just was one thing I came across that sounds close. The other option is of course adding certificates.

Re: SSL Sites bypass URL Category block

mikand — Wed, 05 Jun 2013 06:40:10 GMT

Sounds odd... when you use url filter without decryption then the url filter can only look at the CN part of the certs passing through. This will also mean that the identified application will most likely just be "ssl" (and "web-browsing" for the cleartext stuff).

If you enable decryption then the real appid (lets say youtube or whatever) will be identified and the full url will be logged (and handled by the filters) aswell.