Hi Amos, again thanks for your quick response. I've tried to take in what you wrote and try it out... >The handing of CONNECT and ssl-bump are a bit broken when this mode >change takes place internally to Squid. I have just days ago added >changes that look like fixing CONNECT, these will be in 3.1.12. But >ssl-bump remains broken. At first instance I did not understand what CONNECT has to do with anything since in the access.log I can only see GET messages such as this one: 1300706936.020 142 9.148.16.86 TCP_MISS/503 4274 GET https://9.148.26.247:8443/ - DIRECT/9.148.26.247 text/html However when I added to my config: acl SSL_ports port 443 http_access deny CONNECT !SSL_ports I got this instead: 1300706666.356 0 9.148.16.86 TCP_DENIED/403 3662 CONNECT 9.148.26.247:8443 - NONE/- text/html This did not affect any other site that I tried to access, only the site I ran on the tomcat. So I guess it goes from CONNECT to GET somehow, but this happens by squid before I even see it, right? This actually brings me to more troubling question: Why should the site I put up with tomcat be any different the accessing an https site of my bank for instance. My bank's portal might as well be run on tomcat as well. What is the difference. If I can understand that, maybe I can bypass the problem. >I think this should work for passing requests to the tomcat: > cache_peer parent 443 0 originserver ssl sslflags=DONT_VERIFY_PEER I tried adding this line, it seemed to have made no impact. However, when I added after my "ssl_bump allow all" line the following line: sslproxy_flags DONT_VERIFY_PEER That did eliminate the "Error negotiating SSL connection" problem in squid but the problem was transferred down to my icap service where by I got: "socket read from tap client: Connection reset by peer. TAP client disconnected" So I'm guessing this happened because ssl-bump did not work and I got encrypted stream of data instead of the unencrypted html, right? >Using ssl-bump Squid will pass the tomcat requests with absolute https:// URLs. >... >Once the requests are getting there you may hit a problem with those >ssl-bump absolute URLs. The Tomcat app might need tweaking to accept >them. Or a re-writer may be needed to strip "https://domain"; of the >front of those particular ones. First I must admit that I don't understand this :( You say ssl-bump Squid will pass the tomcat requests with absolute https:// URLs. This is as opposed to what? What happens with other https sites? Second, what do you mean by re-writer to strip "https://domain";, do you have an example for such as re-writer? is there another scenario where this is needed? Again, many thanks, I realize the number of questions is just growing... hopefully this trend will reverse itself soon :) Thanks, Ariel. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-as-forward-proxy-for-portal-run-on-tomcat-tp3383986p3392883.html Sent from the Squid - Users mailing list archive at Nabble.com.
