How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

Lei Wen

Hi,

 

I am setting up a transparent proxy that is doing whitelist work, and at the same time, doing the cache work.


The whitelist works fine, HTTP cache verifed work cause I see TCP_MEM_HIT using this squid.conf, but don't see any HTTPS MEM HIT related log, every time seems a new connection.


For HTTPS traffic, I am getting TCP_TUNNEL/200 all the time, the question is, how can I tell that a HTTPS traffic is actually using cache, or in this case, it's not using cache at all for HTTPS. I am using forward-proxy port in cache_peer.


I understand that there is logformat to make access.log show hostname instead of ip, but this should not effect the MEM HIT log, right?

 

Meanwhile, I am also trying to setup the sibling cache cluster, not sure if this related to HTTPS cache, I am also getting TCP_DENIED/403 for squid-internal-dynamic/netdb - HIER_NONE/- text/html. I do see sibling hit for HTTP site.




Here is my squid version:

Squid Cache: Version 3.5.25

Service Name: squid

configure options:  '--prefix=/usr' '--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/lib/squid3' '--srcdir=.' '--without-libcap' '--sysconfdir=/etc/squid3' '--mandir=/usr/share/man' '--enable-inline' '--enable-async-io' '--enable-icmp' '--enable-useragent-log' '--enable-snmp' '--enable-cache-digests' '--enable-follow-x-forwarded-for' '--enable-storeio=aufs' '--enable-removal-policies=heap,lru' '--with-maxfd=16384' '--enable-poll' '--disable-ident-lookups' '--with-openssl' '--enable-ssl-crtd' '--with-default-user=proxy' '--with-swapdir=/var/spool/squid3' '--with-logdir=/var/log/squid3' '--with-pidfile=/var/run/squid3.pid' '--enable-linux-netfilter'

 

And my squid.conf

# Squid normally listens to port 3128

http_port 3130


http_port 3128 intercept

acl allowed_http_sites dstdomain "/etc/squid3/whitelist.txt"

http_access allow allowed_http_sites


https_port 3129 cert=/etc/squid3/squid.crt key=/etc/squid3/squid.key ssl-bump intercept generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

acl SSL_port port 443

http_access allow SSL_port

acl allowed_https_sites ssl::server_name "/etc/squid3/ssl_sites.txt"

 

#sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB

sslcrtd_program /lib/squid3/ssl_crtd -s /var/lib/ssl_db -M 4MB



acl step1 at_step SslBump1

acl step2 at_step SslBump2

acl step3 at_step SslBump3

ssl_bump peek step1 all

ssl_bump peek step2 allowed_https_sites

ssl_bump splice step3 allowed_https_sites

ssl_bump terminate step2 all


acl container_net src 172.18.0.0/24

tcp_outgoing_address 10.0.8.41 container_net

udp_outgoing_address 10.0.8.41 container_net

http_access allow container_net


icp_port 3131

icp_access allow all

#never_direct allow all

cache_peer 10.0.8.48 sibling 3128 3131 proxy-only

#cache_peer_access 10.0.8.48 allow all



# Uncomment and adjust the following to add a disk cache directory.

hosts_file /etc/hosts

cache_replacement_policy heap LFUDA


cache_dir aufs /var/spool/squid3 4000 16 256

log_icp_queries off


# Leave coredumps in the first cache dir

coredump_dir /var/spool/squid3


#refresh_pattern ^https://.*\.raw.githubusercontent\.com/ 120000 100% 43200

refresh_pattern .               12000       90%     43200


http_access deny all




Thanks,

Lei


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

Amos Jeffries
Administrator
On 26/07/17 10:56, Lei Wen wrote:
> Hi,
>
> I am setting up a transparent proxy that is doing whitelist work, and at
> the same time, doing the cache work.
>
>
> The whitelist works fine, HTTP cache verifed work cause I see
> TCP_MEM_HIT using this squid.conf, but don't see any HTTPS MEM HIT
> related log, every time seems a new connection.


Nod. HIT and REFRESH log entries show cache usage. Squid versions with
SSL-Bump support are more likely to show REFRESH.


>
> For HTTPS traffic, I am getting TCP_TUNNEL/200 all the time, the
> question is, how can I tell that a HTTPS traffic is actually using
> cache, or in this case, it's not using cache at all for HTTPS. I am
> using forward-proxy port in cache_peer.

