Re: [squid-users] Same port for http and https ??

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.
Received on Fri Jul 18 2008 - 11:34:30 MDT