Thanks Eliezer/Amos for the hints. But I have some concerns here with SSLBUMP. Without proxy forwarding, SSL from client is terminated on squid and then squid does SSL with the orgin server. But when squid (with SSLBUMP enabled) connects internet via upstream proxy, it behaves different way. SSL is terminated on downstream proxy as usual. But the traffic flow between squid and the usptream becomes non-encrypted (we are not enabling SSL for parent cache_peer as we want traffic to be encrypted between downstream and upstream only for HTTPS). User won't care if http traffic between upstream and downstream goes unencrypted, but he will be concerned if even for HTTPs traffic goes unencrypted between upstream and downstream. Is it possible SQUID doing "HTTP CONNECT" to the upstream proxy when SSLBUMP is enabled on squid(i.e. on the downstream squid). We don't see any issues in case SSL bump is disabled as HTTPs is just getting relayed via downstream and upstream squids. Regards, Nipun Talukdar Bangalore India On Tue, Jun 12, 2012 at 5:28 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 12.06.2012 11:17, Eliezer Croitoru wrote: >> >> you can use two cache_peers fot he same host then name them >> differently with a "name=" and using a CONNECT method acl to allow >> access to the ssl encrypted upstream connection. >> > > Not quite. The downstream has terminated the TLS and Squid does not wrap > things in CONNECT. Squid uses "native" upstream connectivity which may be > over TLS or TCP links. > > The encrypted cache_peer link needs to be setup with the "ssl" flag and > possibly related settings. > > > >> Eliezer >> >> On 11/06/2012 16:00, nipun_mlist Assam wrote: >>> >>> Hi All, >>> >>> I have a configuration as given below: >>> >>> client<------> downstream-proxy<------> upstream-proxy<-------> cloud >>> >>> downstream proxy is always squid, while upstream proxy is either squid >>> or bluecoat. >>> When SSL termination enabled on downstream proxy, I noticed traffic >>> between down-stream and upstream-proxy is not encrypted. That results >>> in failures when upstream proxy is bluecoat. It returns "400 Bad >>> request" error. > > > This is a mis-configuration and possibly a bug in BlueCoat. > > * Bug in the BlueCoat in that it is not accepting https:// over > non-encrypted links. there are clients which need to send such and have the > proxy encrypt. > > * mis-configuration in that HTTPS specification require https:// URL to be > sent over TLS encrypted links. You should have the "ssl" flag on the > downstream cache_peer configuration to ensure TLS on the link between > downstream and upstream. > > > Amos > -- Regards, Nipun
