topic Re: ssl decryption with upstream proxy in General Topics

ssl decryption with upstream proxy

azwicker — Fri, 22 Mar 2013 08:30:21 GMT

We have a squid server behind our pa fw like this:

Client <-> PA FW <-> Squid Proxy <-> ASA FW <-> Internet

Decryption of site https://addons.mozilla.org adds the IP address of our squid proxy to the exclude-cache list and all following ssl connection are not decrypted anymore. Is this expected behaviour?

Re: ssl decryption with upstream proxy

Retired Member — Fri, 22 Mar 2013 15:20:07 GMT

You mean PaloAlto automaticly adds site to exclude-cache list ?

Only for that site this behaviour ?

Re: ssl decryption with upstream proxy

gwesson — Fri, 22 Mar 2013 18:26:36 GMT

This is expected behavior, though the feature is designed without proxies in mind.

The basis for this behavior is if there is no proxy and an SSL certificate cannot be decrypted, the firewall can avoid attempting to decrypt traffic at that IP for the duration of the exclude-cache. The trouble is that an explicit proxy will cause all sites to be the same IP and will get excluded.

There are a few ways to work around/solve the issue.

1. Move the proxy behind the Palo Alto Networks firewall. This might mean that you have to use the proxy to spoof the client IP if you are using user-id.

2. Use transparent proxy (policy-based-forwarding, L4 routing, WCCP, etc.) upstream from the Palo Alto Networks firewall.

3. Manually add URLs to the exclude cache list. This is fairly time intensive, because it is a reactive approach rather than proactive. The command is:

> configure

# set ssl-decrypt ssl-exclude-cert www.example.com

# commit

#1 might be the easiest to do, though #2 might work better if you already have the equipment to do so.

Hope this helps!

Greg

Re: ssl decryption with upstream proxy

mikand — Sat, 23 Mar 2013 07:52:48 GMT

Another problem is that the identified appid could be just "http-proxy" instead of the true app being used if you have Client <-> PA <-> Proxy.

The "proper" solution, as already mentioned, is to setup the flow as Client <-> Proxy <-> PA.

Also when the PA cannot decrypt the ssl (for example if the server cert cannot be verified) you can use a second cert in PA which the PA will use to notify the client that there is something bad with this connection.

For example:

1) Good example: Client tries to connect to server using ssl. PA terminates this and handshakes on its own with the server. If the servercert is verified and everything is good PA will then use CERT_OK (or whatever you might call it) towards the client. Client has the CA (which PA uses) as trusted authority (otherwise the client will get a warning that the cert sent from PA couldnt be verified against the CA list).

2) Bad example: Same as above but the servercert is bad somhow, the CA might not be trusted or the cert expired etc. Instead of using CERT_OK your PA can instead use another cert as CA in the handshake towards the client named CERT_BAD (or whatever you call it). The client has this CERT_BAD as untrusted/blacklisted CA in its browser.

This way the client can get notified if the PA <-> server connection is good or bad.

Regarding how to setup squid in transparent mode (regarding srcip) see this post:

Re: ssl decryption with upstream proxy

licenselu — Mon, 25 Mar 2013 08:53:51 GMT

Hello,

"Another problem is that the identified appid could be just "http-proxy" instead of the true app being used if you have Client <-> PA <-> Proxy."

That's completely FALSE !!

Even if the traffic is going though a proxy (User-> PA -> Proxy) you can still apply application rules to the traffic flow !

Instead of seeing 'web-browsing' as application in the log, you will see 'http-proxy' but all the other applications (ms-update, etc) will be recognized correctly !

If you need SSL exemption (for specific domain), you must use DNS format (like *.google.com) not IP.

Regards,

Re: ssl decryption with upstream proxy

mikand — Mon, 25 Mar 2013 09:09:53 GMT

Thats what I said - AppID only identifies the outer application being used.

That is if you have Client <-> PA <-> Proxy then all traffic passing through will be "http-proxy" instead of "youtube, facebook, google-apps" etc.

Re: ssl decryption with upstream proxy

azwicker — Wed, 27 Mar 2013 13:24:00 GMT

If implementing #1: Can the PA FW evaluate the X-Forwarded-For Header?

Re: ssl decryption with upstream proxy

mikand — Fri, 29 Mar 2013 09:08:23 GMT

Yes it can evaluate the X-Forwarded-For header however the value of XFF will be in the source user column in the logs.

And currently if you choose to clean out the XFF header it will probably get a hit in misconfigured IPSes (because the header isnt properly cleaned out, just nulled that is the line with XFF will currently show "X-Forwarded-For:" - just the ip/hostname part will be removed).

Also XFF seems to be non-standard-RFC.

Se this for more information: