Re: [squid-users] problem authentication ntlm with squid 3.5.21

[Amos Jeffries]

On 2017-01-04 03:14, ama...@tin.it wrote:

Hello
I upgrade squid from 3.4.9-20141203-r13193 to 3.5.21-20160908-
r14081 and I have a problem with authentication to ntlm in a
transparent configuration:
the squid doesn't switch to https and so it
doesn't authentication


This doesn't compute. Your config below has nothing to do with NTLM or 
HTTPS.




In my older version the configuration it so:


auth_param basic children 5
auth_param basic realm Squid proxy-caching
web server
auth_param basic credentialsttl 2 hours


Three problems here:

1) without a "program" line specified the above do nothing.

2) the above lines are for *Basic* auth, not NTLM.

3) "transparent" interception proxy cannot perform authentication.




cache_peer xxx.xxx.
xxx.xxx parent 3128 0 no-query no-digest sourcehash name=PRX_ONE

cache_peer yyy.yyy.yyy.yyy parent 3128 0 no-query no-digest sourcehash
name=PRX_TWO

that it works, but after I upgrade if I use http it
doesn't autheticate.


see above.

If the parent(s) are performing NTLM authentication you need the 
login=PASSTHRU option to be specified on the cache_peer lines and to 
remove the auth_param settings.


HTH
Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ssl_bump - peek & splice logging IP rather than server name

[Alex Rousskov]

On 01/03/2017 04:11 PM, Mark Hoare wrote:

> I think these are hangovers from earlier syntax (ssl_bump
> server-first all) which shouldn't be required under 3.5.

Please note that the depricated server-first is a "bumping" (not
splicing!) action, and you may see a lot more information in the
bumping-Squid logs, naturally.

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ssl_bump - peek & splice logging IP rather than server name

[Mark Hoare]

Thanks Eliezer,

I'm aiming for a configuration which logs all HTTP and HTTPS connections 
without performing any full ssl_bumping, which would need me to get devices to 
trust my CA cert. 

I have something similar with pfsense (which does log SNI/server name rather 
than IP & port) but I'm getting some strange behaviour so wanted to build an 
equivalent standalone squid server, with a more up to date version of squid. 

Will have another look at my pfsense ssl_bump config as there are some slight 
differences, but I think these are hangovers from earlier syntax (ssl_bump 
server-first all) which shouldn't be required under 3.5. 

Cheers

Mark

> On 3 Jan 2017, at 22:41, Eliezer Croitoru  wrote:
> 
> Hey Mark,
> 
> Squid in intercept or tproxy mode will know one thing about the 
> tunnel\connection: IP+port.
> Since you are using:
>> ssl_bump peek all
>> ssl_bump splice all
> 
> The connections will always be spliced and you will never see any url.(are 
> you expecting only the SNI or also the url?)
> I do not know but there might be a code that can report the SNI if exists in 
> the logs.
> Alex is better then me in this but I believe it should be possible as an 
> addition to the IP+PORT and not replacing them.
> 
> Eliezer
> 
> 
> Eliezer Croitoru
> Linux System Administrator
> Mobile: +972-5-28704261
> Email: elie...@ngtech.co.il
> 
> 
> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On 
> Behalf Of Mark Hoare
> Sent: Saturday, December 31, 2016 4:38 PM
> To: squid-users@lists.squid-cache.org
> Subject: [squid-users] ssl_bump - peek & splice logging IP rather than server 
> name
> 
> Hi,
> 
> I’m trying to setup policy based routing on a gateway device pointing at a 
> remote squid server to do transparent HTTP & HTTPS proxying with ssl_bump 
> (peek & splice)
> 
> After quite a bit of pain getting policy based routing working on the gateway 
> and local port redirection on the squid server, everything appears to be 
> working except the access log still refers to the destination IP address in 
> the TCP_TUNNEL rather than the SNI/TLS server name.
> 
> By increasing the debug level I can see that the SNI/TLS details are 
> definitely being obtained during the request processing but for some reason 
> they are not ending up in the access log.
> 
> Extract from cache log:
>> 2016/12/31 14:18:01.966 kid1| 83,7| bio.cc(1110) parseV3Hello: Found server 
>> name: www.ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,5| support.cc(259) ssl_verify_cb: SSL 
>> Certificate signature OK: /C=US/ST=California/L=Redwood City/O=Qualys, 
>> Inc./CN=ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying 
>> server domain www.ssllabs.com to certificate name/subjectAltName ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying 
>> server domain www.ssllabs.com to certificate name/subjectAltName 
>> *.ssllabs.com
>> 2016/12/31 14:18:02.383 kid1| 83,5| PeerConnector.cc(307) 
>> serverCertificateVerified: HTTPS server CN: ssllabs.com bumped: local=> IP removed>:57790 remote=64.41.200.100:443 FD 14 flags=1
> 
> Extract from access log:
>> 1483193882.790870  TCP_TUNNEL/200 5620 CONNECT 
>> 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -
> 
> From the output above I would have expected some of the server name info to 
> get into the access log.
> 
> Squid config below:
>> debug_options ALL,7
>> 
>> http_port 3128
>> 
>> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>> 
>> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>> 
>> cache_dir ufs /var/spool/squid 200 16 256
>> coredump_dir /var/spool/squid
>> 
>> acl localnet src 10.0.0.0/8# RFC1918 possible internal network
>> acl localnet src 172.16.0.0/12# RFC1918 possible internal network
>> acl localnet src 192.168.0.0/16# RFC1918 possible internal network
>> acl localnet src fc00::/7   # RFC 4193 local private network range
>> acl localnet src fe80::/10  # RFC 4291 link-local (directly plugged) 
>> machines
>> 
>> acl Safe_ports port 80# http
>> acl Safe_ports port 21# ftp
>> acl Safe_ports port 443# https
>> acl Safe_ports port 70# gopher
>> acl Safe_ports port 210# wais
>> acl Safe_ports port 1025-65535# unregistered ports
>> acl Safe_ports port 280# http-mgmt
>> acl Safe_ports port 488# gss-http
>> acl Safe_ports port 591# filemaker
>> acl Safe_ports port 777# multiling http
>> 
>> acl SSL_ports port 443
>> acl CONNECT method CONNECT
>> 
>> http_access deny !Safe_ports
>> http_access deny CONNECT !SSL_ports
>> 
>> http_access allow localhost manager
>> http_access deny manager
>> 
>> refresh_pattern ^ftp:144020%10080
>> refresh_pattern 

Re: [squid-users] ssl_bump - peek & splice logging IP rather than server name

[Alex Rousskov]

On 01/03/2017 03:41 PM, Eliezer  Croitoru wrote:

> Squid in intercept or tproxy mode will know one thing about the 
> tunnel\connection: IP+port.

... and SSL handshake information when peeking or staring at client/server.


> Since you are using:
>> ssl_bump peek all
>> ssl_bump splice all

> The connections will always be spliced and you will never see any
> url.(are you expecting only the SNI or also the url?)

AFAICT, Mark is expecting Squid to log one of the server names, not the
HTTP request URL.


> I do not know but there might be a code that can report the SNI if exists in 
> the logs.

According to squid.conf.documented, the following logformat %code is
supported in modern Squids:

> ssl::>sni   SSL client SNI sent to Squid. Available only
> after the peek, stare, or splice SSL bumping
> actions.

This %code is not in the default access.log line format, naturally.

Squid can also analyze CN and other server certificate fields, but there
is no code to log them IIRC.


Please note that the intercepted server IP address, the client-supplied
SNI name, the server-supplied common name (CN), the server-supplied
alternative names, and the host info in the encrypted client HTTP
request, may all be different.

Given the variety of information sources that might supply different
information, it is not clear to me whether %ru should be based on SNI
information when both TCP-level and SNI information is available. Or
should it be based on CN? Or perhaps on CN _unless_ SNI matches one of
the alternative names?? This is a complicated issue; even the smart
server_name ACL needs parameters to clarify what "server name(s)" the
admin really wants to use/trust...

According to Mark's email, %ru uses TCP-level info. We could either
change %ru to use the "latest" info (like the server_name ACL does) or
add a new logformat code that does that while leaving the old %ru and
friends alone. Given the complexity of the issue, the latter may be a
better approach.


HTH,

Alex.

> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On 
> Behalf Of Mark Hoare
> Sent: Saturday, December 31, 2016 4:38 PM
> To: squid-users@lists.squid-cache.org
> Subject: [squid-users] ssl_bump - peek & splice logging IP rather than server 
> name

> Extract from access log:
>> 1483193882.790870  TCP_TUNNEL/200 5620 CONNECT 
>> 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -

> From the output above I would have expected some of the server name info to 
> get into the access log.

>> http_port 3128
>>
>> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>>
>> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

>> ssl_bump peek all
>> ssl_bump splice all

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ssl_bump - peek & splice logging IP rather than server name

[Eliezer Croitoru]

Hey Mark,

Squid in intercept or tproxy mode will know one thing about the 
tunnel\connection: IP+port.
Since you are using:
> ssl_bump peek all
> ssl_bump splice all

The connections will always be spliced and you will never see any url.(are you 
expecting only the SNI or also the url?)
I do not know but there might be a code that can report the SNI if exists in 
the logs.
Alex is better then me in this but I believe it should be possible as an 
addition to the IP+PORT and not replacing them.

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Mark Hoare
Sent: Saturday, December 31, 2016 4:38 PM
To: squid-users@lists.squid-cache.org
Subject: [squid-users] ssl_bump - peek & splice logging IP rather than server 
name

Hi,

I’m trying to setup policy based routing on a gateway device pointing at a 
remote squid server to do transparent HTTP & HTTPS proxying with ssl_bump (peek 
& splice)

After quite a bit of pain getting policy based routing working on the gateway 
and local port redirection on the squid server, everything appears to be 
working except the access log still refers to the destination IP address in the 
TCP_TUNNEL rather than the SNI/TLS server name.

By increasing the debug level I can see that the SNI/TLS details are definitely 
being obtained during the request processing but for some reason they are not 
ending up in the access log.

Extract from cache log:
> 2016/12/31 14:18:01.966 kid1| 83,7| bio.cc(1110) parseV3Hello: Found server 
> name: www.ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,5| support.cc(259) ssl_verify_cb: SSL 
> Certificate signature OK: /C=US/ST=California/L=Redwood City/O=Qualys, 
> Inc./CN=ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying 
> server domain www.ssllabs.com to certificate name/subjectAltName ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying 
> server domain www.ssllabs.com to certificate name/subjectAltName *.ssllabs.com
> 2016/12/31 14:18:02.383 kid1| 83,5| PeerConnector.cc(307) 
> serverCertificateVerified: HTTPS server CN: ssllabs.com bumped: local= IP removed>:57790 remote=64.41.200.100:443 FD 14 flags=1

Extract from access log:
> 1483193882.790870  TCP_TUNNEL/200 5620 CONNECT 
> 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -

From the output above I would have expected some of the server name info to get 
into the access log.

Squid config below:
> debug_options ALL,7
> 
> http_port 3128
> 
> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem 
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> 
> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem 
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> 
> cache_dir ufs /var/spool/squid 200 16 256
> coredump_dir /var/spool/squid
> 
> acl localnet src 10.0.0.0/8   # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12# RFC1918 possible internal network
> acl localnet src 192.168.0.0/16   # RFC1918 possible internal network
> acl localnet src fc00::/7   # RFC 4193 local private network range
> acl localnet src fe80::/10  # RFC 4291 link-local (directly plugged) 
> machines
> 
> acl Safe_ports port 80# http
> acl Safe_ports port 21# ftp
> acl Safe_ports port 443   # https
> acl Safe_ports port 70# gopher
> acl Safe_ports port 210   # wais
> acl Safe_ports port 1025-65535# unregistered ports
> acl Safe_ports port 280   # http-mgmt
> acl Safe_ports port 488   # gss-http
> acl Safe_ports port 591   # filemaker
> acl Safe_ports port 777   # multiling http
> 
> acl SSL_ports port 443
> acl CONNECT method CONNECT
> 
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> 
> http_access allow localhost manager
> http_access deny manager
> 
> refresh_pattern ^ftp: 144020% 10080
> refresh_pattern ^gopher:  14400%  1440
> refresh_pattern -i (/cgi-bin/|\?) 0   0%  0
> refresh_pattern . 0   20% 4320
> 
> ssl_bump peek all
> ssl_bump splice all
> 
> always_direct allow all
> 
> http_access allow localnet
> http_access allow localhost
> 
> http_access deny all


Any suggestions gratefully received.

Thanks

Mark
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Eliezer Croitoru]

If you get stuck with things contact me and I will see if I can sort things out 
so you would be able to grasp couple basics.

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Hoggins!
Sent: Tuesday, January 3, 2017 3:13 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Intercept mode failing

Hello Amos,

I believe my main problem is that I'm trying to apply recipes without 
understanding some of the internals, so it seems difficult to adapt.
I'll keep searching.

Thanks anyway !

Hoggins!

Le 03/01/2017 à 12:39, Amos Jeffries a écrit :
> On 2017-01-03 23:53, Hoggins! wrote:
>> Hello,
>>
>> (answering to both Amos and Antony here, you got the same questioning
>> ;) )
>>
>> Le 03/01/2017 à 11:45, Amos Jeffries a écrit :
>>> On 2017-01-03 23:13, Hoggins! wrote:
 Okay, I get that.

 Le 03/01/2017 à 10:33, Antony Stone a écrit :
> No - you must do the NAT (or REDIRECT) rule *on the Squid server*.

 Well, my Squid server is not on the same network as my clients, so 
 I need something else than just a REDIRECT on the Squid itself.
>>>
>>> That does not matter when the DNAT or REDIRECT is done on the Squid 
>>> machine.
>>
>> OK, I'll have a deeper look into that, indeed I'm not familiar with 
>> what REDIRECT *exactly* does.
>>
>
> It does the same as DNAT, but using the machines "primary" IP address 
> instead of one you configure. Usually that means the first IP assigned 
> to eth0 or equivalent first interface.
>
> DNAT is best if you want a specific fixed IP:port for Squid to receive 
> on.
>
> REDIRECT is best if you want the proxy to be plug-n-play on any 
> network. squid.conf and iptables not needing IP address, just a port 
> number.
>
>
>>>

>
> If you need to use policy routing to get the packets to the Squid 
> machine in the first place, that's okay, but this *must* be packet 
> routing, not address translation

 Policy routing was my first choice, but there is one important 
 detail in my setup : between my gateway (192.168.22.10) and my 
 Squid (192.168.55.3), there's an IPSec tunnel. My gateway does not 
 have a link-local route to 192.168.55.3 so I can't add the default 
 route to it inside a routing table (I get "Network is unreachable", 
 which is expected).

 So I guess I'm stuck.
>>>
>>>
>>> So how did the packets get to the Squid machine after your DNAT ?
>>>
>>> The route does not have to be link-local. Any type of route will do 
>>> so long as all the routers handling the packets know which way to 
>>> pass them, and the dst-IP address is not changed.
>>
>> Well, xfrm routing is a lot different than "classic" routing, I 
>> learnt it the hard way. DNAT *will* work whereas policy routing won't 
>> if I don't explicitly declare all my subnets in my IPSec tunnel 
>> configuration. Got a big discussion about that on StrongSwan's 
>> mailing-list, and I believe this sums it up pretty nicely :
>> http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9
>> .png
>>
>
> Looks like a simplified version of the netfilter devs official diagram 
> to me. So all the required decision points are present and should be 
> configurable.
>
>>
>> Anyway, yes, if I try to add a route by :
>> ip route add default via  table 123
>>
>>  *has* to be directly reachable. Or it has to be in the 
>> routing table somehow. But the routing table handling the tunnelled 
>> packets is not managed by iproute2.
>
> It should "simply" be one of the tables with a value other than "123".
> But that should not be a consideration as editing it is not necessary.
> This "123" routing is only relevant *before* packets enter the tunnel, 
> since it is what tells the OS to send packets to the tunnel.
>
> IIRC the routing table for HTTP traffic (your '123' table) should 
> indicate the tunnel as the gateway . I don't recall 
> whether that gw was needing to be the local or the remote tunnel 
> endpoint though sorry, been too long since I set one of these up.
>
>>
>> So as I can't do otherwise, I'm going to experiment a bit more with 
>> the REDIRECT + DNAT between the gateway and the Squid server.
>>
>
> I think you are misinterpreting that diagram in regards to the policy 
> routing setup.
>
> What we have on the squid wiki on "Policy Routing" makes packets 
> follow this path;
>
>  * the PREROUTING "mangle" table sets marks on packets to be delivered 
> to Squid.
>
>  * those packets go through the "FORWARD" to that gateway in 
> '123'/'proxy' table.
>   (in our wiki that is the "ip rule add fwmark 2 table ..." part).
>
>  * after POSTROUTING the packets destined to a tunnel gateway are 
> diverted at that last-minute decision point after "QoS egress" so they 
> go back to "OUTPUT" which is where the tunnel related things are done 
> to it.

Re: [squid-users] ssl_bump - peek & splice logging IP rather than server name

[Mark Hoare]

Sorry, should have included squid version details in original post:

Squid Cache: Version 3.5.20
Service Name: squid
configure options:  '--build=x86_64-redhat-linux-gnu' 
'--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' 
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' 
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' 
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' 
'--disable-strict-error-checking' '--exec_prefix=/usr' 
'--libexecdir=/usr/lib64/squid' '--localstatedir=/var' 
'--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' 
'--with-logdir=$(localstatedir)/log/squid' 
'--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' 
'--enable-eui' '--enable-follow-x-forwarded-for' '--enable-auth' 
'--enable-auth-basic=DB,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,SMB_LM,getpwnam'
 '--enable-auth-ntlm=smb_lm,fake' '--enable-auth-digest=file,LDAP,eDirectory' 
'--enable-auth-negotiate=kerberos' 
'--enable-external-acl-helpers=file_userip,LDAP_group,time_quota,session,unix_group,wbinfo_group'
 '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' 
'--enable-delay-pools' '--enable-epoll' '--enable-ident-lookups' 
'--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' 
'--enable-ssl-crtd' '--enable-storeio=aufs,diskd,ufs' '--enable-wccpv2' 
'--enable-esi' '--enable-ecap' '--with-aio' '--with-default-user=squid' 
'--with-dl' '--with-openssl' '--with-pthreads' '--disable-arch-native' 
'--disable-icap-client' 'build_alias=x86_64-redhat-linux-gnu' 
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -fpie' 
'LDFLAGS=-Wl,-z,relro  -pie -Wl,-z,relro -Wl,-z,now' 'CXXFLAGS=-O2 -g -pipe 
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -fpie' 
'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig’

Cheers

Mark

