Im trying to setup Squid 4.8 on Ubuntu 18.04 LTS with HTTPS redirecting to squid error page for sites in ACL's. Yesterday i faced major problem HTTPS sites doesnt open normally in IE11/EDGE and show blank page only + squid replace certificate. If i tap F5, sometimes site opens like it should and certificate replacement doesnt happen...and it works not for all sites. I couldn't pinpoint the dependencies. I also can open some sites like rambler.ru, kanobu.ru, alexa.com normally.
The most interesting thing is that other browsers like Chrome, FF and even Opera open all sites like it should and spoof cert + redirect to error page only if site persist in ACL.
What i already did:
Disabled IPv6 on Squid host
Disabled/Enabled TLS in IE in any variations
Disabled SPDY/3
Bump settings in squid.conf:
http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/squidCA.pem
ssl_bump peek all
I have this errors in /var/log/squid/cache.log
ERROR: negotiating TLS on FD 46: error:1425F175:SSL routines:ssl_choose_client_version:inappropriate fallback (1/-1/0)
ERROR: negotiating TLS on FD 104: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure (1/-1/0)
ERROR: negotiating TLS on FD 27: error:1423406E:SSL routines:tls_parse_stoc_sct:bad extension (1/-1/0)
Error in access.log
TCP_DENIED/407 4141 CONNECT i.ibb.co:443 - HIER_NONE/- text/html
Sorry for complicated description, im new here and its really hard f
or me.
Related
I've seen a lot of similar questions but none of the answers helped me (and there's one addition I didn't see anywhere).
So, I'm using Mamp-Pro 6.0.1 for local testing. I have a domain set up (www.mydomain.lo), enabled SSL and used a self signed certificate I created with the button in Mamp.
I added the cert to my keychain (I'm on a Mac) and set it to «always trust» in the keychain-info.
But when I try to access the local page with https://www.mydomain.lo, I get an error saying:
There was an error connecting to … SSL received an entry which exceeds the max allowed length. Error-Code: SSL_ERROR_RX_RECORD_TOO_LONG
(this is loosely translated from German).
The page works with http:// but I'd like to test the SSL-Version, too.
Any ideas?
I was able to partly solve this riddle.
SSL just doesn't work on local hosts, when the standard port (443) is used.
But it works when the «default MAMP ports» are used.
in MAMP-Pro got to «Ports & User» and click on «Set default MAMP ports».
The ports change as following:
Apache 8888 - SSL 8890
Nginx 7888 - SSL 7890
MySQL 8889
…
It is important that you don't change any of these. I tried to only change the Apache SSL port to 8890 and leave the other ports on their standard (Apache 80, MySQL 3306,…) but then the MySQL-Server doesn't respond.
I switched with my Domain to Cloudflare and now I'm trying to use CloudFlare's SSL Feature.
I already own a SSL cert from StartSSL so I would be possible to set the settings to 'Full (Strict)' but I don't want to so I turned it to 'Full'.
Now I'm getting 525 Errors, after a 'Retry for a live Version' everything is okay.
But I'm getting this Error everytime.
Has anyone an idea ?
Thank you
Picture of my Error
Change Cloudflare SSL/TLS encryption mode in to Flexible. it worked for me.
A 525 error indicates that CloudFlare was unable to contact your origin server and create a SSL connection with it.
This can be due to:
Your servers not having matching or compatible SSL Ciphers
Your website may not have a certificate installed properly
Your website may not have a dedicated IP OR is not configured to use SNI
Attempt to contact your hosting provider for assistance to ensure that your SSL certificate is setup correctly. If you are using a control panel, a quick google search can help you find a install guide for that said control panel.
Visit SSL/TLS tab in Cloudflare. Then:
Switch Your SSL/TLS encryption mode to Flexible.
Make sure to switch On "Always Use HTTPS" under "Edge Certificate" tab.
This will transfer all your request from Http to Https automatically. And if you'll implement custom SSL certificate on your hosting server then this 525 error will automatically disappear without changing anything on Cloudflare.
Got the same problem a few days ago.
Our DevOps contacted support and found out that Cloudflare changed certificate type or smth in that way. Asked to return everything back.
That helped.
I went through the same problem today and found that (at least in my case) it was the lack of TLS v1.3
I had just made a server using nginx + php-fpm and a self signed ssl to use below CloudFlare proxy.
When I switched from the production server to this new one, it gave error 525.
I gave the command: curl -I https://your_server_public_ip/ and it returned the error:
error: 1408F10B: SSL routines: ssl3_get_record: wrong version number
This error is described in the CloudFlare community at:
https://community.cloudflare.com/t/community-tip-fixing-error-525-ssl-handshake-failed/44256
There they advise turning off TLS v1.3 on the CloudFlare panel, but I decided to try installing it.
Using nginx is so easy that I don’t know why to have it shut down.
Only add TLSv1.3 like this-> ssl_protocols TLSv1.2 TLSv1.3; in your nginx/snippets/ssl-params.conf file (default Ubuntu 20 and 18) that will work and you still use the latest and most secure protocols.
I am forcing a dummy SSL for my localhost running through xampp. Now I am using web sockets which asks for 'wss:' instead of 'ws:'. But when using 'wss', I am getting the following Error:
WebSocket connection to 'wss://192.168.1.5/?aswin' failed: WebSocket opening handshake was canceled
I am new to this, I don't know what's causing this issue.
Remember to change the port number to a one different to the one you used for not secure connections. Some browsers get confused if suddenly a port becomes secure or viceversa.
Remember to use the hostname indicated in the certificate to connect and not the IP.
If you are using a self-signed certificate, use it for HTTPS so you can see the dialog for accepting that certificate. When accessing via WSS:// there is not certificate acceptance dialog, it will just fail to connect.
Recently I setup SSL certificate for my website. Everything works good (using https) in Chrome and Mozilla Firefox but website do not open at all in Internet Explorer (IE) and Safari. Following (please check image URL) is the error I see when I try to open website.
I have set redirection to https from http in my .htaccess but I don't think this is the problem here.
SSL is properly set, I have checked with multiple online SSL checkers and SSL certificate includes www.website.com and website.com as well.
Other details of my server are
PHP: 5.5.29
Apache: Apache 2.4.6 CentOS
OpenSSL: OpenSSL 1.0.1e-fips 11 Feb 2013
SSL (Registered Stream Socket Transports): tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
TLS 1.2
Thanks in advance,
Either Enable TLS 1.0 in IE => internet options => advanced => security or downgrade to apache 2.2
I have an odd issue, and have managed to replicate this problem at different locations with different installs of Squid.
I will base my "problem" with my squid server at home.
Running Fedora 20 (32bit), with Squid 3.3.11, firewall and iptables uninstalled/disabled. The network is IPv4. I have a couple of Windows 7 machines with IE11, and 1x Windows 8.1 machine with IE11.
My problem is, on my Windows 8.1 machine with IPv6 protocols turned off, trying to load SSL based web pages (such as https://www.google.co.uk or https://www.facebook.com), the initial page load results in an error. Subsiquent loads either fail, part fail (IE main body of the site loads, but further SSL connections fail, such as image loads) or allow the page to load.). Oddly enough though, I do not re-call having a problem with my banks website! I would suggest that some websites seem to struggle more than others.
A friend of mine also managed to replicate the fault on a squid server he setup with Windows 8.1. He commented that using another browser such as Firefox, the problem is resolved so it seems limited to Windows 8.1, and IE11
Using Wireshark, during the failed attempts, towards the end my machine sends back a load of TCP RST commands.
However loading the same websites on my Windows 7 using IE11, or Windows XP with IE8, the problem does not appear, and until I moved to Windows 8.1, I had 0 problems with my Squid server.
My Squid Config is fairly basic as I just use it for filtering adverts using a block list using SquidGuard, although an experiment ruled out SquidGuard as being the problem when I removed the relevant line from squid.conf.
Thanks for reading and hope we can get to the bottom of this!
Copy of my squid config.
#squid normally listens to port 3128
http_port 3128
#Allow local machine
#acl manager proto cache_object
acl localhost src 192.168.20.6
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
http_access allow localhost
# Define Local network
acl localnet src 192.168.20.0/24
http_access allow localnet
#Redirect for SquidGuard
redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
# And finally deny all other access to this proxy
http_access deny all
I found it: Disable SPDY/3 Protokol in IE11 (Extras....)
It might be related to IE11 disabling RC4 and using TLS1.2 in the initial handshake, see http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-40-of-the-web-more-secure-while-making-sure-sites-continue-to-work.aspx. Unfortunatly lots of hosts still require RC4 and might fail if the client does not offer this cipher. Other hosts will also croak when using TLS1.2, e.g they just close the connection (like currently bmwi.de) or just drop the request (usually an older F5 BIG-IP load balancer in front).
I know from Chrome that it just retries a failed TLS 1.2 request immediately with TLS 1.1. Maybe IE11 does this different, e.g. does not retry immediately but only remembers the failure and work around it if the user retries. Or it behaves this way only when used with a proxy.
That you sometimes get the full page and sometimes only the html on the second request might be the case if the images are loaded from a different host name, e.g. images.whatever instead of www.whatever. In this case it gets at first a failed handshake with www.whatever and after a successful retry it with downgraded SSL it receives the HTML with the includes from images.whatever. It then will access images.whatever and will run in the same problems with SSL, so that the page stays w/o images until another retry.
If my theory is correct, you should see in wireshark in the initial failed connect an SSL Client Hello message with version TLS 1.2 and it should not have RC4 in the list of offered ciphers. On the second (successful) connect you should see RC4 in the cipher list of the Client Hello and maybe it will also use TLS 1.1 or oven TLS 1.0 instead of TLS 1.2.