Further to this:
I have ssl-bump setup on port 8080.
If I remove ssl-bump squid works just like I mentioned in my earlier
e-mail.
> curl -ix 192.168.1.1:8080 https://google.com
HTTP/1.1 307 Temporary Redirect
Server: squid/4.3
Mime-Version: 1.0
Date: Tue, 16 Oct 2018 12:01:41 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 0
Location: http://192.168.1.1/blocked.html
X-Squid-Error: 403 Access Denied
X-Cache: MISS from somehost
X-Cache-Lookup: NONE from somehost:8080
Connection: keep-alive
curl: (56) Received HTTP code 307 from proxy after CONNECT
So then I reactivated ssl-bump and added this at top of squid.conf:
http_port 8080 ssl-bump ...
ssl_bump splice all
i.e. http_port has ssl-bump but squid is not really supposed to bump
at all.
But squid still goes ahead and replies with 200 Connection
established.
So it means that this is a bug in ssl-bump implementation.
It seems that current algorithm for ssl-bump is:
1) Browser sends CONNECT request
2) Squid sends status 200 Connection Established
3) Check ACL
4) If denied, bump the connection with squid certificate
5) If allowed, go ahead with tunneling / bumping as applicable
In my opinion correct flow should be like this:
1) Browser sends CONNECT request
2) Check ACL
3) If denied, return with 307 (or 302)
4) If allowed, go ahead with tunneling / bumping as applicable
Please test / check,
Thank you,
Amish.
On 16/10/18 5:05 PM, Amish wrote:
Hello
I have this simplified ACL in squid.conf
acl denyit src all
deny_info http://192.168.1.1/blocked.html
denyit
http_access deny denyit
The purpose is to block everything and redirect to http://192.168.1.1/blocked.html
It works fine with http (non-secure) CONNECT request ...
> curl -ix 192.168.1.1:8080 http://google.com
HTTP/1.1 302 Found
Server: squid/4.3
Mime-Version: 1.0
Date: Tue, 16 Oct 2018 11:02:05 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 0
Location: http://192.168.1.1/blocked.html
X-Squid-Error: 403 Access Denied
X-Cache: MISS from somehost
X-Cache-Lookup: NONE from somehost:8080
Connection: keep-alive
... but gives certificate error with https CONNECT request.
> curl -ix 192.168.1.1:8080 https://google.com
HTTP/1.1 200 Connection established
curl: (60) SSL certificate problem: self signed certificate in
certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore
could not
establish a secure connection to it. To learn more about this
situation and
how to fix it, please visit the web page mentioned above.
I believe this is because squid first gives 200 status and hence
browser thinks connection is established expects Google's
certificate.
Can squid not return with 302/307 on CONNECT HTTPs requests for
deny_info?
Like instead of HTTP/1.1 200 Connection established - it returns:
HTTP/1.1 307 Redirect
Location: http://192.168.1.1/blocked.html
(...)
RFC 7231 https://tools.ietf.org/html/rfc7231#section-4.3.6
states that:
Any response other than a successful response
indicates that the tunnel has not yet been formed and that the
connection remains governed by HTTP.
which means HTTP/1.1 307 Redirect should make browser treat
connection as HTTP and hopefully also follow Location.
Any idea? Or any other workaround (except importing squid
certificate)
Thanks and regards,
Amish
|
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users