ssl decryption with upstream proxy

Reply
L1 Bithead

ssl decryption with upstream proxy

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?

L6 Presenter

Re: ssl decryption with upstream proxy

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

Only for that site this behaviour ?

L7 Applicator

Re: ssl decryption with upstream proxy

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

L6 Presenter

Re: ssl decryption with upstream proxy

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:

L4 Transporter

Re: ssl decryption with upstream proxy

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,


HA

L6 Presenter

Re: ssl decryption with upstream proxy

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.

L1 Bithead

Re: ssl decryption with upstream proxy

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

L6 Presenter

Re: ssl decryption with upstream proxy

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:

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!