Re: [squid-users] Squid and SSL Bump

[Yoinier Hernandez Nieves]

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, because squid say what I am are not
>> authenticated. And other sites, yes I can access.
> 
> Please give us information:
> 
> 1. An example of sites can you access.
not https

> 2. An example of sites can you not access.
https://www.ssllabs.com/ssltest/viewMyClient.html 

https://outlook.co.il/ 
https://www.facebook.com 

> 3. For problems, show us error messages - quote us what the remote sites tell 
> you.
Se encontró el siguiente error al intentar recuperar la dirección URL: 
https://outlook.co.il/ 
Acceso Denegado a la Caché

Lo lamento, tu no estás autorizado a solicitar https://outlook.co.il/ de este 
caché hasta que te hayas autenticado.

Please contact the cache administrator 

 if you have difficulties authenticating yourself.

> 
> 4. Please rephrase "squid say what I am are not authenticated" - this is not 
> clear - what do you mean?
> 
>> I am authenticated.
> 
> To what?  Squid, or the remote site?
Squid, see message in Spanish for point 3.

Other error is that
https://www.kiosco.bandec.cu/kiosco 
Error negotiating SSL on FD 16: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)
The following error was encountered while trying to retrieve the URL: 
https://www.kiosco.bandec.cu/* 
Failed to establish a secure connection to 190.6.64.132

The system returned:

(71) Protocol error (TLS code: X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY)
SSL Certficate error: certificate issuer (CA) not known: /CN=CX6.bandec.cu

This proxy and the remote host failed to negotiate a mutually acceptable 
security settings for handling your request. It is possible that the remote 
host does not support secure connections, or the proxy is not satisfied with 
the host security credentials.

> 
> How do you know you are authenticated - what confirmation do you have?
> 
>> Fragment of my squid.conf.
>> 
>> http_port 3128 ssl-bump cert=/etc/squid/ssl_cert/ConAlza.pem
>> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB#
>> options=NO_SSLv3 dhparams=/etc/squid/ssl_cert/dhparam.pem sslcrtd_program
>> /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslproxy_options
>> NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
>> acl step1 at_step SslBump1
>> acl step2 at_step SslBump2
>> acl step3 at_step SslBump3
>> ssl_bump peek step1
>> ssl_bump bump all
>> authenticate_ip_ttl 60 seconds
> 
> That looks a bit strange (and a bit incomplete) to me, but since I'm no 
> expert 
> on SSL interception, I'll let someone else step in here.
> 
> If you can provide more information in the meantime (eg: enough to help 
> someone else replicate your problem) that would be good.
> 
I use too dansguardians before the squid proxy.

See the logs for one petition

1515534858.355   3720 aaa.aaa.aaa.aaa TAG_NONE/200 0 CONNECT 
www.ssllabs.com:443 ynieves HIER_DIRECT/64.41.200.100 -
1515534858.375  0 bbb.bbb.bbb.bbb TCP_DENIED/403 4457 GET 
https://www.ssllabs.com/ssltest/viewMyClient.html ynieves HIER_NONE/- text/html
1515534858.407  0 bbb.bbb.bbb.bbb TAG_NONE/503 4952 GET 
http://artemisa.conalza.co.cu:3128/squid-internal-static/icons/SN.png ynieves 
HIER_DIRECT/64.41.200.100 text/html

aaa.aaa.aaa.aaa is my pc.
bbb.bbb.bbb.bbb is the dansguardians

> 
> Antony.
> 
> -- 
> Wanted: telepath.   You know where to apply.
> 
>   Please reply to the list;
> please *don't* CC me.
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

___
squid-users mailing 

Re: [squid-users] Squid and SSL Bump

[Antony Stone]

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 give us information:

1. An example of sites can you access.

2. An example of sites can you not access.

3. For problems, show us error messages - quote us what the remote sites tell 
you.

4. Please rephrase "squid say what I am are not authenticated" - this is not 
clear - what do you mean?

> I am authenticated.

To what?  Squid, or the remote site?

How do you know you are authenticated - what confirmation do you have?

> Fragment of my squid.conf.
> 
> http_port 3128 ssl-bump cert=/etc/squid/ssl_cert/ConAlza.pem
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB#
> options=NO_SSLv3 dhparams=/etc/squid/ssl_cert/dhparam.pem sslcrtd_program
> /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB sslproxy_options
> NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump peek step1
> ssl_bump bump all
> authenticate_ip_ttl 60 seconds

That looks a bit strange (and a bit incomplete) to me, but since I'm no expert 
on SSL interception, I'll let someone else step in here.

If you can provide more information in the meantime (eg: enough to help 
someone else replicate your problem) that would be good.


Antony.

-- 
Wanted: telepath.   You know where to apply.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Squid and SSL Bumb

[Yoinier Hernandez Nieves]

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 cert=/etc/squid/ssl_cert/ConAlza.pem 
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB# options=NO_SSLv3 
dhparams=/etc/squid/ssl_cert/dhparam.pem
sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1
ssl_bump bump all
authenticate_ip_ttl 60 seconds


