On 05/16/2016 04:47 AM, admin wrote: >>> acl blocked_https ssl::server_name "/etc/squid/urls/block-url" >>> https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 >>> connection-auth=off cert=/etc/squid/squidCA.pem >>> acl step1 at_step SslBump1 >>> ssl_bump peek step1 >>> ssl_bump terminate blocked_https >>> >>> It works. >> Obviously not. There is no instruction what to do other than terminate. >> Squid is left to other circumstances to decide what is needed... > it works! :) if you have the opportunity to check on the virtual machine Your configuration works by accident. You should not expect it to work across Squid upgrades, for example. It may continue to work or may stop working. To fix the problem, be explicit regarding what to do when the terminate rule does not match: ssl_bump peek step1 ssl_bump terminate blocked_https ssl_bump splice all > http_access deny users_no_inet > Why, if access is > allowed everything works, and if the ban on access to HTTP, you must > first see a message stating that my certificate has not been able to > match, and then later ERR_ACCESS_DENIED. When access is allowed, Squid works as a TCP relay. Client bytes are sent to the origin server. Server bytes are sent to the client. No errors or certificates to worry about. When access is prohibited via http_access deny, Squid needs to send an "Access Denied" error response to the user (this is how http_access works). To send that error to the user, Squid needs to establish a secure connection with the user (this is how HTTPS works). To do that, Squid has to use its own SSL certificate (this is how SSL works). If you want to use a splice-or-terminate design, do not deny access via http_access. Limit yourself to "ssl_bump terminate" rules. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