> On 31 Dec 2016, at 14:37, Mark Hoare  wrote:
> 
> Hi,
> 
> I’m trying to setup policy based routing on a gateway device pointing at a 
> remote squid server to do transparent HTTP & HTTPS proxying with ssl_bump 
> (peek & splice)
> 
> After quite a bit of pain getting policy based routing working on the gateway 
> and local port redirection on the squid server, everything appears to be 
> working except the access log still refers to the destination IP address in 
> the TCP_TUNNEL rather than the SNI/TLS server name.
> 
> By increasing the debug level I can see that the SNI/TLS details are 
> definitely being obtained during the request processing but for some reason 
> they are not ending up in the access log.
> 
> Extract from cache log:
>> 2016/12/31 14:18:01.966 kid1| 83,7| bio.cc(1110) parseV3Hello: Found server 
>> name: www.ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,5| support.cc(259) ssl_verify_cb: SSL 
>> Certificate signature OK: /C=US/ST=California/L=Redwood City/O=Qualys, 
>> Inc./CN=ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying 
>> server domain www.ssllabs.com to certificate name/subjectAltName ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying 
>> server domain www.ssllabs.com to certificate name/subjectAltName 
>> *.ssllabs.com
>> 2016/12/31 14:18:02.383 kid1| 83,5| PeerConnector.cc(307) 
>> serverCertificateVerified: HTTPS server CN: ssllabs.com bumped: local=> IP removed>:57790 remote=64.41.200.100:443 FD 14 flags=1
> 
> Extract from access log:
>> 1483193882.790870  TCP_TUNNEL/200 5620 CONNECT 
>> 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -
> 
> From the output above I would have expected some of the server name info to 
> get into the access log.
> 
> Squid config below:
>> debug_options ALL,7
>> 
>> http_port 3128
>> 
>> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>> 
>> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem 
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>> 
>> cache_dir ufs /var/spool/squid 200 16 256
>> coredump_dir /var/spool/squid
>> 
>> acl localnet src 10.0.0.0/8  # RFC1918 possible internal network
>> acl localnet src 172.16.0.0/12   # RFC1918 possible internal network
>> acl localnet src 192.168.0.0/16  # RFC1918 possible internal network
>> acl localnet src fc00::/7   # RFC 4193 local private network range
>> acl localnet src fe80::/10  # RFC 4291 link-local (directly plugged) 
>> machines
>> 
>> acl Safe_ports port 80   # http
>> acl Safe_ports port 21   # ftp
>> acl Safe_ports port 443  # https
>> acl Safe_ports port 

[squid-users] problem authentication ntlm with squid 3.5.21

[ama...@tin.it]

Hello
I upgrade squid from 3.4.9-20141203-r13193 to 3.5.21-20160908-
r14081 and I have a problem with authentication to ntlm in a 
transparent configuration:
the squid doesn't switch to https and so it 
doesn't authentication
In my older version the configuration it so:


auth_param basic children 5
auth_param basic realm Squid proxy-caching 
web server
auth_param basic credentialsttl 2 hours

cache_peer xxx.xxx.
xxx.xxx parent 3128 0 no-query no-digest sourcehash name=PRX_ONE

cache_peer yyy.yyy.yyy.yyy parent 3128 0 no-query no-digest sourcehash 
name=PRX_TWO

that it works, but after I upgrade if I use http it 
doesn't autheticate.
Thank you

Best regards,
Mau
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Hoggins!]

Ah !

Le 03/01/2017 à 13:53, Eliezer Croitoru a écrit :
> Hey,
>
> There is also another option.
> You can open a tunnel (IPIP, GRE, OTHER) between the proxy and the router to 
> make it possible to directly route traffic to the proxy.

That would actually solve a lot of my problems.

>
> If you need some help with it let me know.
>
> Eliezer 
>
> 
> Eliezer Croitoru
> Linux System Administrator
> Mobile: +972-5-28704261
> Email: elie...@ngtech.co.il
>
>
> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On 
> Behalf Of Hoggins!
> Sent: Tuesday, January 3, 2017 12:54 PM
> To: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] Intercept mode failing
>
> Hello,
>
> (answering to both Amos and Antony here, you got the same questioning ;) )
>
> Le 03/01/2017 à 11:45, Amos Jeffries a écrit :
>> On 2017-01-03 23:13, Hoggins! wrote:
>>> Okay, I get that.
>>>
>>> Le 03/01/2017 à 10:33, Antony Stone a écrit :
 No - you must do the NAT (or REDIRECT) rule *on the Squid server*.
>>> Well, my Squid server is not on the same network as my clients, so I 
>>> need something else than just a REDIRECT on the Squid itself.
>> That does not matter when the DNAT or REDIRECT is done on the Squid 
>> machine.
> OK, I'll have a deeper look into that, indeed I'm not familiar with what 
> REDIRECT *exactly* does.
>
 If you need to use policy routing to get the packets to the Squid 
 machine in the first place, that's okay, but this *must* be packet 
 routing, not address translation
>>> Policy routing was my first choice, but there is one important detail 
>>> in my setup : between my gateway (192.168.22.10) and my Squid 
>>> (192.168.55.3), there's an IPSec tunnel. My gateway does not have a 
>>> link-local route to 192.168.55.3 so I can't add the default route to 
>>> it inside a routing table (I get "Network is unreachable", which is 
>>> expected).
>>>
>>> So I guess I'm stuck.
>>
>> So how did the packets get to the Squid machine after your DNAT ?
>>
>> The route does not have to be link-local. Any type of route will do so 
>> long as all the routers handling the packets know which way to pass 
>> them, and the dst-IP address is not changed.
> Well, xfrm routing is a lot different than "classic" routing, I learnt it the 
> hard way. DNAT *will* work whereas policy routing won't if I don't explicitly 
> declare all my subnets in my IPSec tunnel configuration. Got a big discussion 
> about that on StrongSwan's mailing-list, and I believe this sums it up pretty 
> nicely :
> http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png
>
> Anyway, yes, if I try to add a route by :
> ip route add default via  table 123
>
>  *has* to be directly reachable. Or it has to be in the routing 
> table somehow. But the routing table handling the tunnelled packets is not 
> managed by iproute2.
>
> So as I can't do otherwise, I'm going to experiment a bit more with the 
> REDIRECT + DNAT between the gateway and the Squid server.
>
> Thanks for your help !
>
>> Amos
>>
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>
>
>




signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Eliezer Croitoru]

Hey,