That TUNNEL shows SSL-Bump splice action happening, or SSL-Bump not even
being considered (ie traffic received in your Squids' port 3130 and 3128).


>
> I understand that there is logformat to make access.log show hostname
> instead of ip, but this should not effect the MEM HIT log, right?
>
> Meanwhile, I am also trying to setup the sibling cache cluster, not sure
> if this related to HTTPS cache, I am also getting TCP_DENIED/403
> for squid-internal-dynamic/netdb - HIER_NONE/- text/html. I do see
> sibling hit for HTTP site.
>

You have configured splice or terminate. No bumping / decryption will
ever happen, so the cache is never even considered for use.


> And my squid.conf
>
> # Squid normally listens to port 3128
>
> http_port 3130
>
>
> http_port 3128 intercept
>
> acl allowed_http_sites dstdomain "/etc/squid3/whitelist.txt"
>
> http_access allow allowed_http_sites
>
>
> https_port 3129 cert=/etc/squid3/squid.crt key=/etc/squid3/squid.key
> ssl-bump intercept generate-host-certificates=on
> dynamic_cert_mem_cache_size=4MB
>
> acl SSL_port port 443
>
> http_access allow SSL_port
>

There are now almost no restrictions on port 443. Anyone can get through
it so long as they claim to be contacting one of the allowed_https_sites
(a the HTTP CONNECT level, not the TLS is unrestricted).
That includes traffic in the ports 3130 and 3128 which are not
considered for ssl_bump processing.



> acl allowed_https_sites ssl::server_name "/etc/squid3/ssl_sites.txt"
>
> #sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB
>
> sslcrtd_program /lib/squid3/ssl_crtd -s /var/lib/ssl_db -M 4MB
>
>
>
> acl step1 at_step SslBump1
>
> acl step2 at_step SslBump2
>
> acl step3 at_step SslBump3
>
> ssl_bump peek step1 all
>
> ssl_bump peek step2 allowed_https_sites

dstdomain ACL is not reliable in ssl_bump. It uses the HTTP URI domain
from the previous CONNECT instead of the actual TLS details.
Use ssl::server_name ACL type instead.

>
> ssl_bump splice step3 allowed_https_sites
>
> ssl_bump terminate step2 all

So what happens when the server TLS cert reveals it is not actually
serving up one of the allowed_https_sites? nothing, the traffic is
allowed through.


Note the terminate line only gets used at step2 (ie. based on client SNI
claims alone). The peek at step2 has precluded / prohibited bump from
happening at step3, which only leaves splice as being possible.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

Lei Wen
Hi Amos,

Thanks a lot.
It is my splice thing is blocking proxy in the middle, after using stare instead of peek, seems work though, terminal in this case is not blocking proxy in the middle?

I made some change on my squid.conf, it work for http/https caching and http/https whitelist.
It is working for http sibling cache as well, but has some issue with https/ssl sibling cache.
in cache_peer, which port number should I use as forward-proxy port? 3130/3128/3129?

I am trying to set up a sibling cache pool, there is no parent or gateway sort of thing in this hierarchy.
Each instance can have their own whitelist, but they share the same cache pool.
On each instance host, squid is actually doing it's whitelist and caching job for a container group on the same host.


http_port 3130

http_port 3128 intercept
acl allowed_http_sites dstdomain "/etc/squid3/whitelist.txt"
http_access allow allowed_http_sites

https_port 3129 cert=/etc/squid3/squid.crt key=/etc/squid3/squid.key ssl-bump intercept generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
acl SSL_port port 443
http_access allow SSL_port
acl allowed_https_sites ssl::server_name "/etc/squid3/ssl_sites.txt"

http_access deny all

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump stare step1 all
ssl_bump stare step2 allowed_https_sites
#ssl_bump bump step3
ssl_bump terminate step2 all

icp_port 3131
icp_access allow all
cache_peer 10.0.8.48 sibling 3130 3131 proxy-only



Thanks,
Lei

On Tue, Jul 25, 2017 at 9:42 PM, Amos Jeffries <[hidden email]> wrote:
On 26/07/17 10:56, Lei Wen wrote:
Hi,

I am setting up a transparent proxy that is doing whitelist work, and at the same time, doing the cache work.


The whitelist works fine, HTTP cache verifed work cause I see TCP_MEM_HIT using this squid.conf, but don't see any HTTPS MEM HIT related log, every time seems a new connection.


Nod. HIT and REFRESH log entries show cache usage. Squid versions with SSL-Bump support are more likely to show REFRESH.



For HTTPS traffic, I am getting TCP_TUNNEL/200 all the time, the question is, how can I tell that a HTTPS traffic is actually using cache, or in this case, it's not using cache at all for HTTPS. I am using forward-proxy port in cache_peer.

That TUNNEL shows SSL-Bump splice action happening, or SSL-Bump not even being considered (ie traffic received in your Squids' port 3130 and 3128).



I understand that there is logformat to make access.log show hostname instead of ip, but this should not effect the MEM HIT log, right?

Meanwhile, I am also trying to setup the sibling cache cluster, not sure if this related to HTTPS cache, I am also getting TCP_DENIED/403 for squid-internal-dynamic/netdb - HIER_NONE/- text/html. I do see sibling hit for HTTP site.


You have configured splice or terminate. No bumping / decryption will ever happen, so the cache is never even considered for use.


And my squid.conf

# Squid normally listens to port 3128

http_port 3130


http_port 3128 intercept

acl allowed_http_sites dstdomain "/etc/squid3/whitelist.txt"

http_access allow allowed_http_sites


https_port 3129 cert=/etc/squid3/squid.crt key=/etc/squid3/squid.key ssl-bump intercept generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

acl SSL_port port 443

http_access allow SSL_port


There are now almost no restrictions on port 443. Anyone can get through it so long as they claim to be contacting one of the allowed_https_sites (a the HTTP CONNECT level, not the TLS is unrestricted).
That includes traffic in the ports 3130 and 3128 which are not considered for ssl_bump processing.



acl allowed_https_sites ssl::server_name "/etc/squid3/ssl_sites.txt"

#sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB

sslcrtd_program /lib/squid3/ssl_crtd -s /var/lib/ssl_db -M 4MB



acl step1 at_step SslBump1

acl step2 at_step SslBump2

acl step3 at_step SslBump3

ssl_bump peek step1 all

ssl_bump peek step2 allowed_https_sites

dstdomain ACL is not reliable in ssl_bump. It uses the HTTP URI domain from the previous CONNECT instead of the actual TLS details.
Use ssl::server_name ACL type instead.


ssl_bump splice step3 allowed_https_sites

ssl_bump terminate step2 all

So what happens when the server TLS cert reveals it is not actually serving up one of the allowed_https_sites? nothing, the traffic is allowed through.


Note the terminate line only gets used at step2 (ie. based on client SNI claims alone). The peek at step2 has precluded / prohibited bump from happening at step3, which only leaves splice as being possible.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

Amos Jeffries
Administrator
On 27/07/17 09:54, Lei Wen wrote:
> Hi Amos,
>
> Thanks a lot.
> It is my splice thing is blocking proxy in the middle,

Sort of, yes.

> after using stare
> instead of peek, seems work though, terminal in this case is not
> blocking proxy in the middle?
>

Not sure what you are asking there. Squid *is* the proxy in the middle,
so terminate does a TCP close().


> I made some change on my squid.conf, it work for http/https caching and
> http/https whitelist.
> It is working for http sibling cache as well, but has some issue with
> https/ssl sibling cache.
> in cache_peer, which port number should I use as forward-proxy port?
> 3130/3128/3129?

Squid does not support relaying decrypted https:// requests over an
insecure connection. So HTTP cache_peer connections will be refused.

Also, when TLS cache_peer is used Squid is unable to tell the difference
between the peer TLS server details an origin. So any server-cert
forging uses the cache_peer's server cert instead of the origin.

In Squid-3.5 (and v4) explicit/forward proxy it is best not to use
cache_peer for decrypted content. The most working way for now is to let
it go 'DIRECT' and repeat the intercept at the peer.


>
> I am trying to set up a sibling cache pool, there is no parent or
> gateway sort of thing in this hierarchy.
> Each instance can have their own whitelist, but they share the same
> cache pool.
> On each instance host, squid is actually doing it's whitelist and
> caching job for a container group on the same host.
>

Are you trying to describe something like a CARP hierarchy?
<http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster>

They suffer from the above problem. There is no good solution for that
in current Squid versions which do SSL-Bump.


>
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump stare step1 all
> ssl_bump stare step2 allowed_https_sites
> #ssl_bump bump step3
> ssl_bump terminate step2 all
>


Up to you, but I would do this:

  ssl_bump peek step1

  ssl_bump stare step2 allowed_https_sites
  ssl_bump terminate step2

  # decrypt with server-cert forging
  ssl_bump bump step3


That peek at step1 allows Squid can splice if things to badly at the
step2 staring. A peek at step1 will not prevent a step3 bump.

And the explicit line with 'bump' ensures that Squid actually does a
bump, the default behaviour is a little bit too variable depending on
what bugs are present in the SSL-Bump code.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

Lei Wen
Hi Amos,

Squid does not support relaying decrypted https:// requests over an insecure connection. So HTTP cache_peer connections will be refused.
Do you mean HTTPS cache_peer connections will be refused?
 

Also, when TLS cache_peer is used Squid is unable to tell the difference between the peer TLS server details an origin. So any server-cert forging uses the cache_peer's server cert instead of the origin.
I am using the same cert on every host, so it doesn't matter if it picks the peer's cert. Besides, I have all sibling relation in this pool, only parent will start the request for peer, right?

 
In Squid-3.5 (and v4) explicit/forward proxy it is best not to use cache_peer for decrypted content. The most working way for now is to let it go 'DIRECT' and repeat the intercept at the peer.
Which directive do you mean by 'DIRECT' as a replacement of cache_peer?


My setup doesn't have many layers like a CARP cluster, it's just a squid host pool, and they are all siblings with each other, no parent/frontend/backend concept, each squid host is also a container host, all containers on different host are doing similar job, so they can share cache between different hosts. This is our initial idea for this project if you know there are better hierarchy and can give me some suggest I am really appreciate.



Thanks,
Lei


On Wed, Jul 26, 2017 at 3:30 PM, Amos Jeffries <[hidden email]> wrote:
On 27/07/17 09:54, Lei Wen wrote:
Hi Amos,

Thanks a lot.
It is my splice thing is blocking proxy in the middle,

Sort of, yes.

after using stare instead of peek, seems work though, terminal in this case is not blocking proxy in the middle?


Not sure what you are asking there. Squid *is* the proxy in the middle, so terminate does a TCP close().


I made some change on my squid.conf, it work for http/https caching and http/https whitelist.
It is working for http sibling cache as well, but has some issue with https/ssl sibling cache.
in cache_peer, which port number should I use as forward-proxy port? 3130/3128/3129?

Squid does not support relaying decrypted https:// requests over an insecure connection. So HTTP cache_peer connections will be refused.

Also, when TLS cache_peer is used Squid is unable to tell the difference between the peer TLS server details an origin. So any server-cert forging uses the cache_peer's server cert instead of the origin.

In Squid-3.5 (and v4) explicit/forward proxy it is best not to use cache_peer for decrypted content. The most working way for now is to let it go 'DIRECT' and repeat the intercept at the peer.



I am trying to set up a sibling cache pool, there is no parent or gateway sort of thing in this hierarchy.
Each instance can have their own whitelist, but they share the same cache pool.
On each instance host, squid is actually doing it's whitelist and caching job for a container group on the same host.


Are you trying to describe something like a CARP hierarchy?
<http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster>

They suffer from the above problem. There is no good solution for that in current Squid versions which do SSL-Bump.



acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump stare step1 all
ssl_bump stare step2 allowed_https_sites
#ssl_bump bump step3
ssl_bump terminate step2 all



Up to you, but I would do this:

 ssl_bump peek step1

 ssl_bump stare step2 allowed_https_sites
 ssl_bump terminate step2

 # decrypt with server-cert forging
 ssl_bump bump step3


That peek at step1 allows Squid can splice if things to badly at the step2 staring. A peek at step1 will not prevent a step3 bump.

And the explicit line with 'bump' ensures that Squid actually does a bump, the default behaviour is a little bit too variable depending on what bugs are present in the SSL-Bump code.


Amos


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

Amos Jeffries
Administrator
On 28/07/17 10:32, Lei Wen wrote:
> Hi Amos,
>
>     /Squid does not support relaying decrypted https:// requests over an
>     insecure connection. So HTTP cache_peer connections will be refused./
>
> Do you mean HTTPS cache_peer connections will be refused?

No, I mean un-encrypted cache_peer connections will be refused.

Encrypted peers might be used, BUT the peer cert is used for the
fake-cert generation. Usually the end user then encounters 'invalid
cert' problems. One also has to be very careful not to introduce other
MITM or downgrade vulnerabilities on the connections to those peers.


>
>     /Also, when TLS cache_peer is used Squid is unable to tell the
>     difference between the peer TLS server details an origin. So any
>     server-cert forging uses the cache_peer's server cert instead of the
>     origin./
>
> I am using the same cert on every host, so it doesn't matter if it picks
> the peer's cert. Besides, I have all sibling relation in this pool, only
> parent will start the request for peer, right?

No, any sibling may pass the request on to any other. If the first proxy
to handle a request thinks that a peer has the response and that peer in
fact does not, it may be passed on to a third sibling, etc.


It does not matter if the certs on the proxies are identical or not. The
SSL-Bump is ideally not sending that particular cert to the clients. It
is generating a fake cert specific for each HTTPS domain being visited -
based on that domains real official cert.
To do that Squid expected to receive that origin servers cert on its
next-hop connection.


>
>     /In Squid-3.5 (and v4) explicit/forward proxy it is best not to use
>     cache_peer for decrypted content. The most working way for now is to
>     let it go 'DIRECT' and repeat the intercept at the peer./
>
> Which directive do you mean by 'DIRECT' as a replacement of cache_peer?
>

"DIRECT" in caching hierarchy, means the proxy handling the request uses
DNS records to identify the origin server and goes directly to that (not
through a cache_peer).


>
> My setup doesn't have many layers like a CARP cluster, it's just a squid
> host pool, and they are all siblings with each other, no
> parent/frontend/backend concept, each squid host is also a container
> host, all containers on different host are doing similar job, so they
> can share cache between different hosts. This is our initial idea for
> this project if you know there are better hierarchy and can give me some
> suggest I am really appreciate.

Okay, understood.

You might be able to get a sort-of workable situation with the following
parameters. I'd still expect a lot of annoying problems though.


  cache_peer sibling.example.com sibling 3128 3130 \
    ssl sslcafile=/path/to/ca.pem \
    sslflags=NO_DEFAULT_CA ssloptions=NO_SSLv3


The /path/to/ca.pem should contain the public cert of the CA used to
sign the peers cert. Do this whether it is a self-signed CA or a public
Trusted CA.

[avoid the DONT_VERIFY_* settings, they are deadly].


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

Lei Wen
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?


Thanks,
Lei

On Thu, Jul 27, 2017 at 8:36 PM, Amos Jeffries <[hidden email]> wrote:
On 28/07/17 10:32, Lei Wen wrote:
Hi Amos,

    /Squid does not support relaying decrypted https:// requests over an
    insecure connection. So HTTP cache_peer connections will be refused./

Do you mean HTTPS cache_peer connections will be refused?

No, I mean un-encrypted cache_peer connections will be refused.

Encrypted peers might be used, BUT the peer cert is used for the fake-cert generation. Usually the end user then encounters 'invalid cert' problems. One also has to be very careful not to introduce other MITM or downgrade vulnerabilities on the connections to those peers.



    /Also, when TLS cache_peer is used Squid is unable to tell the
    difference between the peer TLS server details an origin. So any
    server-cert forging uses the cache_peer's server cert instead of the
    origin./

I am using the same cert on every host, so it doesn't matter if it picks the peer's cert. Besides, I have all sibling relation in this pool, only parent will start the request for peer, right?

No, any sibling may pass the request on to any other. If the first proxy to handle a request thinks that a peer has the response and that peer in fact does not, it may be passed on to a third sibling, etc.


It does not matter if the certs on the proxies are identical or not. The SSL-Bump is ideally not sending that particular cert to the clients. It is generating a fake cert specific for each HTTPS domain being visited - based on that domains real official cert.
To do that Squid expected to receive that origin servers cert on its next-hop connection.



    /In Squid-3.5 (and v4) explicit/forward proxy it is best not to use
    cache_peer for decrypted content. The most working way for now is to
    let it go 'DIRECT' and repeat the intercept at the peer./

Which directive do you mean by 'DIRECT' as a replacement of cache_peer?


"DIRECT" in caching hierarchy, means the proxy handling the request uses DNS records to identify the origin server and goes directly to that (not through a cache_peer).



My setup doesn't have many layers like a CARP cluster, it's just a squid host pool, and they are all siblings with each other, no parent/frontend/backend concept, each squid host is also a container host, all containers on different host are doing similar job, so they can share cache between different hosts. This is our initial idea for this project if you know there are better hierarchy and can give me some suggest I am really appreciate.

Okay, understood.

You might be able to get a sort-of workable situation with the following parameters. I'd still expect a lot of annoying problems though.


 cache_peer sibling.example.com sibling 3128 3130 \
   ssl sslcafile=/path/to/ca.pem \
   sslflags=NO_DEFAULT_CA ssloptions=NO_SSLv3


The /path/to/ca.pem should contain the public cert of the CA used to sign the peers cert. Do this whether it is a self-signed CA or a public Trusted CA.

[avoid the DONT_VERIFY_* settings, they are deadly].


Amos


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users