Hi,
In general, the basic idea is this:
ACLs:
LARGEGROUP (eg. all users)
SMALLGROUP (subset of LARGEGROUP you want to further filter)
SMALLBLACKLIST (site list for SMALLGROUP)
http_access deny SMALLGROUP SMALLBLACKLIST
http_access allow LARGEGROUP [whatever]
http_access deny all
You could
Hi to all.
I block some webs for a group of users.
That users can use internet without problem, but... i block some web (social
networks).
In firefox, all work fine, when someone try to go to facebook for example,
they found with "access denied" (web from squid).
But, in Chrome.. they get this err
On 12/05/2017 08:50 AM, erdosain9 wrote:
> i block some web (social networks).
> In firefox, all work fine, when someone try to go to facebook for example,
> they found with "access denied" (web from squid).
> But, in Chrome.. they get this error "net::err_cert_common_name_invalid".
Does that erro
"Does that error match the generated certificate sent by Squid to a
blocked Chrome user? In other words, does that certificate have an
invalid common name (CN) field? "
No, is the same certificate.
"I suggest comparing the following two certificates:
* the certificate sent by Squid to a blocke
On 12/05/2017 10:05 AM, erdosain9 wrote:
> "Does that error match the generated certificate sent by Squid to a
> blocked Chrome user? In other words, does that certificate have an
> invalid common name (CN) field? "
> No, is the same certificate.
Your statement does not answer my question. I can
Hi, and thanks.
But, i dont get it, how this is possible, if the bumping is working well. I
mean, if all https is working with my certificate, except for those that i
block (from chrome). But the bumping is working well in Chrome and Firefox.
This is log from Chrome with port
1512501177.181
May it be
https://docs.diladele.com/faq/squid/chrome_ssl_filter/dns_does_not_exist.html ?
Best regards,
Rafael Akchurin
Op 5 dec. 2017 om 20:34 heeft erdosain9
mailto:erdosa...@gmail.com>> het volgende geschreven:
Hi, and thanks.
But, i dont get it, how this is possible, if the bumping is wor
On 06/12/17 06:29, Alex Rousskov wrote:
On 12/05/2017 10:05 AM, erdosain9 wrote:
"Does that error match the generated certificate sent by Squid to a
blocked Chrome user? In other words, does that certificate have an
invalid common name (CN) field? "
No, is the same certificate.
Your stateme
When i put the in Chrome
https://.sdfasdfasdfasdfasd.com
it produces the same error...
but this just happend with "https" and with chrome.. not with
firefox.
With firefox i get the error web pager from squid
Unable to determine IP address from host name
"www.sdfasdfasdfasdfa
On 05/12/17 13:07, erdosain9 wrote:
Thanks Amos.
Let's be clear ... this configuration was working exactly as I wanted it to.
The users in each of those groups (i-full, sin_autenticacion, i-limitados)
navigated without problems. So that they did not navigate, I simply took
them out of one of tho
On 06/12/17 09:01, erdosain9 wrote:
When i put the in Chrome
https://.sdfasdfasdfasdfasd.com
it produces the same error...
but this just happend with "https" and with chrome.. not with
firefox.
With firefox i get the error web pager from squid
Unable to determine IP addre
On 12/05/2017 12:33 PM, erdosain9 wrote:
> i dont get it, how this is possible, if the bumping is working well.
Depending on your configuration and traffic, Squid may have more origin
server information when generating certificates for (future)
successfully bumped connections compared to when ge
Everything can be much simpler. If the deny is redirected to the local
web server with https, and the server certificate does not have the
correct CN - or there is no subjectAltName - Chrome will give such an error.
06.12.2017 3:08, Alex Rousskov пишет:
> On 12/05/2017 12:33 PM, erdosain9 wrote:
PS. And, of course, both CN/subjectAltName should be resolvable by
client. If not - you will get such an error.
This, automatically, point us to DNS (internal) which must have local
zone to internal resolving resources such as proxy, local web, etc.
06.12.2017 5:17, Yuri пишет:
> Everything can
PPS. I want to add an obvious thing. Blocking https pages should also be
redirected to the https page. This is obvious and required by the RFC.
As I know. And the https page for the https deny must be opened
correctly by the client browser. It's simple.
06.12.2017 5:24, Yuri пишет:
> PS. And, of
To reiterate Alex, "yes you can".
Squid supports "proxy over TLS" as well as the old/default "proxy over TCP"
- you use the https_port option
...but getting browsers to support it is challenging. The best way would be
to create a WPAD file that tells browsers to use "HTTPS" instead of
"PROXY". Th
16 matches
Mail list logo