I answer interline.
> El 9/01/2018, a las 4:27 p.m., Antony Stone
> escribió:
>
> On Tuesday 09 January 2018 at 21:28:37, Yoinier Hernandez Nieves wrote:
>
>> I try configure squid 3.5 on CentOS 7 with sslBump.
>>
>> But I have some problems, the first:
>>
>> Some HTTPs sites can access, bec
On Tuesday 09 January 2018 at 21:28:37, Yoinier Hernandez Nieves wrote:
> I try configure squid 3.5 on CentOS 7 with sslBump.
>
> But I have some problems, the first:
>
> Some HTTPs sites can access, because squid say what I am are not
> authenticated. And other sites, yes I can access.
Please
I try configure squid 3.5 on CentOS 7 with sslBump.
But I have some problems, the first:
Some HTTPs sites can access, because squid say what I am are not authenticated.
And other sites, yes I can access.
I am authenticated.
Thanks.
Yoinier.
Fragment of my squid.conf.
http_port 3128 ssl-bump
Thanks for the input. Peeking less and splicing sooner appears to resolve
the issue I was having. Since SNI is available at step 2 after peeking at
step 1, I there was no lose in functionality. So my ssl_bump config ends
up looking like below:
ssl_bump peek step1
ssl_bump splice step2 allowed_h
On 09/01/18 22:40, Vieri wrote:
From: Amos Jeffries
I have only taken a brief look, but so far it looks like the problematic
sockets are not participating in any ICAP activity.
Do you see that from the cache.log, or from ":filedescriptors"?
I went throu
On 09.01.18 17:15, Sekar Duraisamy wrote:
"To cache encryption protected content you must first remove the
encryption. That destroys the "anonymous" part completely."
Could you please provide little more details about affecting anonymous
service. Do you meant it will affect customers anonymous o
Hi Amos,
Thanks for your information
"To cache encryption protected content you must first remove the
encryption. That destroys the "anonymous" part completely."
Could you please provide little more details about affecting anonymous
service. Do you meant it will affect customers anonymous or fro
From: Amos Jeffries
>
> I have only taken a brief look, but so far it looks like the problematic
> sockets are not participating in any ICAP activity.
Do you see that from the cache.log, or from ":filedescriptors"?
If I list my current filedescriptors right now
On 01/08/17 11:32, Lei Wen wrote:
Hi Amos,
I tried your suggestion tried to tuned with some other options, no
matter what I've done, seems HTTPS traffic will not look at sibling
cache? it only look into it's own cache if there are only siblings in
the group?
For http:// URLs the peer secu