There is also another option.
You can open a tunnel (IPIP, GRE, OTHER) between the proxy and the router to 
make it possible to directly route traffic to the proxy.

If you need some help with it let me know.

Eliezer 


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Hoggins!
Sent: Tuesday, January 3, 2017 12:54 PM
To: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Intercept mode failing

Hello,

(answering to both Amos and Antony here, you got the same questioning ;) )

Le 03/01/2017 à 11:45, Amos Jeffries a écrit :
> On 2017-01-03 23:13, Hoggins! wrote:
>> Okay, I get that.
>>
>> Le 03/01/2017 à 10:33, Antony Stone a écrit :
>>> No - you must do the NAT (or REDIRECT) rule *on the Squid server*.
>>
>> Well, my Squid server is not on the same network as my clients, so I 
>> need something else than just a REDIRECT on the Squid itself.
>
> That does not matter when the DNAT or REDIRECT is done on the Squid 
> machine.

OK, I'll have a deeper look into that, indeed I'm not familiar with what 
REDIRECT *exactly* does.

>
>>
>>>
>>> If you need to use policy routing to get the packets to the Squid 
>>> machine in the first place, that's okay, but this *must* be packet 
>>> routing, not address translation
>>
>> Policy routing was my first choice, but there is one important detail 
>> in my setup : between my gateway (192.168.22.10) and my Squid 
>> (192.168.55.3), there's an IPSec tunnel. My gateway does not have a 
>> link-local route to 192.168.55.3 so I can't add the default route to 
>> it inside a routing table (I get "Network is unreachable", which is 
>> expected).
>>
>> So I guess I'm stuck.
>
>
> So how did the packets get to the Squid machine after your DNAT ?
>
> The route does not have to be link-local. Any type of route will do so 
> long as all the routers handling the packets know which way to pass 
> them, and the dst-IP address is not changed.

Well, xfrm routing is a lot different than "classic" routing, I learnt it the 
hard way. DNAT *will* work whereas policy routing won't if I don't explicitly 
declare all my subnets in my IPSec tunnel configuration. Got a big discussion 
about that on StrongSwan's mailing-list, and I believe this sums it up pretty 
nicely :
http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png

Anyway, yes, if I try to add a route by :
ip route add default via  table 123

 *has* to be directly reachable. Or it has to be in the routing 
table somehow. But the routing table handling the tunnelled packets is not 
managed by iproute2.

So as I can't do otherwise, I'm going to experiment a bit more with the 
REDIRECT + DNAT between the gateway and the Squid server.

Thanks for your help !

>
> Amos
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>



___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Amos Jeffries]

On 2017-01-03 23:53, Hoggins! wrote:

Hello,

(answering to both Amos and Antony here, you got the same questioning 
;) )


Le 03/01/2017 à 11:45, Amos Jeffries a écrit :

On 2017-01-03 23:13, Hoggins! wrote:

Okay, I get that.

Le 03/01/2017 à 10:33, Antony Stone a écrit :

No - you must do the NAT (or REDIRECT) rule *on the Squid server*.


Well, my Squid server is not on the same network as my clients, so I
need something else than just a REDIRECT on the Squid itself.


That does not matter when the DNAT or REDIRECT is done on the Squid
machine.


OK, I'll have a deeper look into that, indeed I'm not familiar with 
what

REDIRECT *exactly* does.



It does the same as DNAT, but using the machines "primary" IP address 
instead of one you configure. Usually that means the first IP assigned 
to eth0 or equivalent first interface.


DNAT is best if you want a specific fixed IP:port for Squid to receive 
on.


REDIRECT is best if you want the proxy to be plug-n-play on any network. 
squid.conf and iptables not needing IP address, just a port number.









If you need to use policy routing to get the packets to the Squid
machine in
the first place, that's okay, but this *must* be packet routing, not
address
translation


Policy routing was my first choice, but there is one important detail 
in

my setup : between my gateway (192.168.22.10) and my Squid
(192.168.55.3), there's an IPSec tunnel. My gateway does not have a
link-local route to 192.168.55.3 so I can't add the default route to 
it

inside a routing table (I get "Network is unreachable", which is
expected).

So I guess I'm stuck.



So how did the packets get to the Squid machine after your DNAT ?

The route does not have to be link-local. Any type of route will do so
long as all the routers handling the packets know which way to pass
them, and the dst-IP address is not changed.


Well, xfrm routing is a lot different than "classic" routing, I learnt
it the hard way. DNAT *will* work whereas policy routing won't if I
don't explicitly declare all my subnets in my IPSec tunnel
configuration. Got a big discussion about that on StrongSwan's
mailing-list, and I believe this sums it up pretty nicely :
http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png


Looks like a simplified version of the netfilter devs official diagram 
to me. So all the required decision points are present and should be 
configurable.




Anyway, yes, if I try to add a route by :
ip route add default via  table 123

 *has* to be directly reachable. Or it has to be in the
routing table somehow. But the routing table handling the tunnelled
packets is not managed by iproute2.


It should "simply" be one of the tables with a value other than "123". 
But that should not be a consideration as editing it is not necessary. 
This "123" routing is only relevant *before* packets enter the tunnel, 
since it is what tells the OS to send packets to the tunnel.


IIRC the routing table for HTTP traffic (your '123' table) should 
indicate the tunnel as the gateway . I don't recall whether 
that gw was needing to be the local or the remote tunnel endpoint though 
sorry, been too long since I set one of these up.




So as I can't do otherwise, I'm going to experiment a bit more with the
REDIRECT + DNAT between the gateway and the Squid server.



I think you are misinterpreting that diagram in regards to the policy 
routing setup.


What we have on the squid wiki on "Policy Routing" makes packets follow 
this path;


 * the PREROUTING "mangle" table sets marks on packets to be delivered 
to Squid.


 * those packets go through the "FORWARD" to that gateway in 
'123'/'proxy' table.

  (in our wiki that is the "ip rule add fwmark 2 table ..." part).

 * after POSTROUTING the packets destined to a tunnel gateway are 
diverted at that last-minute decision point after "QoS egress" so they 
go back to "OUTPUT" which is where the tunnel related things are done to 
it.


Note that for the machine where the tunnel leads *from*, all that 
matters is routing the packets into the tunnel. Once packets are 
encapsulated by the tunnel they simply go through it to the other end. 
The receiving machine does whatever it needs to after the packets leave 
the tunnel.


HTH
Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid tproxy connection time out

