On 19.03.2012 07:35, Amos Jeffries wrote:
Tried the current 3.1.19 release?
Is the second HTTPS request even going through the proxy?
What is the rest of the config look like?
The partial piece of config you posted has no holes which this could be
using.
On 19.03.12 11:53, Milen Pankov wrote:
You are right that the https requests are not going through the proxy. I
can confirm with tcpdump that the traffic to the https sites is going
directly. In the access logs there are many TCP_DENIED messages at the
same time to some http addresses, which seem to be links in the https
site. It seems if client refuses authentication and he tries to open
https site he can open it directly, but if there are any http links in
the sites they go through the proxy and are denied. Also this seems not
to be a browser problem as I can confirm the same behavior with firefox
and opera on linux. According to me the right behavior should be to deny
the user access to the https site and to present him an error page.
it's impossible for the proxy to pass error page to the browser, when the
user bypasses the proxy and connects to the website directly.
You must deny direct access to HTTPS (port 443) sites by a firewall and
force browsers to use the proxy, if you want to control access on the
proxy.
However, as long as HTTPS is encrypted, the only way you can allow/deny
users using some sites, is having list of sites (IP addresses) that
will be allowed (and deny access to others) or denied (and allow access
to others).
--
Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I intend to live forever - so far so good.
