On Fri, Jul 18, 2008 at 03:30:58PM +0530, Karandeep Malik wrote: > I am using a standard proxy configuration. Can I use same port for > http and https ? Yes, the two are handled quite differently but so long as the client (web browser) knows what it's doing there's no problem. > When I do use the forward proxy mode i.e. tunneling of client > requests to server, I see wireshark actually capturing plain http > packets from my proxy server to the main server instead of > SSL/TLS packets. For HTTP connections, the client (with a proxy configured) will connect to the proxy, and then issue the request in much the same way as it does for a regular direct-to-server connection. The only difference is that it specifies the full hostname of the request, rather than just the path. So, you get something like: GET http://www.google.com/ HTTP/1.0 User-Agent: blah and then a blank line to indicate the end of the request (a little different if it's posting data, but you get the idea). When a browser is configured to use a HTTP proxy for SSL connections, it's quite different: it merely tells the proxy what host to connect to. This request looks like this: CONNECT www.google.com:443 HTTP/1.0 The proxy then tries to connect, and then sends a response back to the client saying it's connected. From that point, the proxy is merely shuffling bits back and forth between the client and the origin server. This will firstly be an SSL handshake, and then it will be a regular HTTP request (albeit encrypted) as if the browser was talking directly to the origin server (which, effectively, it is). > This is my configuration:- > > http_port 8080 > > acl destall dst 0.0.0.0/0.0.0.0 If you're intending to match "anything", I think it's better to use "src 0.0.0.0/0.0.0.0" or similar, because the "dst" ACL causes squid to do a DNS lookup of the domain name before permitting it. I think the "src" ACL doesn't force a DNS lookup. http://www.visolve.com/squid/squid26/accesscontrols.php#dst Mind you, this probably makes no difference if you don't have any peer caches to send requests to. > http_access allow localweb auth > http_access allow localhost auth > http_access allow sangram auth > http_access allow destall auth The line above will allow all kinds of access to anyone who has authenticated, which might not be what you're intending. i.e. processing of the http_access ACLs will stop here with an "allow" if the user is authenticated, permitting them to e.g. CONNECT to any port they want, rather than just your SSL_ports, or access the cache_object protocol. Or in other words, the following ACEs only apply to unauthenticated users. If this is what you're after, then no worries. > http_access allow manager localhost auth > http_access deny manager > http_access deny !Safe_ports > http_access allow CONNECT > http_access deny CONNECT !SSL_ports The above two lines permit CONNECT to any port at all, and then deny it to those which aren't SSL_ports. However that second line will never be used, because the ACLs are processed in order until a match is found. Better to write as: http_access deny CONNECT !SSL_ports http_access allow CONNECT Or simply omit the "allow CONNECT" line, since the default when processing reaches the end of an ACL is the opposite of whatever the last action was. I prefer to explicitly put the "allow all" or "deny all" because I find it easier to read. It could also be written as: http_access allow CONNECT SSL_ports with or without a "deny CONNECT" after it. > Am I missing sonmething ??? I'm not sure, I think your ACLs may not be doing quite what you want them to but I don't see any particular reason it'd be somehow "converting" HTTPS requests into HTTP. The proxy can't really do that, because the browser would end up very very confused. Can you describe in more detail what you're seeing, and confirm that the browser is configured to use your server for HTTPS traffic? Maybe also capture traffic between the browser and your proxy and see if the browser is doing what it's meant to.
