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

From: arielf <arielf_at_il.ibm.com>
Date: Mon, 21 Mar 2011 08:58:58 -0700 (PDT)

Hi Amos, thanks again for the quick response.
I need some clarification on some of your answers

>>> 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.

yes, thanks, when I added this indeed CONNECT passes through. So what you
are saying is the all https sites pass through CONNECT only they were on
port 443, thus bumped and I saw only the GET, right?

> 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.

This was even before I tried the cache_peer and it didn't seem to work in
any case.
at least not what I put down:
cache_peer 9.148.26.247 parent 8443 0 originserver ssl
sslflags=DONT_VERIFY_PEER
This didn't seem to make an impact, so I commented it out.
Thus I'm still at a loss why this specific site should be different than any
other https site now that I fixed the CONNECT port issue. CONNECT is
configured for both 443 and 8443 and no cache peer is configured.

Only two questions this time... I'm trying to break the trend :)

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-tp3383986p3393945.html
Sent from the Squid - Users mailing list archive at Nabble.com.
Received on Mon Mar 21 2011 - 15:59:01 MDT

This archive was generated by hypermail 2.2.0 : Tue Mar 22 2011 - 12:00:02 MDT