On 4/08/2016 2:32 a.m., Heiler Bemerguy wrote:
>
> I think it doesn't really matter how much squid sets its default buffer.
> The linux kernel will upscale to the maximum set by the third option.
> (and the TCP Window Size will follow that)
>
> net.ipv4.tcp_wmem = 1024 32768 8388608
> net.ipv4.tc
First run the command I mentioned to ensure openssl can verify the full
chain for Yahoo.
$ openssl s_client -connect www.yahoo.com:443
../../ca-certificates/extracted/cadir/Verisign_Class_3_Public_Primary_Certification_Authority.pem
If you don't have a symlink that matches the subject hash then
On Wed, Aug 3, 2016 at 9:14 AM Alex Rousskov <
rouss...@measurement-factory.com> wrote:
> On 08/02/2016 09:53 PM, Amos Jeffries wrote:
>
> > To do bumping with server certificate mimic you need the 'bump' action
> > to occur at #3.
>
Thanks for the clarification. I probably read that 100 times in
That would explain the error if the Verisign Class 3 public root CA were
missing. However, our Smoothwall Express OS has all the standard root CAs
package found in /usr/ssl/certs. Do I need to tell squid where to find
those certs? If so, what config directive would I use for that?
Thanks!
On Wed,
It looks like you are missing the Verisign Class 3 Public Primary Root cert.
Notice the certificate chain list below.
Yahoo correctly send back all intermediate certificates in the TLS
handshake so the only certificate you need to make sure squid trusts (via
openssl) is the Verisign root.
You shou
Okay, it's not a name of the cert problem.
I turned on extra debug info to see what I get when I remove the
DONT_VERIFY_PEER flag and tried accessing https://www.yahoo.com. This is
what I got in the cache.log. I only see a couple of lines about a
certificate error. Sorry this is long but I didn't
Thanks for the info, Alex. That's very helpful about cleaning up my ACLs.
Those ACLs are a collection of ACLs that others have suggested I use, but
it would be nice to make them less confusing for me.
With my limited understanding of how sslbump works, the idea for squid to
play MITM is that a sel
On 08/03/2016 08:45 AM, Stanford Prescott wrote:
> ssl_bump none localhostgreen
> ssl_bump peek tls_s1_connect all
> ssl_bump splice tls_s2_client_hello tls_to_splice
> ssl_bump stare tls_s2_client_hello all
> ssl_bump bump tls_s3_server_hello all
AFAICT, the above is too complex. You can simplif
On 08/03/2016 10:27 AM, Amos Jeffries wrote:
On 3/08/2016 9:45 p.m., Marcus Kool wrote:
On 08/03/2016 12:30 AM, Amos Jeffries wrote:
If thats not fast enough, you may also wish to patch in a larger value
for HTTP_REQBUF_SZ in src/defines.h to 64KB with a matching incease to
read_ahead_gap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
You haven't permissive rule for localnet.
03.08.2016 22:53, Harsha S Aryan пишет:
>
> -- Forwarded message --
> From: *Harsha S Aryan* mailto:harsha.s.ar...@gmail.com>>
> Date: Wed, Aug 3, 2016 at 10:22 PM
> Subject: All website g
-- Forwarded message --
From: Harsha S Aryan
Date: Wed, Aug 3, 2016 at 10:22 PM
Subject: All website getting Blocked
To: squid-users@lists.squid-cache.org
Hi,
All website getting Blocked
using squid3
ubuntu 14.04
Squid Cache: Version 3.3.8
conf file
auth_param basic children
I have had my squid implementation for sslbump set up and working for some
time now. I have had several people point out that my use of "sslproxyflags
DONT_VERIFY_PEER" is dangerous from a security standpoint. When I was first
trying to get sslbump working it would not work until I saw a suggestion
I'm trying to do some summary statistics based on log files from our
2.6.STABLE18 setup.
A range of issues with interpreting 0 and negative values have arisen:
1) Roughly 6 in every 1000 log lines show an HTTP status code of 000,
about 90% with TCP_MISS, the rest mostly TCP_HIT, e.g.
14
I think it doesn't really matter how much squid sets its default buffer.
The linux kernel will upscale to the maximum set by the third option.
(and the TCP Window Size will follow that)
net.ipv4.tcp_wmem = 1024 32768 8388608
net.ipv4.tcp_rmem = 1024 32768 8388608
--
Best Regards,
Heiler Be
On 08/02/2016 09:53 PM, Amos Jeffries wrote:
> To do bumping with server certificate mimic you need the 'bump' action
> to occur at #3.
>
> Like:
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> ssl_bump peek step1
> ssl_bump stare step2
> ssl_bump bump all
>
> (or maybe stare an
tks amos yes its just to have some gain of caching
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Spdy-header-and-related-tp4678728p4678731.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
On 4/08/2016 12:34 a.m., joe wrote:
> is it ok to drop X-Firefox-Spdy
> reply_header_access X-Firefox-Spdy deny all
> just alow http/1
"just allow http/1" is not what the above does. It simply denies the
client being informed about that header existing.
> and if yes how chrome use Spdy in header
On 3/08/2016 9:45 p.m., Marcus Kool wrote:
>
>
> On 08/03/2016 12:30 AM, Amos Jeffries wrote:
>
>
>> If thats not fast enough, you may also wish to patch in a larger value
>> for HTTP_REQBUF_SZ in src/defines.h to 64KB with a matching incease to
>> read_ahead_gap in squid.conf. That has had som
is it ok to drop X-Firefox-Spdy
reply_header_access X-Firefox-Spdy deny all
just alow http/1
and if yes how chrome use Spdy in header to drop it
dose it heart the clients app or browsig ??
im droping those as well so fare so good no complain
reply_header_access Strict-Transport-Security deny all
On 08/03/2016 12:30 AM, Amos Jeffries wrote:
If thats not fast enough, you may also wish to patch in a larger value
for HTTP_REQBUF_SZ in src/defines.h to 64KB with a matching incease to
read_ahead_gap in squid.conf. That has had some mixed results though,
faster traffic, but also some assert
20 matches
Mail list logo
