Michael Alger wrote:
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.
Same goes for the "deny !Safe_Ports" entry. Will never match for local
traffic, and is useless for blocking remote attacks, since almost next
line is "deny all" anyway.
Better to use this sequence:
deny !Safe_ports
deny CONNECT !SSL_Ports
.. other config ...
deny all
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.
Amos
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE8
