Re: [squid-users] dh key too small
On 2/15/21 4:42 PM, Marek Greško wrote: > Hello, > > most probably the problem is on the server side: > > openssl s_client -connect www.p-mat.sk:443 -tls1 > CONNECTED(0003) > depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > verify return:1 > depth=0 CN = p-mat.sk > verify return:1 > 139797750867776:error:141A318A:SSL routines:tls_process_ske_dhe:dh key > too small:ssl/statem/statem_clnt.c:2157: > > It seems their DH params are too small. What are the possibilities to > overcome the problem on squid side? Unfortunately, I can only answer with a question: Does OpenSSL have a runtime option to allow too-small keys? If yes, you may be able to use that option with tls_outgoing_options. Alex. > 2021-02-15 19:56 GMT+01:00, Marek Greško : >> Hello, >> >> I am struggling with "ERROR: negotiating TLS on FD 53: >> error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small >> (1/-1/0)" error when ssl bumping. >> >> I cannot find out where the problem liesand why is the key too small. >> I regenerated my dhparams with openssl dhparam -outform PEM -out >> dhparam.pem 4096. >> >> http_port 3128 ssl-bump \ >> generate-host-certificates=on \ >> dynamic_cert_mem_cache_size=4MB \ >> cert=/**/bump-ca.crt \ >> key=/**/bump-ca.key \ >> tls-dh=/etc/squid/dhparam.pem >> >> ssl_bump peek step1 >> ssl_bump bump bumped_group !bank_dom >> ssl_bump splice all >> >> I use recent Fedora 33 packages. >> >> I observe the issue when connecting to https://www.p-mat.sk as a bumped >> user. >> >> Thanks for any help. >> >> Marek >> > ___ > 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] Started testing squid-6.0.0-20210204-r5f37a71ac
On 2/16/21 2:40 AM, Eliezer Croitoru wrote:
> Google host means that the host that squid couldn't connect ie :
connection on conn2195 local=216.58.198.67:443
remote=192.168.189.94:41724 FD 104 flags=33: 0x55cf6a6debe0*1
>
> 216.58.198.67:443
>
> The issue can be teste against this host.( the above)
> There is an issue with ssl bump and this specific host is a re-producible
> issue/case/problem.
Thank you for clarifying that.
FWIW, in my tests, a v6-based Squid successfully bumps the connection to
(a result of the reverse DNS lookup of) 216.58.198.67 IP address:
> ... NONE_NONE/200 0 CONNECT dub08s02-in-f3.1e100.net:443 ...
> ... TCP_MISS/404 1960 GET https://dub08s02-in-f3.1e100.net/ ...
Also, the ERROR message you shared earlier suggests that the problem
happens when accepting a TLS client connection ("failure while accepting
a TLS"), but your summary above says "squid couldn't connect" as if the
problem happens when establishing a TLS connection with the server.
The information you have provided so far does not tell me what goes
wrong in your tests. Hopefully, somebody will volunteer to reproduce
this and discover the cause of these connection establishment problems.
Alternatively, you can try sharing an ALL,9 cache.log of the isolated
failed transaction[1]. After that, we will probably know how to address
those problems.
[1]
https://wiki.squid-cache.org/SquidFaq/BugReporting#Debugging_a_single_transaction
Alex.
> -Original Message-
> From: Alex Rousskov
> Sent: Monday, February 15, 2021 9:03 PM
> To: Eliezer Croitoru ; squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] Started testing squid-6.0.0-20210204-r5f37a71ac
>
> On 2/15/21 6:32 AM, Eliezer Croitoru wrote:
>
>> Where exactly do you see Host Header Forgery in my last email?
>
> Your last email says "google hosts". The previous email from you (in the
> same thread) said "Most of the issues I see are related to Host header
> forgery detection" and then named "google host related issue" to be "the
> main issue". I naturally assumed that you are talking about a set of
> Host forgery related issues with one specific Host forgery detection
> issue being the prevalent/major one.
>
> If my assumption was wrong, then you have not addressed the problem I
> stated in my very first response -- I still do not know what "google
> host related issue" is. The cache.log lines you have posted do not
> answer that question for me. You seem to know what the problem actually
> is, so, if you want answers, perhaps you can detail/explain the problem
> you are asking about.
>
> Alex.
>
>
>> -Original Message-
>> From: Alex Rousskov
>> Sent: Thursday, February 11, 2021 7:02 PM
>> To: Eliezer Croitoru ;
>> squid-users@lists.squid-cache.org
>> Subject: Re: [squid-users] Started testing squid-6.0.0-20210204-r5f37a71ac
>>
>> On 2/11/21 10:41 AM, Eliezer Croitoru wrote:
>>
>>> The issue that makes it's impossible to surf not to cache.
>>> The
2021/02/07 19:46:07 kid1| ERROR: failure while accepting a TLS
connection on conn2195 local=216.58.198.67:443
remote=192.168.189.94:41724 FD 104 flags=33: 0x55cf6a6debe0*1
current master transaction: master78
which is a google host related issue.
>>>
>>> The access to google hosts seems to be the main issue here.
>>
>> How is this different from the host forgery related discussions we
>> recently had? I consider the general "What can we do about host forgery
>> errors?" question answered already. If you disagree with those answers,
>> we can discuss further, but, to make progress, you need to say
>> explicitly which answer you disagree with and why.
>>
>> Alex.
>>
>>
>>> -Original Message-
>>> From: Alex Rousskov
>>> Sent: Tuesday, February 9, 2021 11:03 PM
>>> To: Eliezer Croitoru ;
>>> squid-users@lists.squid-cache.org
>>> Subject: Re: [squid-users] Started testing squid-6.0.0-20210204-r5f37a71ac
>>>
>>> On 2/7/21 12:47 PM, Eliezer Croitoru wrote:
I move on to testing squid-6.0.0-20210204-r5f37a71ac
Most of the issues I see are related to Host header forgery detection.
I do see that the main issue with TLS is similar to:
2021/02/07 19:46:07 kid1| ERROR: failure while accepting a TLS
connection on conn2195 local=216.58.198.67:443
remote=192.168.189.94:41724 FD 104 flags=33: 0x55cf6a6debe0*1
current master transaction: master78
which is a google host related issue.
>>>
>>>
Alex and Amos,
Can the project do something about this?
>>> FWIW, I do not understand what you are asking about -- it is not clear
>>> to me what "this" is in the context of your question. As you know, there
>>> have been several recent discussions about host header forgery detection
>>> problems. It is not clear to me whether you are asking about some
>>> specific new case or want to revisit some specific aspects of those
>>> discussions.
>>>
>>> Alex.
>>>
Re: [squid-users] Why some traffic is TCP_DENIED
On 16/02/21 11:09 pm, Vieri wrote: Hi, I'm trying to understand why Squid denies access to some sites, eg: [Tue Feb 16 10:15:36 2021].044 0 - TCP_DENIED/302 0 GET http://www.microsoft.com/pki/certs/MicRooCerAut2011_2011_03_22.crt - HIER_NONE/- text/html [Tue Feb 16 10:15:36 2021].050 46 10.215.248.160 TCP_DENIED/403 3352 - 52.109.12.25:443 - HIER_NONE/- text/html [Tue Feb 16 10:15:36 2021].050 0 10.215.248.160 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- - [Tue Feb 16 10:15:36 2021].052 140 10.215.246.144 TCP_MISS/200 193311 GET https://outlook.office.com/mail/ - ORIGINAL_DST/52.97.168.210 text/html [Tue Feb 16 10:15:36 2021].053 49 10.215.248.74 TCP_MISS/200 2037 GET https://puk1-collabhubrtc.officeapps.live.com/rtc2/signalr/negotiate? - ORIGINAL_DST/52.108.88.1 application/json [Tue Feb 16 10:15:36 2021].057 0 10.215.247.159 NONE_NONE/000 0 - error:invalid-request - HIER_NONE/- - [Tue Feb 16 10:15:36 2021].057 0 10.215.247.159 TCP_DENIED/403 3353 - 40.67.251.132:443 - HIER_NONE/- text/html [Tue Feb 16 10:15:36 2021].057 0 10.215.247.159 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- - If I take the first line in the log and I open the URL from a client I use then the site opens as expected, and the corresponding Squid log is: [Tue Feb 16 10:45:50 2021].546 628 10.215.111.210 TCP_MISS/200 2134 GET https://www.microsoft.com/pki/certs/MicRooCerAut2011_2011_03_22.crt - ORIGINAL_DST/23.210.36.30 application/octet-stream [Tue Feb 16 10:45:52 2021].668 49 10.215.111.210 NONE_NONE/000 0 CONNECT 216.58.215.138:443 - ORIGINAL_DST/216.58.215.138 - In this log I see my host's IP addr. 10.215.111.210. However, in the first log I do not see a source IP address. Why? Because this is Squid downloading the cert for its own use. For example SSL-Bump needing it to complete a TLS cert chain. Other clients seem to be denied access with errors in the log such as "NONE_NONE/000" followed by error:invalid-request or error:transaction-end-before-headers. How can I find out why I get "invalid requests"? Would a tcpdump on the server or client help? Or should I enable verbose debugging in Squid? Looking at all these lines together I see; * a client TLS connection being intercepted, the server cert chain in incomplete. * Squid attempts to download the missing cert(s). * squid.conf rules force the cert download to get a 302 instead of a valid cert. * which leaves Squid unable to send the TLS connection client a valid cert chain. * the client rejects the TLS handshake and disconnects before any HTTP happens. To avoid these, you need to prevent your squid.conf rules generating that 302 when Squid is initiating the request. The ACL type "transaction_initiator" can be used for that. Amos ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid http CONNECT
On 2/16/21 2:29 AM, Kevin Shell wrote: What requirements are needed for smtps imaps pop3s nntps client programs to tunnel thru squid proxy? On 16.02.21 11:28, Alex Rousskov wrote: If your Squid is a forward proxy, then those clients have to support HTTP (and/or HTTPS) forward proxies. In other words, they should establish a standard HTTP CONNECT tunnel through Squid. If you are intercepting their traffic, then there are no special requirements for those clients. You will have to configure Squid to splice the intercepted connection before getting to unencrypted bytes so your Squid will be limited to very basic checks at or below the TLS layer. also, squid must allow CONNECT to smtps, imaps, pop3s and nntps ports. which usually means, they have to be added to ssl_ports ACL. -- 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. He who laughs last thinks slowest. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid http CONNECT
On 2/16/21 2:29 AM, Kevin Shell wrote: > What requirements are needed for smtps imaps pop3s nntps client programs > to tunnel thru squid proxy? If your Squid is a forward proxy, then those clients have to support HTTP (and/or HTTPS) forward proxies. In other words, they should establish a standard HTTP CONNECT tunnel through Squid. If you are intercepting their traffic, then there are no special requirements for those clients. You will have to configure Squid to splice the intercepted connection before getting to unencrypted bytes so your Squid will be limited to very basic checks at or below the TLS layer. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Fwd: The user/password pair is correct, yet squid keeps sending me TCP_DENIED/407
I just realized gmail was using the wrong reply address. Sorry about that. > > acl GRP2 external ADGroup CN=UsuariosInternet,OU=UsersOU,DC=example,DC=com > > acl GRP3 external ADGroup CN=GRP3,OU=UsersOU,DC=example,DC=com > > acl GRP4 external ADGroup CN=GRP4,OU=UsersOU,DC=example,DC=com > > All these group checks will trigger re-authenticate if the user is not a > member of the group(s) being checked - in case a different login would work. > > This issue is where the "all hack" comes from. Put "all" at the end of > the deny lines which need to end with a group check. Or where possible > rearrange the ACL checks to put some other ACL type after the group check. > > > For example: ... > > > http_access deny !GRP3 !GRP2 !GRP4 > > ... here: > >http_access deny !GRP3 !GRP2 !GRP4 all > > > > http_access deny !InternalSites GRP3 !GRP2 > > ... here: >http_access deny GRP3 !GRP2 !InternalSites > > > > http_access allow SocialNetworks GRP4 > > ... here: >http_access allow GRP4 SocialNetworks holly ..., that is a tricky detail I just read https://wiki.squid-cache.org/action/show/Features/Authentication. The squid team should put some warning on the config file or something to bring this detail to prominence. THANK YOU VERY MUCH > > > http_access deny SocialNetworks > > acl BlackListedDomains1 dstdomain -n > > '/etc/squid/Sites/Forbidden/BlackListedDomains1' > > http_access deny BlackListedDomains1 > > acl BlackListedDomains2 dstdomain -n > > '/etc/squid/Sites/Forbidden/BlackListedDomains2' > > http_access deny BlackListedDomains2 > > acl BlackListedDomains3 dstdomain -n > > '/etc/squid/Sites/Forbidden/BlackListedDomains3' > > http_access deny BlackListedDomains3 > > acl BlackListedDomains4 dstdomain -n > > '/etc/squid/Sites/Forbidden/BlackListedDomains4' > > http_access deny BlackListedDomains4 > > Any particular reason for some many different blacklists? > > It is a faster check and simpler config file to either have one > blacklist file, or to load all the files as one ACL name. Easy maintenance. I want to know/remember why I blacklisted some specific domain. Keep in mind I "anonymised" the config file before posting, so the generic names, the example.com domain, etc. > > acl REBlackListedDomains1 dstdom_regex -i > > '/etc/squid/Sites/Forbidden/REBlackListedDomains1' > > http_access deny REBlackListedDomains1 > > acl REBlackListedDomains2 dstdom_regex -i > > '/etc/squid/Sites/Forbidden/REBlackListedDomains2' > > http_access deny REBlackListedDomains2 > > acl REBlackListedDomains3 dstdom_regex -i > > '/etc/squid/Sites/Forbidden/REBlackListedDomains3' > > http_access deny REBlackListedDomains3 > > Same for the regex blacklists. > Same for the regex blacklists. ;-) > > 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
[squid-users] Why some traffic is TCP_DENIED
Hi, I'm trying to understand why Squid denies access to some sites, eg: [Tue Feb 16 10:15:36 2021].044 0 - TCP_DENIED/302 0 GET http://www.microsoft.com/pki/certs/MicRooCerAut2011_2011_03_22.crt - HIER_NONE/- text/html [Tue Feb 16 10:15:36 2021].050 46 10.215.248.160 TCP_DENIED/403 3352 - 52.109.12.25:443 - HIER_NONE/- text/html [Tue Feb 16 10:15:36 2021].050 0 10.215.248.160 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- - [Tue Feb 16 10:15:36 2021].052 140 10.215.246.144 TCP_MISS/200 193311 GET https://outlook.office.com/mail/ - ORIGINAL_DST/52.97.168.210 text/html [Tue Feb 16 10:15:36 2021].053 49 10.215.248.74 TCP_MISS/200 2037 GET https://puk1-collabhubrtc.officeapps.live.com/rtc2/signalr/negotiate? - ORIGINAL_DST/52.108.88.1 application/json [Tue Feb 16 10:15:36 2021].057 0 10.215.247.159 NONE_NONE/000 0 - error:invalid-request - HIER_NONE/- - [Tue Feb 16 10:15:36 2021].057 0 10.215.247.159 TCP_DENIED/403 3353 - 40.67.251.132:443 - HIER_NONE/- text/html [Tue Feb 16 10:15:36 2021].057 0 10.215.247.159 NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE/- - If I take the first line in the log and I open the URL from a client I use then the site opens as expected, and the corresponding Squid log is: [Tue Feb 16 10:45:50 2021].546 628 10.215.111.210 TCP_MISS/200 2134 GET https://www.microsoft.com/pki/certs/MicRooCerAut2011_2011_03_22.crt - ORIGINAL_DST/23.210.36.30 application/octet-stream [Tue Feb 16 10:45:52 2021].668 49 10.215.111.210 NONE_NONE/000 0 CONNECT 216.58.215.138:443 - ORIGINAL_DST/216.58.215.138 - In this log I see my host's IP addr. 10.215.111.210. However, in the first log I do not see a source IP address. Why? Other clients seem to be denied access with errors in the log such as "NONE_NONE/000" followed by error:invalid-request or error:transaction-end-before-headers. How can I find out why I get "invalid requests"? Would a tcpdump on the server or client help? Or should I enable verbose debugging in Squid? BTW this might be irrelevant but these messages seem to come up when accessing office 365 sites. Thanks, Vieri ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