[mrghorbani]

also what about this topology?
 



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-tproxy-connection-time-out-tp4681027p4681044.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid3 configure to force access to the facebook by the proxy

[Hardik Dangar]

I am not sure why you would need that many ports. if you think each port is
for each user or some other misconcept then let me tell you, you can route
all your hosts and traffic from single port only.

On Tue, Jan 3, 2017 at 4:06 PM, hitman13 
wrote:

> Hi guys, I'm new to linux
> And I need to configure squid3 on UBUNTU SERVER 16.04
>
> But I need to force facebook access through the proxy
> And it has multi-ports, I actually need many
> EX:
> 52.xx.6.214: 3128
> 52.xx.6.214: 3129
> 52.xx.6.214: 3130
> 52.xx.6.214:  as much as possible
>
> So that when you need access by the mozilla can always pick up a new port
>
> Thank you very much in advance.
>
>
>
> --
> View this message in context: http://squid-web-proxy-cache.
> 1019090.n4.nabble.com/Squid3-configure-to-force-access-to-
> the-facebook-by-the-proxy-tp4681041.html
> Sent from the Squid - Users mailing list archive at Nabble.com.
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Hoggins!]

Hello,

(answering to both Amos and Antony here, you got the same questioning ;) )

Le 03/01/2017 à 11:45, Amos Jeffries a écrit :
> On 2017-01-03 23:13, Hoggins! wrote:
>> Okay, I get that.
>>
>> Le 03/01/2017 à 10:33, Antony Stone a écrit :
>>> No - you must do the NAT (or REDIRECT) rule *on the Squid server*.
>>
>> Well, my Squid server is not on the same network as my clients, so I
>> need something else than just a REDIRECT on the Squid itself.
>
> That does not matter when the DNAT or REDIRECT is done on the Squid
> machine.

OK, I'll have a deeper look into that, indeed I'm not familiar with what
REDIRECT *exactly* does.

>
>>
>>>
>>> If you need to use policy routing to get the packets to the Squid
>>> machine in
>>> the first place, that's okay, but this *must* be packet routing, not
>>> address
>>> translation
>>
>> Policy routing was my first choice, but there is one important detail in
>> my setup : between my gateway (192.168.22.10) and my Squid
>> (192.168.55.3), there's an IPSec tunnel. My gateway does not have a
>> link-local route to 192.168.55.3 so I can't add the default route to it
>> inside a routing table (I get "Network is unreachable", which is
>> expected).
>>
>> So I guess I'm stuck.
>
>
> So how did the packets get to the Squid machine after your DNAT ?
>
> The route does not have to be link-local. Any type of route will do so
> long as all the routers handling the packets know which way to pass
> them, and the dst-IP address is not changed.

Well, xfrm routing is a lot different than "classic" routing, I learnt
it the hard way. DNAT *will* work whereas policy routing won't if I
don't explicitly declare all my subnets in my IPSec tunnel
configuration. Got a big discussion about that on StrongSwan's
mailing-list, and I believe this sums it up pretty nicely :
http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png

Anyway, yes, if I try to add a route by :
ip route add default via  table 123

 *has* to be directly reachable. Or it has to be in the
routing table somehow. But the routing table handling the tunnelled
packets is not managed by iproute2.

So as I can't do otherwise, I'm going to experiment a bit more with the
REDIRECT + DNAT between the gateway and the Squid server.

Thanks for your help !

>
> Amos
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>




signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid3 configure to force access to the facebook by the proxy

[hitman13]

Hi guys, I'm new to linux
And I need to configure squid3 on UBUNTU SERVER 16.04

But I need to force facebook access through the proxy
And it has multi-ports, I actually need many
EX:
52.xx.6.214: 3128
52.xx.6.214: 3129
52.xx.6.214: 3130
52.xx.6.214:  as much as possible

So that when you need access by the mozilla can always pick up a new port

Thank you very much in advance.



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid3-configure-to-force-access-to-the-facebook-by-the-proxy-tp4681041.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid tproxy connection time out

[mrghorbani]

hello,
i had created the topology diagram as i get from your idea, does it that you
mentioned?
but, according to that my bgp and wireless points are connected to mikrotik
router, i can not move squid to the end point...in this network, now and in
exists network, i routed the client to the mikrotik  as gw and then routed
him by mikrotik to squid so, now, mikrotik is between the client and squid
but in virtuality
 



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-tproxy-connection-time-out-tp4681027p4681040.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Amos Jeffries]

On 2017-01-03 23:13, Hoggins! wrote:

Okay, I get that.

Le 03/01/2017 à 10:33, Antony Stone a écrit :

No - you must do the NAT (or REDIRECT) rule *on the Squid server*.


Well, my Squid server is not on the same network as my clients, so I
need something else than just a REDIRECT on the Squid itself.


That does not matter when the DNAT or REDIRECT is done on the Squid 
machine.






If you need to use policy routing to get the packets to the Squid 
machine in
the first place, that's okay, but this *must* be packet routing, not 
address

translation


Policy routing was my first choice, but there is one important detail 
in

my setup : between my gateway (192.168.22.10) and my Squid
(192.168.55.3), there's an IPSec tunnel. My gateway does not have a
link-local route to 192.168.55.3 so I can't add the default route to it
inside a routing table (I get "Network is unreachable", which is 
expected).


So I guess I'm stuck.



So how did the packets get to the Squid machine after your DNAT ?

The route does not have to be link-local. Any type of route will do so 
long as all the routers handling the packets know which way to pass 
them, and the dst-IP address is not changed.


Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Antony Stone]

On Tuesday 03 January 2017 at 11:13:33, Hoggins! wrote:

> Okay, I get that.
> 
> Le 03/01/2017 à 10:33, Antony Stone a écrit :
> > No - you must do the NAT (or REDIRECT) rule *on the Squid server*.
> 
> Well, my Squid server is not on the same network as my clients, so I
> need something else than just a REDIRECT on the Squid itself.

I'm not sure you fully understand what REDIRECT does.  It changes the 
destination address of the packets which *were* going to random web servers 
around the Internet, and have now reached your Squid box, so thatthey go to 
the local address of your Squid machien instead (and therefore Squid can see 
them and process them).