___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ALPN, HTTP/2 and sslbump

[Brian Bergstrom]

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_https_sites
ssl_bump splice step2 allowed_https_ips
ssl_bump terminate step2 all


Thanks again!

On Wed, Jan 3, 2018 at 5:47 PM, Amos Jeffries  wrote:

> On 04/01/18 12:37, Alex Rousskov wrote:
>
>> On 01/03/2018 03:30 PM, brianbergstrom wrote:
>>
>> If I understand the docs and this thread correctly, Squid should be
>>> removing
>>> h2 from the ALPN in the Client Hello since Squid does not support it.
>>>
>>
>> Please note that Squid cannot remove something when using "peek" and
>> "splice" actions.
>>
>> I do not know whether Squid removes unsupported ALPN values when using
>> "stare" and "bump" actions, and I would not be surprised to learn that
>> Squid does not police those values at all (yet),
>>
>
> It does *unless* peeking at the server handshake: <
> https://github.com/squid-cache/squid/blob/v3.5/src/ssl/bio.cc#L1261>.
>
> Amos
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>



-- 
*Brian Bergstrom*
SOFTWARE ENGINEER

SportsEngine | 807 Broadway St NE | Suite 300 | Minneapolis, MN 55413
SportsEngine.com  | twitter.com/NBCSportsEngine |
facebook.com/NBCSportsEngine
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] How to enable caching for https websites on Squid

[Matus UHLAR - fantomas]

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 or from proxy
server?


I believe you have been answered already multiple times, but once more:

the customer will have no privacy against proxy server - the proxy server
will see everything they access, all the content etc.

This is impossible with SSL - SSL has been created just to provide privacy
to users, so nobody sees the content, only the final server.

With HTTPS decrypting the destination server will only see your proxy
accessing, no IP, browser info (if you decide to hide it) but the proxy will
see everything.  Proxy admins will be able to see their passwords, their
mail, banking account information, etc.
 
If your users are OK with that, fine.  The question is if they really want

this kind of anonymity.


When we use certificate in the Proxy server to decrypt the content of
HTTPS, multiple customers will hit to the same HTTPS website in a day
through our proxy, that website always see single certificate even
though multiple customers from multiple IPs. Is there a chance from
website can block
because of they will see more requests from more IP's but single
certificate for the all the requests to the same doamin ?


The end servers will not see your proxy certificate. 
The HTTP server certificate is used to authentize server, not the client.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The only substitute for good manners is fast reflexes. 
___

squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] How to enable caching for https websites on Squid

[Sekar Duraisamy]

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 from proxy
server?

We used to disable via and forwarded_for header to make squid proxy as
anonymous in HTTP.

When we use certificate in the Proxy server to decrypt the content of
HTTPS, multiple customers will hit to the same HTTPS website in a day
through our proxy, that website always see single certificate even
though multiple customers from multiple IPs. Is there a chance from
website can block
because of they will see more requests from more IP's but single
certificate for the all the requests to the same doamin ?

On Wed, Dec 20, 2017 at 8:42 PM, Amos Jeffries  wrote:
> On 21/12/17 02:41, Matus UHLAR - fantomas wrote:
>>>
>>> On 21/12/17 01:23, Matus UHLAR - fantomas wrote:

 and I think you should read the last paragraph as:

  "caching often will not happen, since most of web developers don't know
 hot
   so use and benefit of it thus they try to disable caching globally"
>>
>>
>> On 21.12.17 02:20, Amos Jeffries wrote:
>>>
>>> That is nothing special for HTTPS, it happens worse in regular HTTP.
>>
>>
>> do you want to say that breaking into https can cause http caching more
>> efficient?
>> do you have any evidence of that?
>>
>
> No, I am saying that the problem you pointed at is a _larger_ problem in
> http:// because those dev are having to actively prevent caching. Many are
> also under the false impression that https:// goes end-to-end and caching
> does not happen there other than Browser cache. So those who develop sites
> with HTTPS in mind do not go to quite such extremes to block proxies
> caching.
>
> HTTPS has _other_ problems that impact on caching efficiency.
>
> Amos
>
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TCP out of memory

[Vieri]

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, I get this:

