url filtering question

[simsim]

Hi,

How PA  categorize (business or  research....) and filter if a proxy server re writing a url . 

for example 

if the original url is https://yyyy.com  and after rewriting  it became https://yyyy.com.proxy.mycompany.com 

Is there a possiblity  giving certificate error instead of giving  access deined   message (from palo alto  by url filtering)   to the 

End user 

Thanks

[Raido_Rattameister]

Most likely it will be categorized as "unknown"

If you block unknown category those sites will be blocked.

[simsim]

Hi,

Is there a possiblity  giving certificate error instead of giving  response page (from palo alto )  to the 

End user 

[Raido_Rattameister]

Initially I missed the part that it is https site.

Issue is that unless you decrypt traffic Palo does not see HTTP GET and it can identify only name on the certificate.

So if you don't decrypt https then https traffic might even be categorized correctly.

Can you check your URL Filter log to identify what category this URL is assigned to and what action fields shows.

What response page tells to be reason why was this site blocked?

[simsim]

Hi,

I can't find anything in the log related with the url,

the user getting an error like below  , I was assumming  PA doing something , 

I feel it like it happens after url filtering added in the policy .

Certificate seems to be ok .

What is your expert opinion 

Thanks

 

[BPry]

If this just started happening then Chrome's 58 update broke a large amount of MitM decryption/proxying methods. I would assume that you should likely take a look at your proxy if this is the case, it's likely that Chrome simply doesn't like that your proxy is feeding unencrypted traffic for domains that should be encrypted hence the warning message stating that traffic from/to facebook is usually encrypted but now it is not.

[simsim]

Hi,

It's not facebook , I just was showing the error . I am getting this error in firefox , chrome  (ver 57).

Is there something  needed to verified from PA side  finally as per your expert opinion 

Here what I am getting on the firefox 

Your connection is not private
Attackers might be trying to steal your information from yyyy.com.proxy.mycompany.com
(for example, passwords, messages or credit cards).
net-err_cert_common_name_invalid

Hide Advanced

This server could not prove that it is yyyy.com.proxy.mycompany.com ; its security certificate is from
*.proxy.mycompany.com.
This may be caused by a misconfiguration or an attacker intercepting your connection.
Proceed to yyyy.com.proxy.mycompany.com (unsafe)

proxy team blames PA : ) because of the sentence in the error message  "This may be caused by a misconfiguration or an attacker intercepting your connection." 

Thanks

[Raido_Rattameister]

You asked "Is there a possiblity  giving certificate error instead of giving  response page"

Well screenshot you posted is cert error.

Does this happen with every browser?

Does cert match url?

Is CA cert that SSL Proxy uses still valid or expired?

Find a site that resolves to single ip (not google or facebook).

Go to a site.

Close browser to end session.

Check traffic log towards this IP.

Click on mag glass to view session details.

What URL category you see?

With URL filtering if action is "allow" then category is permitted but log is not written. If action is "alert" category is permitted and log is writted to URL Filtering log.

[BPry]

@simsim,

So if I have this correct then the following is true.

1) You utilize a proxy server that is serperate from the Palo Alto deivce?

2) This was working and your Palo Alto is not a new install?

3) The after a set date 'just stopped' regardless of browser.

If that's the case then it sounds like your certificate that is fed from traffic delivered by your proxy has expired or in some way for some reason no longer trusted by your client devices.

Either the certificate just expired on your proxy, or the proxy server itself is new. I don't believe that the Palo Alto is really playing a part in this at all unless this is a brand new deployment.

[gwesson]

The answer is actually in the recent update:

---

@BPry wrote:

Attackers might be trying to steal your information from yyyy.com.proxy.mycompany.com
(for example, passwords, messages or credit cards).
net-err_cert_common_name_invalid

Hide Advanced

This server could not prove that it is yyyy.com.proxy.mycompany.com ; its security certificate is from
*.proxy.mycompany.com.

The certificate on the proxy is wrong. Each "dot" is literal when it comes to wildcard certificates. If it's for *.example.com, but the URI requested is alpha.bravo.example.com, then it won't match. If you want to match on those, your cert would need to have a Subject Alternative Name field of at least:

*.example.com

*.*.example.com

Each subdomain level needs a separate *. for itself. 

The reason you're getting the HSTS message is that you had previously gone to the site in that browser and it pinned the certificate from before.

[simsim]

Hi,

This is the  vendor   requirement for wildcard .

This is their defenition of  wildcard 

In the following, Regular refers to a certificate that is issued in the exact name of your EZproxy server (e.g., ezproxy.yourlib.org) whereas Wildcard refers to a certificate that is issued as *. followed by the exact name of your EZproxy server (e.g., *.ezproxy.yourlib.org). These form of certificate names are the two types that can be created from within the SSL configuration option provided by EZproxy.

( we choose the above )

If you create a wildcard certificate outside of EZproxy that is a wildcard for your domain (e.g., *.yourlib.org) and if you are using proxy by hostname, you must edit config.txt and add "Option IgnoreWildcardCertificate" to indicate that your wildcard is not in the form EZproxy expects. If you do this, your wildcard certificate will behave as a Regular certificate, which includes providing browser warnings when https web sites are proxied.

Note on wildcard certificates: EZproxy expects the wildcard domain name to be specified with the CN element in the Subject field.  The non-wildcard domain should be specified as a DNS element in the Subject Alternative Name (SAN) field.

yyyy.com.proxy.mycompany.com

here yyyy.com a site which reside outside  and proxy.mycompany.com is   proxy server fqdn 

Thanks

[simsim]

Hi,

1) You utilize a proxy server that is serperate from the Palo Alto deivce?

yes 

2) This was working and your Palo Alto is not a new install?

yes 

3) The after a set date 'just stopped' regardless of browser.

let's say two persons are using same chrome or firefox ,for one person it works, the other one it does not .

And IE users almost it 's ok 

Thanks