> > If you need to use policy routing to get the packets to the Squid machine
> > in the first place, that's okay, but this *must* be packet routing, not
> > address translation
> 
> Policy routing was my first choice, but there is one important detail in
> my setup : between my gateway (192.168.22.10) and my Squid
> (192.168.55.3), there's an IPSec tunnel. My gateway does not have a
> link-local route to 192.168.55.3 so I can't add the default route to it
> inside a routing table (I get "Network is unreachable", which is expected).

So, if you can't route packets from the gateway to Squid, how was your NAT 
setup getting them there?

You said in your original posting: "192.168.55.3 being the Squid server, 
directly connected to the Internet, on a network my gateway has the routes 
for", suggesting that your gateway *can* route to the Squid server.

> So I guess I'm stuck.

Maybe you need to do policy routing on the gateway to the IPsec endpoint, and 
then further routing from there to Squid?


Antony.

-- 
"Remember: the S in IoT stands for Security."

 - Jan-Piet Mens

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid tproxy connection time out

[Omid Kosari]

Hello,

I think your problem is topology . I suggest change the position of squid so
the mikrotik router stands between clients and squid box .

Also assign a private ip address to your squid and also one ip from same
range to your mikrotik router . Then try to mangle and route to that private
ip .





--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-tproxy-connection-time-out-tp4681027p4681037.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Hoggins!]

Okay, I get that.

Le 03/01/2017 à 10:33, Antony Stone a écrit :
> No - you must do the NAT (or REDIRECT) rule *on the Squid server*.

Well, my Squid server is not on the same network as my clients, so I
need something else than just a REDIRECT on the Squid itself.

>
> If you need to use policy routing to get the packets to the Squid machine in 
> the first place, that's okay, but this *must* be packet routing, not address 
> translation

Policy routing was my first choice, but there is one important detail in
my setup : between my gateway (192.168.22.10) and my Squid
(192.168.55.3), there's an IPSec tunnel. My gateway does not have a
link-local route to 192.168.55.3 so I can't add the default route to it
inside a routing table (I get "Network is unreachable", which is expected).

So I guess I'm stuck.

Thanks anyway !

Hoggins!



signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Intercept mode failing

[Antony Stone]

On Tuesday 03 January 2017 at 10:17:54, Hoggins! wrote:

> Hello list,
> 
> I'm trying to do a simple intercept with Squid. Here is my setup :
> 
> I have a LAN with machines on 192.168.22.0/24. Their gateway is
> 192.168.22.10. On this machine, I have set the following iptables rule :
> 
> iptables -t nat -A PREROUTING -i eth0.100 ! -d 192.168.0.0/16 -p tcp
> --dport 80 -j DNAT --to 192.168.55.3:3129
> 
> - 192.168.55.3 being the Squid server

No - you must do the NAT (or REDIRECT) rule *on the Squid server*.

If you need to use policy routing to get the packets to the Squid machine in 
the first place, that's okay, but this *must* be packet routing, not address 
translation.

See http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat 
http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect and 
http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute


Antony.

-- 
In Heaven, the beer is Belgian, the chefs are Italian, the supermarkets are 
British, the mechanics are German, the lovers are French, the entertainment is 
American, and everything is organised by the Swiss.

In Hell, the beer is American, the chefs are British, the supermarkets are 
German, the mechanics are French, the lovers are Swiss, the entertainment is 
Belgian, and everything is organised by the Italians.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Intercept mode failing

[Hoggins!]

Hello list,

I'm trying to do a simple intercept with Squid. Here is my setup :

I have a LAN with machines on 192.168.22.0/24. Their gateway is
192.168.22.10. On this machine, I have set the following iptables rule :

iptables -t nat -A PREROUTING -i eth0.100 ! -d 192.168.0.0/16 -p tcp
--dport 80 -j DNAT --to 192.168.55.3:3129

- eth0.100 because it's on a VLAN
- 192.168.55.3 being the Squid server, directly connected to the
Internet, on a network my gateway has the routes for

On the Squid server (192.168.55.3), I have configured the following
options in squid.conf :

- (default localnet ACLs were fine, as well as Safe_ports setting)
- tcp_outgoing_address 1.2.3.4 (the public address the server is
attached to. There are several interfaces)
- http_port 3129 intercept
- http_access allow localnet
- http_access allow localhost
- http_access deny all

Now, if I issue a curl http://google.fr on a LAN machine
(192.168.22.129), I get the Squid error page saying "Acces Denied", and
the Squid server log shows the following :

1483434892.803  0 1.2.3.4 TCP_DENIED/403 4032 GET
http://google.fr/ - HIER_NONE/- text/html
1483434892.804 17 192.168.22.129 TCP_MISS/403 4146 GET
http://google.fr/ - ORIGINAL_DST/192.168.55.3 text/html


"Normal" proxying works fine with this Squid setup (I also have a
"http_port 3128" with no option, and explicitly setting the proxy
address on the LAN hosts works fine).

Do you have an idea of what are my mistakes ?

Thank you for your inputs !

Hoggins!



signature.asc
Description: OpenPGP digital signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid Websocket Issue

[Amos Jeffries]

On 2017-01-03 05:49, Hardik Dangar wrote:

Hey Eliezer,

The issue was with whatsapp web socket was not working, here is
detailed information about issue


Here is some information about my squid version,

Squid Cache: Version 3.5.22-20161115-r14113
Service Name: squid
configure options:  '--prefix=/usr' '--localstatedir=/var/squid'
'--libexecdir=/lib/squid' '--srcdir=.' '--datadir=/share/squid'
'--sysconfdir=/etc/squid' '--with-default-user=proxy'
'--with-logdir=/var/log/squid' '--with-pidfile=/var/run/squid.pid'
'--with-openssl' '--enable-ssl-crtd' '--enable-inline'
'--disable-arch-native' '--enable-async-io=8'
'--enable-storeio=ufs,aufs,diskd,rock'
'--enable-removal-policies=lru,heap' '--enable-delay-pools'
'--enable-follow-x-forwarded-for' '--enable-url-rewrite-helpers=fake'
'--enable-ecap'

My squid config file is located at, http://pastebin.com/raw/LvDxEF4x

Now the issue is whenever someone requests a page which contains web
socket requests response is always bad request.
Here is an example,

Request URL:wss://w4.web.whatsapp.com/ws [1]
Request Method:GET
Status Code:400 Bad Request

Response Headers
#
Connection:keep-alive
Date:Sat, 17 Dec 2016 09:05:36 GMT
Transfer-Encoding:chunked
X-Cache:MISS from Proxy

