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

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