# squidclient mgr:filedescriptors | grep "127.0.0.1:1344"
20 Socket  899  25*   10001  127.0.0.1:1344127.0.0.1
30 Socket0   7164872210  127.0.0.1:1344127.0.0.1
38 Socket  900   0*2564  127.0.0.1:1344127.0.0.1
102 Socket0   6722267689  127.0.0.1:1344127.0.0.1
107 Socket0  102679   203677  127.0.0.1:1344127.0.0.1
113 Socket0   6722267709  127.0.0.1:1344127.0.0.1
115 Socket  886   0*2588  127.0.0.1:1344127.0.0.1
116 Socket  873  25*   10395  127.0.0.1:1344127.0.0.1
129 Socket0  114892   144095  127.0.0.1:1344127.0.0.1
134 Socket  900  25*8863  127.0.0.1:1344127.0.0.1
160 Socket0   6722267687  127.0.0.1:1344127.0.0.1
165 Socket0   7783378401  127.0.0.1:1344127.0.0.1
166 Socket0   6722267702  127.0.0.1:1344127.0.0.1
175 Socket0   6722267698  127.0.0.1:1344127.0.0.1
176 Socket0   6722267698  127.0.0.1:1344127.0.0.1
212 Socket0   6722267742  127.0.0.1:1344127.0.0.1
213 Socket  878   0*2533  127.0.0.1:1344127.0.0.1
226 Socket  873   0*2531  127.0.0.1:1344127.0.0.1
236 Socket0   78332   180786  127.0.0.1:1344127.0.0.1
244 Socket0   6722267698  127.0.0.1:1344127.0.0.1
281 Socket0   6722267685  127.0.0.1:1344127.0.0.1
285 Socket0   78253   149568  127.0.0.1:1344127.0.0.1
298 Socket0   7783378451  127.0.0.1:1344127.0.0.1
305 Socket0   74366   168309  127.0.0.1:1344127.0.0.1
307 Socket0  114519   115068  127.0.0.1:1344127.0.0.1
326 Socket0   6722267698  127.0.0.1:1344127.0.0.1
327 Socket0   6722267687  127.0.0.1:1344127.0.0.1
365 Socket0   70248   114918  127.0.0.1:1344127.0.0.1
372 Socket0   6722267698  127.0.0.1:1344127.0.0.1
390 Socket0   7783378483  127.0.0.1:1344127.0.0.1
404 Socket0   9002290703  127.0.0.1:1344127.0.0.1
464 Socket0   78253   144095  127.0.0.1:1344127.0.0.1
472 Socket0   6722267698  127.0.0.1:1344127.0.0.1
480 Socket  891   0*2514  127.0.0.1:1344127.0.0.1
491 Socket0   6722267685  127.0.0.1:1344127.0.0.1
509 Socket0   6722267687  127.0.0.1:1344127.0.0.1
512 Socket0   6722267703  127.0.0.1:1344127.0.0.1
528 Socket0  131176   155548  127.0.0.1:1344127.0.0.1
536 Socket0   70111   134058  127.0.0.1:1344127.0.0.1
547 Socket0   6722267689  127.0.0.1:1344127.0.0.1
554 Socket0  131860   152673  127.0.0.1:1344127.0.0.1
570 Socket0   6722267707  127.0.0.1:1344127.0.0.1
572 Socket  893   0*2706  127.0.0.1:1344127.0.0.1
596 Socket0   78390   114864  127.0.0.1:1344127.0.0.1
602 Socket0   6722267691  127.0.0.1:1344127.0.0.1
624 Socket0   7267873442  127.0.0.1:1344127.0.0.1
631 Socket0   7164672250  127.0.0.1:1344127.0.0.1
635 Socket0  104333   104896  127.0.0.1:1344127.0.0.1
641 Socket0   6722267687  127.0.0.1:1344127.0.0.1
646 Socket0   6722267698  127.0.0.1:1344127.0.0.1
662 Socket0   6722267698  127.0.0.1:1344127.0.0.1
674 Socket0   6722267691  127.0.0.1:1344127.0.0.1
678 Socket0   6722267687  127.0.0.1:1344127.0.0.1
687 Socket0   6722267702  127.0.0.1:1344127.0.0.1
730 Socket0   6722267691  127.0.0.1:1344127.0.0.1
767 Socket0   74465   152811  127.0.0.1:1344127.0.0.1
772 Socket0   6721767747  127.0.0.1:1344127.0.0.1
815 Socket0   7786478246  127.0.0.1:1344127.0.0.1
848 Socket0   6722267743  127.0.0.1:1344127.0.0.1
865 Socket0   6722267747  127.0.0.1:1344127.0.0.1
890 Socket0   6722267699  127.0.0.1:1344127.0.0.1
943 Socket0   7783378501  127.0.0.1:1344127.0.0.1
1008 Socket0   7421278383  127.0.0.1:1344127.0.0.1
1018 Socket0   7446690630  127.0.0.1:1344127.0.0.1
1099 Socket0   6722267687  127.0.0.1:1344127.0.0.1
1124 Socket0   6722267683  127.0.0.1:1344127.0.0.1
1167 Socket0   6722267687  127.0.0.1:1344127.0.0.1
1273 Socket0   6725867879  127.0.0.1:1344127.0.0.1
1337 Socket0   7424378265  127.0.0.1:1344127.0.0.1


Both Nread and Nwrite seem to be well over 

Re: [squid-users] How to tell HTTPS traffic is using cache from access.log in 3.5.x when using ssl_bump

[Amos Jeffries]

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 security does not matter, for https:// the 
peer requires TLS connections to be used. Other than that limit they 
should behave the same.


That said there are some unresolved things related to 
 which can prevent 
HTTPS doing some things one would expect to be possible.



Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users