[squid-users] PHP: failed to open stream: Cannot connect to HTTPS server through proxy
I tried to install a joomla-Plugin from behind squid. It didn't work. I could reproduce the error using the following php-script: > $url="https://downloads.joomla.org/extensions/install-from-web/1-1-1/ plg_webinstaller_3.7v1.1.1.zip"; > $ctx = stream_context_create(['http' => ['proxy' => "tcp://$proxy:$port"], > 'ssl' => ['capture_session_meta' => TRUE]]); > $html = file_get_contents($url , FALSE, $ctx); > $meta = stream_context_get_options($ctx)['ssl']['session_meta']; > var_dump($meta); > ?> Results in: > PHP Warning: file_get_contents(): Peer certificate CN=`*.s3-us- west-2.amazonaws.com' did not match expected CN=`downloads.joomla.org' in / tmp/test.php on line 5 > PHP Warning: file_get_contents(https://downloads.joomla.org/extensions/ install-from-web/1-1-1/plg_webinstaller_3.7v1.1.1.zip): failed to open stream: Cannot connect to HTTPS server through proxy in /tmp/test.php on line 5 For $url="https://cdn.joomla.org/images/Joomla_logo.png"; it works. Squid produces the following log: 2018/03/10 13:19:48.252 kid1| 5,2| TcpAcceptor.cc(226) doAccept: New connection on FD 17 2018/03/10 13:19:48.252 kid1| 5,2| TcpAcceptor.cc(317) acceptNext: connection on local=localhost:localport remote=[::] FD 17 flags=9 2018/03/10 13:19:48.252 kid1| 17,2| QosConfig.cc(126) getNfmarkFromConnection: QOS: Failed to retrieve connection mark: (-1) (1) Operation not permitted (Destination localhost:localport, source localhost:47200) 2018/03/10 13:19:48.252 kid1| 11,2| client_side.cc(1329) parseHttpRequest: HTTP Client local=localhost:localport remote=localhost:47200 FD 18 flags=1 2018/03/10 13:19:48.252 kid1| 11,2| client_side.cc(1333) parseHttpRequest: HTTP Client REQUEST: - CONNECT downloads.joomla.org:443 HTTP/1.0 -- 2018/03/10 13:19:48.253 kid1| 85,2| client_side_request.cc(755) clientAccessCheckDone: The request CONNECT downloads.joomla.org:443 is ALLOWED; last ACL checked: all 2018/03/10 13:19:48.253 kid1| 85,2| client_side_request.cc(731) clientAccessCheck2: No adapted_http_access configuration. default: ALLOW 2018/03/10 13:19:48.253 kid1| 85,2| client_side_request.cc(755) clientAccessCheckDone: The request CONNECT downloads.joomla.org:443 is ALLOWED; last ACL checked: all 2018/03/10 13:19:48.253 kid1| 44,2| peer_select.cc(282) peerSelectDnsPaths: Find IP destination for: downloads.joomla.org:443' via downloads.joomla.org 2018/03/10 13:19:48.253 kid1| 44,2| peer_select.cc(303) peerSelectDnsPaths: Found sources for 'downloads.joomla.org:443' 2018/03/10 13:19:48.253 kid1| 44,2| peer_select.cc(304) peerSelectDnsPaths: always_direct = DENIED 2018/03/10 13:19:48.253 kid1| 44,2| peer_select.cc(305) peerSelectDnsPaths: never_direct = DENIED 2018/03/10 13:19:48.253 kid1| 44,2| peer_select.cc(309) peerSelectDnsPaths: DIRECT = local=0.0.0.0 remote=72.29.124.146:443 flags=1 2018/03/10 13:19:48.253 kid1| 44,2| peer_select.cc(318) peerSelectDnsPaths: timedout = 0 2018/03/10 13:19:48.925 kid1| 33,2| client_side.cc(585) swanSong: local=localhost:localport remote=localhost:47200 flags=1 ==> /var/log/squid/access.log <== localhost - - [10/Mar/2018:13:19:48 +] "CONNECT downloads.joomla.org:443 HTTP/1.0" 200 5843 "-" "-" TCP_TUNNEL:HIER_DIRECT [] [] ==> /var/log/squid/cache.log <== 2018/03/10 13:19:48.927 kid1| 5,2| TcpAcceptor.cc(226) doAccept: New connection on FD 17 2018/03/10 13:19:48.928 kid1| 5,2| TcpAcceptor.cc(317) acceptNext: connection on local=localhost:localport remote=[::] FD 17 flags=9 2018/03/10 13:19:48.928 kid1| 17,2| QosConfig.cc(126) getNfmarkFromConnection: QOS: Failed to retrieve connection mark: (-1) (1) Operation not permitted (Destination localhost:localport, source localhost:47206) 2018/03/10 13:19:48.972 kid1| 11,2| client_side.cc(1329) parseHttpRequest: HTTP Client local=localhost:localport remote=localhost:47206 FD 18 flags=1 2018/03/10 13:19:48.972 kid1| 11,2| client_side.cc(1333) parseHttpRequest: HTTP Client REQUEST: - CONNECT s3-us-west-2.amazonaws.com:443 HTTP/1.0 -- 2018/03/10 13:19:48.973 kid1| 85,2| client_side_request.cc(755) clientAccessCheckDone: The request CONNECT s3-us-west-2.amazonaws.com:443 is ALLOWED; last ACL checked: all 2018/03/10 13:19:48.973 kid1| 85,2| client_side_request.cc(731) clientAccessCheck2: No adapted_http_access configuration. default: ALLOW 2018/03/10 13:19:48.973 kid1| 85,2| client_side_request.cc(755) clientAccessCheckDone: The request CONNECT s3-us-west-2.amazonaws.com:443 is ALLOWED; last ACL checked: all 2018/03/10 13:19:48.973 kid1| 44,2| peer_select.cc(282) peerSelectDnsPaths: Find IP destination for: s3-us-west-2.amazonaws.com:443' via s3-us- west-2.amazonaws.com 2018/03/10 13:19:49.006 kid1| 44,2| peer_select.cc(303) peerSelectDnsPaths: Found sources for 's3-us-west-2.amazonaws.com:443' 2018/03/10 13:19:49.006 kid1| 44,2| peer_select.cc(304) peerSelectDnsPaths: always_direct = DENIED 2018/03/10 13:19:49.006 kid1| 44,2| peer_select.cc(305) peerSelectDnsPath
Re: [squid-users] Transition from squid3.5 to squid4; ciphers don't work anymore, ERROR: Unknown TLS option SINGLE_DH_USE
Am Samstag, 17. Februar 2018, 14:28:04 CET schrieb chiasa.men: > Am Montag, 12. Februar 2018, 14:29:09 CET schrieb chiasa.men: > > Hi I tried squid4. > > > > Squid Cache: Version 4.0.23 > > This binary uses OpenSSL 1.1.1-dev xx XXX > > > > Before, I used: > > Squid Cache: Version 3.5.27 > > This binary uses OpenSSL 1.0.2g 1 Mar 2016 > > > > Some of the config directives changed: > > E.g. > > sslproxy_options SINGLE_DH_USE,SINGLE_ECDH_USE > > -> > > tls_tls_outgoing_options options=SINGLE_DH_USE,SINGLE_ECDH_USE > > > > But that results in version 4 in the follwing errors (cache.log) > > ERROR: Unknown TLS option SINGLE_DH_USE > > ERROR: Unknown TLS option SINGLE_ECDH_USE > > > > (same error with the same options in https_proxy) > > > > Is that a problem related to the openssl version change? > > > > > > In cache_peer I also have now to configure tls-cafile=/etc/ssl/certs/ca- > > certificates.crt explicitly (I used some self signed certificates for > > testing - but in Squid3 I didn't need to configure that) > > Otherwise I get: > > (71) Protocol error (TLS code: X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN) > > > > In the reference it's stated that: > > tls-default-ca[=off] > > > > Whether to use the system Trusted CAs. Default is ON. > > > > Shouldn't the tls-cafile option be unnecessary since it's trusted by > > default? > > > > > > > > Furthermore I set Apache (the peer) to "SSLCipherSuite > > ECDHE-ECDSA-AES256- > > GCM-SHA384" > > as well as cache_peer sslcipher=ECDHE-ECDSA-AES256-GCM-SHA384 > > > > ERROR: negotiating TLS on FD 20: error:141A90B5:SSL > > routines:ssl_cipher_list_to_bytes:no ciphers available (1/-1/0) > > > > How can that be? > > > > > > > > > > ___ > > squid-users mailing list > > squid-users@lists.squid-cache.org > > http://lists.squid-cache.org/listinfo/squid-users > > Any idea? I could solve the "no ciphers available" by appending "TLS13-AES-256-GCM- SHA384" to the ciphers. But the log shows the use of "ECDHE-ECDSA-AES256-GCM-SHA384" Why is that cipher relevant if its not used? ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Transition from squid3.5 to squid4; ciphers don't work anymore, ERROR: Unknown TLS option SINGLE_DH_USE
Am Montag, 12. Februar 2018, 14:29:09 CET schrieb chiasa.men: > Hi I tried squid4. > > Squid Cache: Version 4.0.23 > This binary uses OpenSSL 1.1.1-dev xx XXX > > Before, I used: > Squid Cache: Version 3.5.27 > This binary uses OpenSSL 1.0.2g 1 Mar 2016 > > Some of the config directives changed: > E.g. > sslproxy_options SINGLE_DH_USE,SINGLE_ECDH_USE > -> > tls_tls_outgoing_options options=SINGLE_DH_USE,SINGLE_ECDH_USE > > But that results in version 4 in the follwing errors (cache.log) > ERROR: Unknown TLS option SINGLE_DH_USE > ERROR: Unknown TLS option SINGLE_ECDH_USE > > (same error with the same options in https_proxy) > > Is that a problem related to the openssl version change? > > > In cache_peer I also have now to configure tls-cafile=/etc/ssl/certs/ca- > certificates.crt explicitly (I used some self signed certificates for > testing - but in Squid3 I didn't need to configure that) > Otherwise I get: > (71) Protocol error (TLS code: X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN) > In the reference it's stated that: > tls-default-ca[=off] > Whether to use the system Trusted CAs. Default is ON. > Shouldn't the tls-cafile option be unnecessary since it's trusted by > default? > > > > Furthermore I set Apache (the peer) to "SSLCipherSuite ECDHE-ECDSA-AES256- > GCM-SHA384" > as well as cache_peer sslcipher=ECDHE-ECDSA-AES256-GCM-SHA384 > > ERROR: negotiating TLS on FD 20: error:141A90B5:SSL > routines:ssl_cipher_list_to_bytes:no ciphers available (1/-1/0) > > How can that be? > > > > > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users Any idea? ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Transition from squid3.5 to squid4; ciphers don't work anymore, ERROR: Unknown TLS option SINGLE_DH_USE
Hi I tried squid4. Squid Cache: Version 4.0.23 This binary uses OpenSSL 1.1.1-dev xx XXX Before, I used: Squid Cache: Version 3.5.27 This binary uses OpenSSL 1.0.2g 1 Mar 2016 Some of the config directives changed: E.g. sslproxy_options SINGLE_DH_USE,SINGLE_ECDH_USE -> tls_tls_outgoing_options options=SINGLE_DH_USE,SINGLE_ECDH_USE But that results in version 4 in the follwing errors (cache.log) ERROR: Unknown TLS option SINGLE_DH_USE ERROR: Unknown TLS option SINGLE_ECDH_USE (same error with the same options in https_proxy) Is that a problem related to the openssl version change? In cache_peer I also have now to configure tls-cafile=/etc/ssl/certs/ca- certificates.crt explicitly (I used some self signed certificates for testing - but in Squid3 I didn't need to configure that) Otherwise I get: (71) Protocol error (TLS code: X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN) In the reference it's stated that: tls-default-ca[=off] Whether to use the system Trusted CAs. Default is ON. Shouldn't the tls-cafile option be unnecessary since it's trusted by default? Furthermore I set Apache (the peer) to "SSLCipherSuite ECDHE-ECDSA-AES256- GCM-SHA384" as well as cache_peer sslcipher=ECDHE-ECDSA-AES256-GCM-SHA384 ERROR: negotiating TLS on FD 20: error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available (1/-1/0) How can that be? ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] WARNING: DNS lookup for 'example.com' failed!
I have to restart squid after each reboot to get it working. I think that is because squid starts before systemd has started the network and so the dns lookups fail: journalctl says: "squid.service: Unit cannot be reloaded because it is inactive." cache.log contains: "WARNING: DNS lookup for 'example.com' failed!" The problems seems to be the squid.service file which I took from ubuntus squid package: # Automatically generated by systemd-sysv-generator [Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/squid Description=LSB: Squid HTTP Proxy version 3.x Before=multi-user.target Before=multi-user.target Before=multi-user.target Before=graphical.target Before=shutdown.target After=network-online.target After=remote-fs.target After=systemd-journald-dev-log.socket After=nss-lookup.target Wants=network-online.target Conflicts=shutdown.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes ExecStart=/etc/init.d/squid start ExecStop=/etc/init.d/squid stop ExecReload=/etc/init.d/squid reload Did anybody have the same problem and a nicer solution than adding each hostname to /etc/hosts? ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] RC4-MD5 cipher is always enabled?
Am Dienstag, 5. September 2017, 11:57:06 CEST schrieb Amos Jeffries: > On 05/09/17 20:55, chiasa.men wrote> Thanks, that was easy... but: > > That does not work: > > > > https_port 3128 accel defaultsite=www.example.com cert=/example/cert.pem > > key=/ example/key.pem cipher=ECDHE-ECDSA-AES256-GCM-SHA384:!RC4:!MD5 > > > > openssl s_client -connect localhost:3128 > > 140048907216536:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 > > alert handshake failure:s23_clnt.c:769: > > > > > > Allowing RC4 and MD5 works: > > > > https_port 3128 accel defaultsite=www.example.com cert=/example/cert.pem > > key=/ example/key.pem cipher=ECDHE-ECDSA-AES256-GCM-SHA384:RC4:MD5 > > > > openssl s_client -connect localhost:3128 > > > > Cipher: ECDH-ECDSA-RC4-SHA > > > > But openssl works without allowing RC4 and MD5: > > > > openssl s_server -cert /example/cert.pem -key /example/key.pem -cipher > > 'ECDHE- ECDSA-AES256-GCM-SHA384:!RC4:!MD5' > > > > openssl s_client -connect localhost:4433 > > > > Cipher: ECDHE-ECDSA-AES256-GCM-SHA384 > > > > So I guess the certificate and the openssl part should work. > > Maybe you could give another advice? > > " > cipher= > Colon separated list of supported ciphers. > NOTE: some ciphers such as EDH ciphers depend on > additional settings. If those settings are > omitted the ciphers may be silently ignored > by the OpenSSL library." > " > > For the ECDHE-* ciphers to work the server end needs to be configured > with curve parameters. That is done the tls-dh= option with a curve name > and > > " > tls-dh=[curve:]file > File containing DH parameters for temporary/ephemeral DH key > exchanges, optionally prefixed by a curve for ephemeral ECDH > key exchanges. > See OpenSSL documentation for details on how to create the > DH parameter file. Supported curves for ECDH can be listed > using the "openssl ecparam -list_curves" command. > > WARNING: EDH and EECDH ciphers will be silently disabled if > this option is not set. > " > > > btw, the used squid version: > > Squid Cache: Version 3.5.12 > > Service Name: squid > > Ubuntu linux > > Please upgrade. Somewhat urgently. > > * TLS/SSL has had a *lot* of progress in the past few years. There are > many security related issues resolved in the latest releases which exist > in the older ones. > > * ECDHE is a good example of the change. It is not supported *at all* by > that old version of Squid. > > When using TLS/SSL support Squid-3.5.24 is currently the oldest > acceptable Squid release as it contains extra mitigation for TLS DoS > vulnerabilities. The current 3.5.27 would be best from the 3.5 series. > > If you are not already aware there is no official security > support/tracking from Debian and Ubuntu for TLS/SSL vulnerabilities as > their packages do not ship with OpenSSL support. So following their > stable/security package version is of no benefit for TLS/SSL issues, you > need to track upstream releases yourself when custom building software > (that goes for anything, not just Squid). > > Amos > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users Thanks - rtfm often helps. Sorry for that! Furthermore my certificates were not corresponding to the ecc so I had to regenerate them via "openssl ecparam" (not openssl rsa). Kind of obvious but I just forgot about them. The version was simply compiled via apt source on Ubuntu. I'm using the current version now (un/fortunately Ubuntu is not bleeding edge) ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] RC4-MD5 cipher is always enabled?
Am Montag, 4. September 2017, 14:07:54 CEST schrieb Amos Jeffries:
> On 04/09/17 20:36, chiasa.men wrote:
> > "RC4-MD5" seems to be always enabled. Is there a way to prohibit RC4-MD5?
> >
> >
> >
> > squid.conf:
> > https_port 3128 accel defaultsite=www.example.com cert=/example/cert.pem
> > key=/ example/key.pem
>
> Above line configures the what Squid listening port parameters are.
> There are no cipher restrictions listed, so any cipher the library
> configuration allows is accepted on client->Squid connections.
>
> > sslproxy_version 6
> > sslproxy_options NO_SSLv2,NO_SSLv3,NO_TLSv1,NO_TLSv1_1,NO_TICKET
> > sslproxy_cipher ECDHE-ECDSA-AES256-GCM-SHA384:!RC4:!MD5
>
> These lines configure what Squid uses on its outbound server
> connections. Those connections (only) are restricted by !RC4:!MD5.
>
>
> Is the problem obvious now?
>
>
> To make the Squid listening port reject RC4 or MD5 you need to add an
> ssloptions= or sslcipher= parameter to the port line. Its syntax is the
> same as the values on the sslproxy_* lines.
>
>
> PS;
> To make other services on the machine gain these same TLS protections
> you should find and alter the library config file instead. OpenSSL's
> libssl is a bit unusual, despite being a library it has its own
> system-wide config file just like applications.
>
> The squid.conf should only contain things which are different from your
> machines basic security profile.
>
>
> HTH
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
Thanks, that was easy... but:
That does not work:
https_port 3128 accel defaultsite=www.example.com cert=/example/cert.pem key=/
example/key.pem cipher=ECDHE-ECDSA-AES256-GCM-SHA384:!RC4:!MD5
openssl s_client -connect localhost:3128
140048907216536:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
handshake failure:s23_clnt.c:769:
Allowing RC4 and MD5 works:
https_port 3128 accel defaultsite=www.example.com cert=/example/cert.pem key=/
example/key.pem cipher=ECDHE-ECDSA-AES256-GCM-SHA384:RC4:MD5
openssl s_client -connect localhost:3128
Cipher: ECDH-ECDSA-RC4-SHA
But openssl works without allowing RC4 and MD5:
openssl s_server -cert /example/cert.pem -key /example/key.pem -cipher 'ECDHE-
ECDSA-AES256-GCM-SHA384:!RC4:!MD5'
openssl s_client -connect localhost:4433
Cipher: ECDHE-ECDSA-AES256-GCM-SHA384
So I guess the certificate and the openssl part should work.
Maybe you could give another advice?
btw, the used squid version:
Squid Cache: Version 3.5.12
Service Name: squid
Ubuntu linux
configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=$
{prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/
info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/
squid3' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-
tracking' '--disable-silent-rules' 'BUILDCXXFLAGS=-g -O2 -fPIE -fstack-
protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -
fPIE -pie -Wl,-z,relro -Wl,-z,now' '--datadir=/usr/share/squid' '--
sysconfdir=/etc/squid' '--libexecdir=/usr/lib/squid' '--mandir=/usr/share/man'
'--enable-inline' '--disable-arch-native' '--enable-async-io=8' '--enable-
storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-
delay-pools' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-
x-forwarded-for' '--enable-auth-
basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-
digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-
ntlm=fake,smb_lm' '--enable-external-acl-
helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group'
'--enable-url-rewrite-helpers=fake' '--enable-eui' '--with-openssl' '--enable-
ssl-crtd' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap'
'--disable-translation' '--with-swapdir=/var/spool/squid' '--with-logdir=/var/
log/squid' '--with-pidfile=/var/run/squid.pid' '--with-filedescriptors=65536'
'--with-large-files' '--with-default-user=proxy' '--enable-build-info=Ubuntu
linux' '--enable-linux-netfilter' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -
O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall'
'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now'
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-
protector-strong -Wformat -Werror=format-security'
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
[squid-users] RC4-MD5 cipher is always enabled?
"RC4-MD5" seems to be always enabled. Is there a way to prohibit RC4-MD5? squid.conf: https_port 3128 accel defaultsite=www.example.com cert=/example/cert.pem key=/ example/key.pem sslproxy_version 6 sslproxy_options NO_SSLv2,NO_SSLv3,NO_TLSv1,NO_TLSv1_1,NO_TICKET sslproxy_cipher ECDHE-ECDSA-AES256-GCM-SHA384:!RC4:!MD5 squid -f /tmp/s.conf -N -d debug SSLScan reports RC4-MD5 is accepted: sslscan --no-failed localhost:3128 Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 256 bits CAMELLIA256-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 128 bits SEED-SHA Accepted TLSv1 128 bits CAMELLIA128-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 Accepted TLSv1 112 bits DES-CBC3-SHA Connection with RC4-MD5 is successful: openssl s_client -connect localhost:3128 -cipher RC4-MD5 New, TLSv1/SSLv3, Cipher is RC4-MD5 Cipher: RC4-MD5 Connection with rejected ciphers is not successful: openssl s_client -connect localhost:3128 -cipher ECDHE-RSA-NULL-SHA 140016624731800:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769: New, (NONE), Cipher is (NONE) Cipher: ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] (no subject)
Am Freitag, 12. Mai 2017, 14:16:45 CEST schrieb Amos Jeffries: > On 12/05/17 22:31, chiasa.men wrote: > > Am Sonntag, 23. April 2017, 17:57:52 CEST schrieb Amos Jeffries: > >> On 23/04/17 23:25, chiasa@web.de wrote: > >>> Hello > >>> > >>> my squid.conf looks like that: > >>> > >>> https_port 3128 accel cert=/cert.pem key=/cert.key > >>> > >>> defaultsite=ww1.example.com vhost > >>> > >>> acl server20_domains dstdomain ww1.example.com ww2.example.com > >>> > >>> http_access allow server20_domains > >>> > >>> cache_peer server20 parent 443 0 no-query originserver name=server20 > >>> > >>> login=PASSTHRU ssl sslversion=6 > >>> > >>> cache_peer_access server20 allow server20_domains > >>> > >>> cache_peer_access server20 deny all > >>> > >>> The idea was to send ww1 and ww2 to server20 which is hosting an apache > >>> > >>> webservice for both sites. > >> > >> That looks fine. > >> > >>> You can see that approximately after 5s the timeout happens. Is it a > >>> message > >>> > >>> to worry about? (it is just "info" labled) Why does it occur? > >> > >> Unknown. This is an Apache problem. The Squid portion of things appears > >> to be working if I'm reading that weird access.log correctly. > >> > >> Amos > > > > Acutally it's not. The problem seemed to be the > > server_persistent_connections setting in squid.conf. > > By default set to on it tries to keep the cache_peer connection. Apache on > > the other site hit the KeepAliveTimeout which was set to 5 seconds by > > default. server_persistent_connections off in squid.conf > > So Squid is told (by Apache) that the connection is to be kept open / > persistent and then Apache closes it very quickly afterward. That is an > explicit configured problem, but still Apache endpoint is the cause of > the issues you are having here. > > It is not a bug or error for either software, since that is one of the > behaviours explicitly allowed by HTTP. But for you its being a problem. You are absolutely right. > > > It set server_persistent_connections to off and the problem disappeared. > > Is there any downside of this setting? > > 1) Every single HTTP request sent to any upstream server has to go > through a full TCP connection handshake process, then a TCP shutdown > process afterwards. > > 2) TCP socket cannot be used for a second connection until the kernel > has confirmed both endpoints are not going to send anything on it. Which > may be up to 15min. > > Between them these can cause a 50ms extra latency on every request, with > a limit of just over 70 requests per second through the proxy to any > given server - compared to the several tens of thousands Squid can > normally handle and under 1ms latency that is quite bad. > > > The efficient solution is to have long persistence on the connections > between your CDN frontend (Squid) and the backend origins (Apache). You > can make the timeout much shorter on the Squid client connections. I see. So I'll tell apache to set the KeepAliveTimeout to squids default persistent_request_timeout of 2 minutes :) That sounds reasonable. Thank you for the explanation. > > 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] (no subject)
Am Sonntag, 23. April 2017, 17:57:52 CEST schrieb Amos Jeffries: > On 23/04/17 23:25, chiasa@web.de wrote: > > Hello > > > > my squid.conf looks like that: > > > > https_port 3128 accel cert=/cert.pem key=/cert.key > > > > defaultsite=ww1.example.com vhost > > > > acl server20_domains dstdomain ww1.example.com ww2.example.com > > > > http_access allow server20_domains > > > > cache_peer server20 parent 443 0 no-query originserver name=server20 > > > > login=PASSTHRU ssl sslversion=6 > > > > cache_peer_access server20 allow server20_domains > > > > cache_peer_access server20 deny all > > > > The idea was to send ww1 and ww2 to server20 which is hosting an apache > > > > webservice for both sites. > > That looks fine. > > > You can see that approximately after 5s the timeout happens. Is it a > > message > > > > to worry about? (it is just "info" labled) Why does it occur? > > Unknown. This is an Apache problem. The Squid portion of things appears > to be working if I'm reading that weird access.log correctly. > > Amos Acutally it's not. The problem seemed to be the server_persistent_connections setting in squid.conf. By default set to on it tries to keep the cache_peer connection. Apache on the other site hit the KeepAliveTimeout which was set to 5 seconds by default. server_persistent_connections off in squid.conf It set server_persistent_connections to off and the problem disappeared. Is there any downside of this setting? __ |"""\-= () __ |"""\-= () (tanks) Chia ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] https_port Connection reset by peer; http_port works
Am Sonntag, 23. April 2017, 18:03:25 CEST schrieb Amos Jeffries: > You appear not to be using curl correctly. > > Test #1 and #3 show that curl is probably sending the https:// requests > through port 8080 on your proxy as a CONNECT request. Check that in your > Squid log to confirm. I wasn't aware of that thx, but nevertheless the problem still exists curl -x 'proxy:8443' https://www.google.de curl: (56) Recv failure: Connection reset by peer # no log entry curl -x 'proxy:8443' http://www.google.de curl: (56) Recv failure: Connection reset by peer # no log entry curl -x 'proxy:8080' http://www.google.de # no output [23/Apr/2017:19:28:53 +] "GET http://www.google.de/ HTTP/1.1" 301 206 "-" "curl/7.47.0" TCP_DENIED:HIER_NONE curl -x 'proxy:8080' https://www.google.de # works [23/Apr/2017:19:29:27 +] "CONNECT www.google.de:443 HTTP/1.1" 200 15157 "-" "curl/7.47.0" TCP_TUNNEL:HIER_DIRECT The corresponding tcpdumps are here to be found: https://nopaste.me/view/ 1e07d687 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] https_port Connection reset by peer; http_port works
Hello folks I tried to encrypt the connection between client and squid. Therefore I generated certificates which are accepted by the clients and configured squid as followed: Squid.conf https_port 10.0.13.10:8443 cert=/cert.pem key=/cert.key http_port 10.0.13.10:8080 http_access allow all My following tests show that I can use the http port for internet access but the https port wont work. openssl s_client -connect proxy:8443 # Verify return code: 0 (ok) export https_proxy="proxy:8443" export http_proxy="proxy:8080" curl https://www.google.de # curl: (56) Recv failure: Connection reset by peer curl http://www.google.de # works export https_proxy="proxy:8443" export http_proxy="$https_proxy" curl https://www.google.de # curl: (56) Recv failure: Connection reset by peer curl http://www.google.de # curl: (56) Recv failure: Connection reset by peer export http_proxy="proxy:8080" export https_proxy="$http_proxy" curl https://www.google.de # works curl http://www.google.de # works What did I wrong? Do I misunderstand something regarding the configuration options? Regards Chia ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] header_access ssl multiple cache_peers? Redirect http to https
hello there a two cache_peers with ssl enabled webservers. Obviously for both the private keys are available. For http_port squid can use header_access to filter headers. Can squid make use of the known private keys in order to filter the headers for https_port connetions too? How? Is the any method at all to filter headers in ssl connections? Is it possible to make squid redirect http to https? How? (http://example.com redirect to https://example.com) regards chiasa ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
