On 2015-09-09 08:29 PM, Alex Rousskov wrote:
On 09/09/2015 07:06 PM, Dan Charlesworth wrote:
if I change ssl_bump peek step1 to ssl_bump peek all, I get this
assertion failure:
PeerConnector.cc:747: "!callback"
Please see http://bugs.squid-cache.org/show_bug.cgi?id=4303
Alex.
On 9/09/2015 7:39 p.m., Jason Haar wrote:
> On 08/09/15 20:32, Amos Jeffries wrote:
>> The second one is a fake CONNECT generated internally by Squid using
> Is it too late to propose that intercepted SSL transactions be logged as
> something besides "CONNECT"? I know I find it confusing - and so
On 08/09/15 20:32, Amos Jeffries wrote:
> The second one is a fake CONNECT generated internally by Squid using
Is it too late to propose that intercepted SSL transactions be logged as
something besides "CONNECT"? I know I find it confusing - and so do
others. I appreciate the logic behind it - but
Thanks for all the info here, people.
This is probably because of some other dumb thing I’m doing in my ssl_bump
config, but if I change ssl_bump peek step1 to ssl_bump peek all, I get this
assertion failure:
PeerConnector.cc:747: "!callback"
> On 9 Sep 2015, at 6:59 pm, Amos Jeffries
On 09/09/2015 07:06 PM, Dan Charlesworth wrote:
> if I change ssl_bump peek step1 to ssl_bump peek all, I get this assertion
> failure:
>
> PeerConnector.cc:747: "!callback"
Please see http://bugs.squid-cache.org/show_bug.cgi?id=4303
Alex.
>> On 9 Sep 2015, at 6:59 pm, Amos Jeffries
On 8/09/2015 5:36 p.m., Dan Charlesworth wrote:
> Hello all
>
> I’ve been testing out an SSL bumping config using 3.5.8 for the last week or
> so and am scratching my head over a couple of things.
>
> First, here’s my config (shout out to James Lay):
>
> acl tcp_level at_step SslBump1
> acl
This:
08/Sep/2015-17:41:38 11049 10.0.1.7 TCP_TUNNEL 200 12871 CONNECT
api.github.com:443 api.github.com - peek
Mozilla/5.0%20(Macintosh;%20Intel%20Mac%20OS%20X%2010.10;%20rv:40.0)%20Gecko/20100101%20Firefox/40.0
HIER_DIRECT/192.30.252.127 -
Compared to this:
08/Sep/2015-17:04:17 13359
Thanks Amos.
To clarify about the user agents: I’m talking about anything with a (logged)
SSL bump mode of “splice” — I’m not expecting to see one for the synthetic
(“peek") connections. In this case it’s actually intercepted spliced
connections.
Wondering why a spliced connection doesn't log
On 8/09/2015 7:45 p.m., Dan Charlesworth wrote:
> This:
> 08/Sep/2015-17:41:38 11049 10.0.1.7 TCP_TUNNEL 200 12871 CONNECT
> api.github.com:443 api.github.com - peek
> Mozilla/5.0%20(Macintosh;%20Intel%20Mac%20OS%20X%2010.10;%20rv:40.0)%20Gecko/20100101%20Firefox/40.0
>
On 09/07/2015 11:36 PM, Dan Charlesworth wrote:
> First, here’s my config (shout out to James Lay):
> acl client_hello_peeked at_step SslBump2
> ssl_bump splice client_hello_peeked bump_bypass_domains
> ssl_bump bump client_hello_peeked
Just in case somebody tries to copy this:
AFAICT, in Squid
On 2015-09-08 01:54 PM, Alex Rousskov wrote:
On 09/07/2015 11:36 PM, Dan Charlesworth wrote:
First, here’s my config (shout out to James Lay):
acl client_hello_peeked at_step SslBump2
ssl_bump splice client_hello_peeked bump_bypass_domains
ssl_bump bump client_hello_peeked
Just in case
On 09/08/2015 02:18 PM, James Lay wrote:
> I'm currently having great success with 3.5.8 and this
> peek/splice only method using transparent intercept:
>
> ###
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
>
> ssl_bump peek
On 2015-09-08 02:32 PM, Alex Rousskov wrote:
On 09/08/2015 02:18 PM, James Lay wrote:
I'm currently having great success with 3.5.8 and this
peek/splice only method using transparent intercept:
###
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3
On 9/09/2015 8:42 a.m., James Lay wrote:
> On 2015-09-08 02:32 PM, Alex Rousskov wrote:
>> On 09/08/2015 02:18 PM, James Lay wrote:
>>
>>> I'm currently having great success with 3.5.8 and this
>>> peek/splice only method using transparent intercept:
>>>
>>> ###
>>> acl
14 matches
Mail list logo
