hi all, my current setup: laptop(10.0.1.10) and squid-box(10.0.1.11) and
debian router(10.0.1.1).
I am doing wget on laptop
wget squid-cache.org
I am redirecting packets on the router to squid-box by changing the
destination MAC address and destination IP and port address. I am able to
see the p
On 26/01/2017 1:00 a.m., javier.sanchez wrote:
>
> Hi all.
>
>
> I using squid 3.4.8 over Debian as reverse proxy in order to protect
> with SSL some of our servers.
>
>
> How can I solve that? Is this a bug or something that can be solved
> changing configuration.
Please try th
On 25/01/2017 10:29 p.m., ho...@free.fr wrote:
>
> Hi everybody,
>
> I really try to find a answer with google, and within
> the archives of this mailing list but couldn't find anything
> so... here I am...
>
> I need to select a squid parent based on the login of the
> user (and others things).
On 27/01/2017 9:46 a.m., Yuri Voinov wrote:
>
>
> 27.01.2017 2:44, Matus UHLAR - fantomas пишет:
>>> 26.01.2017 2:22, boruc пишет:
After a little bit of analyzing requests and responses with WireShark I
noticed that many sites that weren't cached had different
combination of
b
On 27/01/2017 9:44 a.m., Matus UHLAR - fantomas wrote:
>> 26.01.2017 2:22, boruc пишет:
>>> After a little bit of analyzing requests and responses with WireShark I
>>> noticed that many sites that weren't cached had different combination of
>>> below parameters:
>>>
>>> Cache-Control: no-cache, no-
Is it stock REDHAT or CentOS or Other?
You can use the RPM's of squid I am building which are quite generic and works
very well.
I have just released 3.5.23 and 4.0.17.
I have built it both for RH and CentOS:
http://wiki.squid-cache.org/KnowledgeBase/CentOS#Squid-3.5
And you can take a peek and br
On 27/01/2017 11:08 a.m., reinerotto wrote:
>> reply_header_access Cache-Control deny all<
> Will this only affect downstream caches, or will this squid itself also
> ignore any Cache-Control header info
> received from upstream ?
>
It will only affect the clients caches. eg. their browser cache
On 01/26/2017 03:38 PM, Mark Hoare wrote:
> To reiterate, my desire is to have Squid running and capable of blocking
> access to http and https sites primarily based on the server name
> requested by the client (so no need to go beyond a peek)
... or even beyond a peek at the client.
> From eve
Alex/Eliezer,
Thanks for you earlier comments and apologies for not responding (and saying
thank you previously, squid got back-burnered unfortunately)
Getting logging working with transparent proxying was my initial step prior to
looking at restricting specific sites via either ACLs or a URL r
>reply_header_access Cache-Control deny all<
Will this only affect downstream caches, or will this squid itself also
ignore any Cache-Control header info
received from upstream ?
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Not-all-html-objects-are-being
On 26.01.17 08:41, Alexander wrote:
It seems that I have solved the issue by using nf_conntrack_ftp and
redirecting "NEW,RELATED" traffic to squid:
ftp_port 2121 intercept
modprobe nf_conntrack_ftp ports=2121
iptables -t nat -A PREROUTING -p tcp --dport 21 -j REDIRECT --to-port 2121
iptables -
27.01.2017 2:44, Matus UHLAR - fantomas пишет:
>> 26.01.2017 2:22, boruc пишет:
>>> After a little bit of analyzing requests and responses with WireShark I
>>> noticed that many sites that weren't cached had different
>>> combination of
>>> below parameters:
>>>
>>> Cache-Control: no-cache, no-st
26.01.2017 2:22, boruc пишет:
After a little bit of analyzing requests and responses with WireShark I
noticed that many sites that weren't cached had different combination of
below parameters:
Cache-Control: no-cache, no-store, must-revalidate, post-check, pre-check,
private, public, max-age, pu
On 01/26/2017 03:16 AM, Vieri wrote:
> I'm guessing that it
> should be possible for Squid to tell OpenSSL to report what it
> actually said to the server without the need for an admin to do a
> traffic dump and analysis.
Your are correct, but, in most cases, it is a lot easier to dump and
analyz
Well, actually these rules are just a kind of proof of concept and there is
something to think about later. The redirection rule should be more precise
and include destination address. Also, 'NEW' state should probably be
excluded from the list.
--
View this message in context:
http://squid-web
On Thursday 26 January 2017 at 17:41:21, Alexander wrote:
> It seems that I have solved the issue by using nf_conntrack_ftp and
> redirecting "NEW,RELATED" traffic to squid:
Excellent news.
> ftp_port 2121 intercept
>
> modprobe nf_conntrack_ftp ports=2121
>
> iptables -t nat -A PREROUTING -p
It seems that I have solved the issue by using nf_conntrack_ftp and
redirecting "NEW,RELATED" traffic to squid:
ftp_port 2121 intercept
modprobe nf_conntrack_ftp ports=2121
iptables -t nat -A PREROUTING -p tcp --dport 21 -j REDIRECT --to-port 2121
iptables -t nat -A PREROUTING -p tcp -m state --
- Original Message -
From: Alex Rousskov
> If my reconstruction of the events was correct, then OpenSSL supplied as
> much information as it could -- the "unsupported TLS/SSL versions" is
> _your_ conclusion based on the information that neither Squid nor
> OpenSSL had access to.
>
>
>>
18 matches
Mail list logo
