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.
