How to block login popup from remote site?

I wonder if I can even tell from the logs, for audit purposes, whether a 407 comes from UTM or the remote system?

The proxy logs will not for any 407 that it generates itself.

Note:

407 is for proxy authentication.  No websites should be sending a 407.
401 is for Unauthorized.  Websites should be send a 401 with WWW-Authenticate header to do authentication.

This is, of course, according to the specifications, which routinely get ignored.

When the UTM is used in Standard mode the client knows there is a proxy and the UTM does a 407.

When the UTM is used in Transparent mode the client does not know there is a proxy.  The UTM does a 302 to redirect the traffic to a local address, then 401 to authenticate, for 302 back to the original destination.

The proxy logs will not for any 407 that it generates itself.

Note:

407 is for proxy authentication.  No websites should be sending a 407.
401 is for Unauthorized.  Websites should be send a 401 with WWW-Authenticate header to do authentication.

This is, of course, according to the specifications, which routinely get ignored.

When the UTM is used in Standard mode the client knows there is a proxy and the UTM does a 407.

When the UTM is used in Transparent mode the client does not know there is a proxy.  The UTM does a 302 to redirect the traffic to a local address, then 401 to authenticate, for 302 back to the original destination.

Thank you for clarifying.  

This means I want to block 401, certainly if session is unencrypted and probably for anything not on a whitelist.  My guess was that it would be a feature request, but I was hopeful.

I am using standard proxy, so I should be able to find 401 in the logs.  Of course, that does not solve the risk of data loss in the form of exposed credentials.

Assuming for a moment we are talking about authentication using the HTTP protocol (not web logins like Facebook) then there are these types:

Basic - password is plaintext

NTLM - password is encrypted

Negotiate - Kerberos password is never sent (not even encrypted)

Layered on top of this is SSL.  If the connection is HTTPS then it is encrypted at that layer.

And finally layered on top of that is what the Web Browser trusts and is willing to send.  For IE, if the URI is a bare hostname (eg http://internalserver/foobar) then it will send credentials automatically (this is SSO Single Sign On).  If the URI is a full domain (eg http://internternalserver.mycompany.com/foobar) then it will not send credentials instead it will do a pop-up messagebox asking the user to fill in username and password (since it does not trust it and assumes that it does not want the computer credentials).  FF does something similar.  You can trust a site so that it will do authentication automatically.

AFAIK almost all intranet and internet authentication occurs using web form submissions and not using the HTTP protocol.

The only really insecure is Basic over HTTP.  However I would be suspicious of anything that goes over the internet that wants your credentials.  That being said, who knows what things like Office365 does.

Agreed.  Anything that produces a badic login pipup is suspicious, and the user's response is unprddictable especially because it is unusual.   All good readons to prevent it from happening.