I am happy to release the new RPMs of Squid 3.5.13 for:
- CentOS 6 32bit [http://ngtech.co.il/repo/centos/6/i686/]
- CentOS 6 64bit [http://ngtech.co.il/repo/centos/6/x86_64/]
- CentOS 7 64bit [http://ngtech.co.il/repo/centos/7/x86_64/]
- OpenSUSE leap(42.1) 64bit [http://ngtech.co.il/repo/opensus
hello,
I am migrating a squid box from squid 2.7 to squid 3.4.8 (debian jessie).
I use squid for forwarding only.
My squid box is not on a firewall, but on a dedicated server in the DMZ,
between the internal and the external firewall.
So, I have two http_port directives :
http_port 8080
http_p
On Thursday 14 January 2016 at 13:21:57, jean-yves boisiaud wrote:
> My squid box is not on a firewall, but on a dedicated server in the DMZ,
> between the internal and the external firewall.
> On the internal firewall, port 80 is redirected to the squid box port 3128,
> for transparent proxying.
On 15/01/2016 1:27 a.m., Antony Stone wrote:
> On Thursday 14 January 2016 at 13:21:57, jean-yves boisiaud wrote:
>
>> My squid box is not on a firewall, but on a dedicated server in the DMZ,
>> between the internal and the external firewall.
>
>> On the internal firewall, port 80 is redirected t
On 12/01/2016 2:40 p.m., Jason Haar wrote:
> Hi there
>
> I am finding squid-3.5.13 is false positive-ing on ssl-bump way too
> often. I'm just using "peek-and-splice" on intercepted port 443 to
> create better squid logfiles (ie I'm not actually bump-ing) but that
> enables enough of the code to
Eliezer, Amos,
I wanted to follow-up on the below thread since I encountered an
additional, interesting issue.
Per my issue with shutterfly.com below, if I *do not* set an ECDH cipher in
the tls-dh parameter, then I have to remove NO_SSLv2 from sslproxy_options.
However, if I set an ECDH cipher
On 15/01/2016 3:47 a.m., David Marcos wrote:
> Eliezer, Amos,
>
> I wanted to follow-up on the below thread since I encountered an
> additional, interesting issue.
>
> Per my issue with shutterfly.com below, if I *do not* set an ECDH cipher in
> the tls-dh parameter, then I have to remove NO_SSLv
Hi,
I want to limit the users with the Maxconn parameters. But the users are NATed
behind a public IP address. Is squid just looking at the IP address or can it
also use the username to figure out if it should apply the maxconn?
Thanks
Murat
___
squid-
>
>
> You *must* perform the NAT on the machine Squid is running on for intercept
> mode to work.
>
> Doing it on any other router along the way will not work.
>
Unless I'm missing something, I'd phrase this differently: the NAT must not
be performed between the client and Squid. Squid is indiffer
On 15/01/2016 6:25 a.m., Robert Plamondon wrote:
>>
>>
>> You *must* perform the NAT on the machine Squid is running on for intercept
>> mode to work.
>>
>> Doing it on any other router along the way will not work.
>>
>
> Unless I'm missing something, I'd phrase this differently: the NAT must not
On Thursday 14 January 2016 at 18:25:16, Robert Plamondon wrote:
> > You *must* perform the NAT on the machine Squid is running on for
> > intercept mode to work.
> >
> > Doing it on any other router along the way will not work.
>
> Unless I'm missing something, I'd phrase this differently: the
In Squid http-redirector can get access to the full url, for https
sslbump only gives us the host(https://host), to get a full
url(https://host/path), are the only choices icap/ecap for content
filtering? in this case I really don't care about the https content
payload, just its http header tha
Hello,
thank you for your answer. I'm using the debian stable version(3.4.8) at
the moment. The squid server is working very well.
But I have a different question: How to secure/hardening my squid _https_
proxy?
I used the following page to configure my https proxy:
http://wiki.squid-cache.org/C
Hello
I'd like to suggest that the pre compiled squid packages (e.g *.deb) should
be build with the flags
--enable-ssl \
--with-openssl \
--enable-ssl-crtd"
by default
It would make things much easier for me then I can install a https ready
squid directly from the repository(apt-get)
___
On 15/01/2016 2:08 p.m., xxiao8 wrote:
> In Squid http-redirector can get access to the full url, for https
> sslbump only gives us the host(https://host), to get a full
> url(https://host/path), are the only choices icap/ecap for content
> filtering? in this case I really don't care about the http
On 15/01/2016 3:38 p.m., startrekfan wrote:
> Hello,
>
> thank you for your answer. I'm using the debian stable version(3.4.8) at
> the moment. The squid server is working very well.
>
> But I have a different question: How to secure/hardening my squid _https_
> proxy?
>
I'm a lot confused why
16 matches
Mail list logo