Request Headers
#
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:Upgrade
Host:w4.web.whatsapp.com [2]
Origin:https://web.whatsapp.com
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:kzrB2ZcMHDAqvjDNXnjL/w==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/55.0.2883.75 Safari/537.36

My question is how we can work with web socket requests in squid or if
not by pass them squid. My squid instance is in interception mode and
requests are intercepted at instance via iptables and forwarded to
squid using below rules,


WebSockets has several ways to initiate connections:

1) native WebSocket port
 - requires any intermediary has native Websocket support

2) CONNECT tunnel (maybe with Upgrade)
 - requires only that the intermediary has HTTP CONNECT support

3) GET request with Upgrade
 - requires that the intermediary has both HTTP Upgrade and WebSockets 
native support



Squid supports method #2.

The transaction you are showing as broken is mechanism #3. Both the 
Upgrade and WebSockets support requirements are not existing in Squid.


That particular request going through a non-WebSockets proxy is supposed 
to be passed to the server as a regular GET request (without Upgrade). 
Exactly what Squid does. The server itself is producing the 400 response 
instead of using alternative things like HTTP long-polling in place of 
WebSockets. That is its choice, nothing to do with Squid and a perfectly 
valid choice on the servers part.


If WhatsApp tried the supported #2 mechanism it would work through 
Squid.





--

SOLUTION TO ABOVE PROBLEM WAS,



... to splice instead of bump.



So basically websockets are connected as normal https request( i think
this is a very nature of Web sockets and define somewhere in web
socket standards).


No, that is the nature of HTTPS when not being bump'ed. Squid is not 
involved in the encrypted request when splicing. So it does not matter 
if it really is HTTPS or actually encrypted WebSockets.


The HTTPS goes through Squid as a CONNECT tunnel. Which for WebSockets 
is connection method #2 above - which is supported and works.



I think your problem is that you are expecting unrealistic things from 
decrypted HTTPS. *HTTPS* being the critical word there. Bumping decrypts 
HTTPS, it does not decrypt other protocols - including WebSockets.


Since the WhatsApp traffic is/was intercepted the client software has no 
knowledge of the proxy existing so it is not realistic to expect it to 
attempt the CONNECT method, even as a failover.


Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 3.5.22 Bug when using Mimetype Detection? rep_mime_type

[Amos Jeffries]

On 2017-01-03 07:33, Flashdown wrote:

Hello together,

with Squid 3.5.22 I have switched from using a url-regex to Mime Type
Detection, which seemed to work nicely until now... :/



The thing to be very wary of with this change is that when reply 
blocking the request does still make it through to the server and any 
processing done there still happens.


With things like ticketing systems that means the tickets and any auth 
related token creating has actually happened, even if the client is 
prevented from being told what the created token was.


That is a major difference from URL based blocking, which would reject 
before any server contact.




OS: Debian Stretch 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13)
x86_64 GNU/Linux




I really advise going to 3.5.23. Several major issues about sending 
wrong replies on certain occasions were fixed there. New .deb should be 
available by now to fix that.





I faced the following Situation:

When I globally deny specific mimetypes using a blockfile, then it
performs as it should, so only mime types I defined in the block file
are getting blocked, so far so good.

When I do an exception for a group I belong to like unblocking
application/octet-stream, then I can download files, so the exception
works in the first place.
acl mime_IT rep_mime_type application/octet-stream
http_reply_access allow IT mime_IT

Normally internal targets are excluded from the Proxy using Proxy
Exception lists. But I do not get these settings automatically, so my
browser did not contain this exception so I was able to discover the
following behavior:

The Issue is occuring when browsing to an internal OTRS Web Server via
FQDN (It's a web ticket system) through the proxy I get "Access
Denied" from the Proxy on all requests. But when browsing to an online
OTRS Demo site with the same OTRS version like this one:
http://itsm-demo.otrs.com/otrs/index.pl then it works. When I now try
again to access the internal OTRS Server through the proxy it works.
That's strange, when I now force reload (CTRL+F5 in Firefox) the
internal OTRS Ticketsystems webpage, I get the "access denied" again.



How is the auth happening between the users and the proxy to find out 
what the groups are?

 The reply checks may be interferring with the auth replies.



When I remove the exception from the global block list for the group I
belong to,- here it's IT- then this issue does not occur and the
website is accessible like it should.
So I just need to comment out these lines:
#acl mime_IT rep_mime_type application/octet-stream
#http_reply_access allow IT mime_IT

When I add text/html & application/xml to the global block exception,
then this error does not occur anymore.
acl mime_IT rep_mime_type application/octet-stream text/html 
application/xml

http_reply_access allow IT mime_IT

So currently I can workaround the issue in 3 different ways:
1. Do not create a global mimetype block exception for groups I belong 
to

2. Browse to the start page of an Online Demo OTRS Site and then
reload the internal Website
3. Add text/html & application/xml to my exception even if these
Mimetypes are not part of the global block list, so they are not
supposed to be blocked. (I just looked at the internal website and it
just uses text/html and application/xml on the start page (Login Page)
so I added them to the exception list for my group and it worked)

Conclusion: When having a global mime type block and unblocking a
specific mime type for a specific group, then this group will most
propably face issues with mime types that are not supposed to be
blocked. So in case of errors, I need to unblock not blocked mimetypes
,too.


My Squid config for mime type blocking:
---
## Define Default MIMETYPE ERROR Message and global block access list
acl block_mimetypes rep_mime_type "/etc/squid/mimetype_blacklist.acl"
deny_info ERR_BLOCKED_FILES block_mimetypes

# Configure Execptions
acl mime_IT rep_mime_type application/octet-stream
http_reply_access allow IT mime_IT

acl mime_SpecialGroup rep_mime_type application/octet-stream
http_reply_access allow SpecialGroup mime_SpecialGroup


#Applying Global MimeType Block
http_reply_access deny block_mimetypes


Any other http_reply_access rules? the implicit-default behaviour may be 
having an effect if there are.




---
Squid main config:
---
http_port 8080 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=16MB cert=/*
ssl_bump splice localhost
ssl_bump splice SSL_Exclude


These splice rules may be related to the issue. Any connection that gets 
spliced may be used by other requests without squid being aware of them.



ssl_bump bump all
sslproxy_cert_error allow SSL_TrustedSites
sslproxy_cert_error deny all
---



Contents of mimetype_blacklist.acl:
---


That looks