Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate
Thank you Alex for the reply. Alex: 1. Servers never send SNI. Clients usually send SNI. Squid should forward SNI it received from the client to the server, provided the client actually sent SNI. Did your client send SNI? Sid: I can see in Client Hello IP Address being sent by Client; so there is no SNI from client itself. Alex: 2. Bugs notwithstanding, the implied order of events is not what actually happens: Squid, as configured, does _not_ forward anything from the server certificate to the client. Squid, as configured, generates a certificate based on client-supplied information (not server-supplied information). After sending that generated certificate to the client, Squid establishes a TLS connection with the server. Sid: Thank you for explanation. Alex: For an accurate picture, in addition to Squid-server and server-Squid traffic, look at what Squid has received from the client and what Squid sent to the client, all in actual order. Sid: I took wireshark on Squid server (centOS 7); I took 2 wiresharks between Client & Squid and then between Squid & Server. I can see client being sent fake cert generated by Squid & client responds with "Client key Exchange", "Change cipher spec", "Encrypted Handshake Message". But I can't see actual client certificate sent to Squid. Is there a way to decypt in Wireshark. In Wireshark between Squid & Server I can see Squid responding with "61 Alert (Level: Fatal, Description: Internal Error)". Alex: Is your Squid configured to trust those internal CAs? If not, Squid would not be able to validate the server certificate. Sid: I have added those chained certificates as following in squid.conf tls_outgoing_options cafile=/usr/local/squid/etc/UCAppsCA.pem sslproxy_foreign_intermediate_certs /usr/local/squid/etc/UCAppsCA.pem -- Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Squid 3.5.25 does not recognise ICAP 408 status code
On 10/30/18 6:45 PM, Arunabha Saha wrote: > Squid 3.5.25 does not seem to recognise the 408 request timeout error > code from ICAP. Squid effectively recognizes ICAP 408 response as an ICAP transaction error response and blames the ICAP service for that error. That (minimal) support can be improved, of course. See options #1 and #3 below. As with any timeout, it is impossible to say in general which side of the connection is at fault. This case has at least three sides: It could be the HTTP agent, Squid, and/or the ICAP service. Did one of them stall the transaction? Or was the ICAP service just too impatient? See option #4 below. Needless to say, treating all ICAP service timeouts as if nothing bad happened would break some existing Squid deployments (while possibly fixing yours). A proper general solution (option #3 below) would most likely require making Squid behavior configurable. > The more troublesome issue for me is the exception it generates and then > declares ICAP down after a certain number of such exceptions. > > I don't want to disable the failure limit entirely given that we can > often have genuine failures that squid needs to detect. > > What i'd like to see is squid should not throw an exception in this > case. The "exception" is a minor low-level/technical detail. What you really want to see is Squid blaming itself (rather than the ICAP service) for the problem. Squid indeed lacks that kind of functionality, but it can be added if really needed. See options #1 and #3 below. > The timeout is somewhat aggressive but works with an earlier > version of ICAP (0.1.x). The one i'm testing is 0.5.3. Please note that ICAP is a protocol, not a product/software name. It probably does not matter what ICAP service you are using though. > Any suggestions? I can suggest a few options, in no particular order: 1. Modify your Squid to treat 408 differently. 2. Modify your ICAP service to stop sending ICAP 408 responses to Squid. 3. Add proper ICAP timeout support feature to Squid. 4. Investigate why your ICAP service times out. If you are lucky, you may be able to fix or work around the problem by adjusting Squid and/or your ICAP service configuration. For option #1, Adaptation::Icap::ModXact::parseIcapHead() may be a good starting point. For options #1 and #3, see also https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F In most cases, option #4 is the best first step but YMMV. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] redirect based on url (302)
On 31/10/18 12:49 AM, uppsalanet wrote:
> Thanks,
> Missed that I need to install squid-helpers "yum install squid-helpers" :-)
> Now it's there.
>
> Now I use it like this:
>
> external_acl_type whitelist ttl=60 children-max=1 %SRC %DST
> /usr/lib64/squid/ext_sql_session_acl --user root --password config --table
> sessions --cond "" --debug
>
> But receive this:
> /2018/10/30 12:38:37.279| 82,9| external_acl.cc(600) aclMatchExternal:
> acl="whitelist"
> 2018/10/30 12:38:37.280| 82,9| external_acl.cc(629) aclMatchExternal: No
> helper entry available
> 2018/10/30 12:38:37.280| 82,2| external_acl.cc(663) aclMatchExternal:
> whitelist("130.238.171.59 muse.jhu.edu -") = lookup needed
> 2018/10/30 12:38:37.280| 82,2| external_acl.cc(667) aclMatchExternal:
> "130.238.171.59 muse.jhu.edu -": queueing a call.
> 2018/10/30 12:38:37.280| 82,2| external_acl.cc(1031) Start: fg lookup in
> 'whitelist' for '130.238.171.59 muse.jhu.edu -'
Oh darn. Sorry, I forgot about the implicit %DATA parameters on external
ACL yet again. One of the things on my long todo list is to make that
optionally ignored.
For now the easiest fix/workaround is to have your custom helper append
that " -" string to the IDs in the database.
Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] ERROR The requested URL could not be retrieved
On 31/10/18 1:45 AM, Uchenna Nebedum wrote: > Thanks a lot it works now... I've added site bumping exceptions, and it > still throws invalid certificate exceptions even though it uses the > 'ssl_bump stare' configuration, is it possible to reduce the errors? > > Uchenna Nebedum > Maybe, the above is a bit vague on details. What exactly do you have configured now after those changes? And what exact error(s) are you seeing now? Amos PS. please reply to the list instead of me personally. PPS. If you want dedicated support I do provide it commercially, but you started this on-list so I assume you are not wanting to receive an invoice for responses. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Squid proxy not working when upgrade from 27 to 3.5
On 30/10/18 4:15 PM, Angus J. wrote: > Hi Amos > > Can I just copy the all squid configure file at /etc/squid/ from 2.7 to 3.5 > ? > Sometimes, but usually not *just* that. The problem is that Squid-2.7 very old and also 2.6 & 2.7 was a fork of the even older Squid-2.5 code. There have been quite a lot of changes to squid.conf in the 12 years between 2.5 and 3.5, and v2.7 does some things a bit differently to both. The squid -k parse mechanism was added to help reduce the problems encountered with upgrades. So you can have the squid-3 tell you what it understands about the older config files. As you should have noticed when I got you to run -k parse earlier there were things coming up as FATAL and ERROR in your particular config file. That means Squid will not even start until the config is changed to the Squid-3.x settings. FWIW: Marcus and I are trying to get you to the point where your Squid will run and do what you have told us it is supposed to be doing. The problems you are having in the latest few days are because you went and changed other things (the cache_peer lines) beside what we pointed out - which broken the proxy again in a different way. It's okay that you don't know what you are doing. This list is in part for helping people learn to operate Squid. Just try not to go too fast of more breakage will occur. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Squid 3.5.25 does not recognise ICAP 408 status code
Squid 3.5.25 does not seem to recognise the 408 request timeout error code from ICAP. The more troublesome issue for me is the exception it generates and then declares ICAP down after a certain number of such exceptions. I don't want to disable the failure limit entirely given that we can often have genuine failures that squid needs to detect. What i'd like to see is squid should not throw an exception in this case. The timeout is somewhat aggressive but works with an earlier version of ICAP (0.1.x). The one i'm testing is 0.5.3. Any suggestions? I tried looking at squid 3.5.26 through 3.5.28 but i don't see any support for 408 timeout there (maybe i missed it?). Debug Logs: 2018/10/29 20:20:25.656| 93,5| ModXact.cc(654) parseMore: ICAP/1.0 408 Request timeout^M Server: C-ICAP/0.5.3^M Connection: close^M ISTag: CI0001-X^M ^M 2018/10/29 20:20:25.656| 93,5| ModXact.cc(749) parseHeaders: parse ICAP headers 2018/10/29 20:20:25.656| 93,5| ModXact.cc(1079) parseHead: have 98 head bytes to parse; state: 0 2018/10/29 20:20:25.656| 93,5| ModXact.cc(1094) parseHead: parse success, consume 98 bytes, return true 2018/10/29 20:20:25.656| 93,5| ModXact.cc(785) parseIcapHead: found connection close 2018/10/29 20:20:25.656| 93,5| ModXact.cc(815) parseIcapHead: ICAP status 408 2018/10/29 20:20:25.656| 93,3| ../../../src/base/AsyncJobCalls.h(177) dial: Adaptation::Icap::Xaction::noteCommRead threw exception: Unsupported ICAP status code 2018/10/29 20:20:25.656| 11,5| HttpRequest.cc(472) detailError: current error details: 35/396407234 2018/10/29 20:20:25.656| 93,4| Xaction.cc(514) setOutcome: ICAP_ERR_OTHER 2018/10/29 20:20:25.656| 93,4| ServiceRep.cc(80) noteFailure: failure 4 out of 10 allowed in 0sec [up,fail4] ... 2018/10/29 20:21:06.981| 93,5| ModXact.cc(815) parseIcapHead: ICAP status 408 2018/10/29 20:21:06.981| 93,3| ../../../src/base/AsyncJobCalls.h(177) dial: Adaptation::Icap::Xaction::noteCommRead threw exception: Unsupported ICAP status code 2018/10/29 20:21:06.981| 11,5| HttpRequest.cc(472) detailError: current error details: 35/396407234 2018/10/29 20:21:06.981| 93,4| Xaction.cc(514) setOutcome: ICAP_ERR_OTHER 2018/10/29 20:21:06.981| 93,4| ServiceRep.cc(80) noteFailure: failure 11 out of 10 allowed in 0sec [up,fail11] 2018/10/29 20:21:06.981| suspending ICAP service for too many failures -- regards, Arun ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Squid 4.3: SSL Bump fails to send client certificate
On 10/30/18 2:36 AM, Sid wrote: > http_port 3128 ssl-bump \ > cert=/usr/local/squid/etc/ssl_cert/myCA.pem \ > generate-host-certificates=on dynamic_cert_mem_cache_size=4MB > ssl_bump peek step1 > ssl_bump bump all > Browser & HTTP UA Client connections are working with SSL bump properly; but > except for one connection. > Server sends certificate with SNI; but squid forwards it as IP Address to > client Two problems with that statement: 1. Servers never send SNI. Clients usually send SNI. Squid should forward SNI it received from the client to the server, provided the client actually sent SNI. Did your client send SNI? 2. Bugs notwithstanding, the implied order of events is not what actually happens: Squid, as configured, does _not_ forward anything from the server certificate to the client. Squid, as configured, generates a certificate based on client-supplied information (not server-supplied information). After sending that generated certificate to the client, Squid establishes a TLS connection with the server. > When I took wireshark on Squid; I can see Squid sends: For an accurate picture, in addition to Squid-server and server-Squid traffic, look at what Squid has received from the client and what Squid sent to the client, all in actual order. > 61 Alert (Level: Fatal, Description: Internal Error) to certificate sent by > Server > > cache.log: > 2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21: > error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify > failed (1/-1/0) > 2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21: > error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify > failed (1/-1/0) > > This is an internal server with its own CA certs. Is your Squid configured to trust those internal CAs? If not, Squid would not be able to validate the server certificate. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] redirect based on url (302)
Thanks,
Missed that I need to install squid-helpers "yum install squid-helpers" :-)
Now it's there.
Now I use it like this:
external_acl_type whitelist ttl=60 children-max=1 %SRC %DST
/usr/lib64/squid/ext_sql_session_acl --user root --password config --table
sessions --cond "" --debug
But receive this:
/2018/10/30 12:38:37.279| 82,9| external_acl.cc(600) aclMatchExternal:
acl="whitelist"
2018/10/30 12:38:37.280| 82,9| external_acl.cc(629) aclMatchExternal: No
helper entry available
2018/10/30 12:38:37.280| 82,2| external_acl.cc(663) aclMatchExternal:
whitelist("130.238.171.59 muse.jhu.edu -") = lookup needed
2018/10/30 12:38:37.280| 82,2| external_acl.cc(667) aclMatchExternal:
"130.238.171.59 muse.jhu.edu -": queueing a call.
2018/10/30 12:38:37.280| 82,2| external_acl.cc(1031) Start: fg lookup in
'whitelist' for '130.238.171.59 muse.jhu.edu -'
2018/10/30 12:38:37.280| 82,4| external_acl.cc(1071) Start:
externalAclLookup: looking up for '130.238.171.59 muse.jhu.edu -' in
'whitelist'.
2018/10/30 12:38:37.280| Starting new whitelist helpers...
2018/10/30 12:38:37.282| 82,4| external_acl.cc(1086) Start:
externalAclLookup: will wait for the result of '130.238.171.59 muse.jhu.edu
-' in 'whitelist' (ch=0x26782c8).
2018/10/30 12:38:37.282| 82,2| external_acl.cc(670) aclMatchExternal:
"130.238.171.59 muse.jhu.edu -": return -1.
Received: Channel=, UID=''
Query: SELECT '' as 'user', '' as 'tag' FROM sessions WHERE (id = ?) UID
queried: ''
Rows: 0
2018/10/30 12:38:37.420| 82,2| external_acl.cc(958) externalAclHandleReply:
reply={result=Unknown, other: "ERR message="unknown UID ''""}/
Looking into the code of ext_sql_session_ac and line 190:
*my ($cid, $uid) = ($1, $2);*
I assume this will split the $_into $cid and $uid. But debug says:
*Received: Channel=, UID=''*
Query: SELECT '' as 'user', '' as 'tag' FROM sessions WHERE (id = ?) UID
queried: ''
Rows: 0
Do I have done something wrong?
/Fredrik
--
Sent from:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Squid 4.3: SSL Bump fails to send client certificate
Hi, I have following Squid version installed on CentOS 7: [root@localhost ~]# squid -v Squid Cache: Version 4.3 Service Name: squid This binary uses OpenSSL 1.0.2k-fips 26 Jan 2017. For legal restrictions on distribution see https://www.openssl.org/source/license.html configure options: '--prefix=/usr' '--includedir=/usr/include' '--datadir=/usr/share' '--bindir=/usr/sbin' '--libexecdir=/usr/lib/squid' '--localstatedir=/var' '--sysconfdir=/etc/squid' '--with-openssl' '--enable-ssl-crtd' Squid.conf: # Recommended minimum configuration: # # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed #acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN) #acl localnet src 10.0.0.0/8# RFC 1918 local private network (LAN) #acl localnet src 100.64.0.0/10 # RFC 6598 shared address space (CGN) #acl localnet src 169.254.0.0/16# RFC 3927 link-local (directly plugged) machines #acl localnet src 172.16.0.0/12 # RFC 1918 local private network (LAN) #acl localnet src 10.133.64.0/22# RFC 1918 local private network (LAN) acl localnet src 20.20.64.0/24 acl localnet src 192.168.1.0/24 #acl localnet src 10.133.65.0/22 #acl localnet src 10.133.66.0/22 #acl localnet src 10.133.67.0/22 #acl localnet src fc00::/7 # RFC 4193 local private network range #acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl SSL_ports port 443 acl SSL_ports port 8443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 8443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # # Recommended minimum Access Permission configuration: # # Deny requests to certain unsafe ports http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports # Only allow cachemgr access from localhost http_access allow localhost manager http_access deny manager # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on "localhost" is a local user #http_access deny to_localhost # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed http_access allow localnet http_access allow localhost # And finally deny all other access to this proxy http_access deny all # Squid normally listens to port 3128 #http_port 3128 http_port 3128 ssl-bump \ cert=/usr/local/squid/etc/ssl_cert/myCA.pem \ generate-host-certificates=on dynamic_cert_mem_cache_size=4MB # For squid 3.5.x #sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB # For squid 4.x sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s /var/lib/ssl_db -M 4MB acl step1 at_step SslBump1 ssl_bump peek step1 ssl_bump bump all tls_outgoing_options cafile=/usr/local/squid/etc/UCAppsCA.pem sslproxy_foreign_intermediate_certs /usr/local/squid/etc/UCAppsCA.pem # Uncomment and adjust the following to add a disk cache directory. cache_effective_user squid cache_dir ufs /usr/local/squid/var/cache/squid 100 16 256 # Leave coredumps in the first cache dir coredump_dir /usr/local/squid/var/cache/squid # # Add any of your own refresh_pattern entries above these. # refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 xx Browser & HTTP UA Client connections are working with SSL bump properly; but except for one connection. Server sends certificate with SNI; but squid forwards it as IP Address to client 1540529604.672 49 20.20.64.91 NONE/200 0 CONNECT 20.20.64.56:443 - HIER_DIRECT/20.20.64.56 - When I took wireshark on Squid; I can see Squid sends: 61 Alert (Level: Fatal, Description: Internal Error) to certificate sent by Server cache.log: 2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0) 2018/10/30 12:55:47 kid1| ERROR: negotiating TLS on FD 21: error:14090086:SSL
