On 21/03/11 21:19, arielf wrote:
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?
Yes. That GET is ssl-bump happening on the CONNECT.
It "unwraps" the CONNECT to get the HTTPS, then decrypts the 'S' (SSL)
to find the HTTP inside. Which turns out to be a "GET /" in this case.
The above config was nearly right. You just needed:
acl SSL_ports port 443 8443
with that ACL, you should see ssl-bump working still but only for HTTPS
sites on port 443 or 8443.
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.
In this case the port number is the only real difference.
The second difference is what Squid does with it when decrypted. In the
banks case you are connecting out to the banks server using DNS.
In the tomcat case you are/were connecting to it via a configured
cache_peer link.
At least I thought so, the below sslproxy_flags result shows
otherwise. For that setting to work Squid is going DIRECT.
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?
I'm not sure what that TAP message is about. I think it may be related
to the ssl-bump being turned off when you logged CONNECT.
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 :(
Okay no problem. Lets skip it until we are sure its actually needed then.
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 :)
Sorry. My fault for mentioning too many options.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.11
Beta testers wanted for 3.2.0.5
