[squid-users] Re: squid as forward proxy for portal run on tomcat

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.