Did request come via SSL?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Did request come via SSL?

Grant McLean-2
Hi All

I'm setting up Squid for the first time, in accelerator mode in front of
an Apache/mod_perl app.  Squid is listening on both port 80 (HTTP) and
port 443 (HTTPS).  The basics (including SSL cert stuff) are working but
I've hit a bit of a road block.

Is there any way to tell that a particular request came in on the SSL
port?

There are some sections of our site that should only be accessed via SSL
and in general, the rest of the site should only be accessed via HTTP.
With Apache, I could achieve this using mod_rewrite to detect requests
that came in on the 'wrong' port and issue redirects for the same path
on the http or https url as appropriate.

Now that I have Squid in front of Apache, there doesn't appear to be
anything in any of the headers that tells me the request came over the
secure port.  Is there some option I can enable to add a header?

It would be even better if I could achieve the redirect magic using a
squid redirector script, but once again, there doesn't seem to be
sufficient information passed to the redirector for it to know if the
request came over a secure channel.

Strangely, when I was playing around with this on Friday, I could have
sworn that the redirector script was receiving URLs that started with
'https', but I can't reproduce that today so I must have imagined it :-)

Does anyone have any suggestions.

Thanks
Grant

Reply | Threaded
Open this post in threaded view
|

Re: Did request come via SSL?

Henrik Nordström
tis 2007-05-22 klockan 10:02 +1200 skrev Grant McLean:
> Hi All
>
> I'm setting up Squid for the first time, in accelerator mode in front of
> an Apache/mod_perl app.  Squid is listening on both port 80 (HTTP) and
> port 443 (HTTPS).  The basics (including SSL cert stuff) are working but
> I've hit a bit of a road block.
>
> Is there any way to tell that a particular request came in on the SSL
> port?

Yes.

To have this forwarded to the backend server see the front-end-https
cache_peer option.

To detect this within Squid see the myport acl, or alternatively the
proto acl (but see below).

> It would be even better if I could achieve the redirect magic using a
> squid redirector script, but once again, there doesn't seem to be
> sufficient information passed to the redirector for it to know if the
> request came over a secure channel.

Well, for browsers you have the protocol. https vs http.

But technically an http client could send a fully qualified https:// URI
without using SSL if they insist on it so it's not a 100% indication
that the request was received encrypted on an https_port.

> Strangely, when I was playing around with this on Friday, I could have
> sworn that the redirector script was receiving URLs that started with
> 'https', but I can't reproduce that today so I must have imagined it :-)

It does.. at least unless

a) You tell your https_port to use http as the protocol identified.

or

b) If you are using Squid-2.5 and not the currently supported 2.6
version. The https_port support in Squid-2.5 isn't very friendly..

Regards
Henri

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Did request come via SSL?

Jeff Tharp
Here's how I tackled this issue...I set up two virtual hosts in Apache,
then did the following in my Squid.conf:

acl httpreq port 80
acl httpsreq port 443

cache_peer 127.0.0.1 parent 8100 0 no-query originserver login=PASS
name=nonsecure
cache_peer 127.0.0.1 parent 8101 0 no-query originserver login=PASS
name=secure

cache_peer_access nonsecure allow httpreq
cache_peer_access nonsecure deny httpsreq
cache_peer_access secure allow httpsreq
cache_peer_access secure deny httpreq

http_port       80 vhost
https_port X.X.X.X:443 cert=/etc/squid/ssl/castest.crt
key=/etc/squid/ssl/castest.key defaultsite=castest.esri.com

etc...
(where X.X.X.X is the real IP used on the box for this particular SSL
site)

Apache config bits:
Listen 8100
Listen 8101
NameVirtualHost *:8100
NameVirtualHost *:8101

In this case, Apache runs on the same box as Squid, but on port 8100
(non-secure virtual host) and 8101 (secure virtual host).  I then have
Apache also configured as a reverse proxy and use name-based virtual
hosts on both ports.  In this manner, I have several sites hosted
through one set of reverse proxies and each site can have a different
config for SSL versus non-SSL portions of the site.

As to why we use both Squid and Apache for our reverse proxy, I prefer
using Squid for caching, but I use Apache for doing any mod_proxy or
mod_rewrite mojo and to filter requests through ModSecurity.

Jeff Tharp
System Administrator
ESRI, Redlands, CA
http://www.esri.com

> -----Original Message-----
> From: Henrik Nordstrom [mailto:[hidden email]]
> Sent: Monday, May 21, 2007 3:30 PM
> To: Grant McLean
> Cc: [hidden email]
> Subject: Re: [squid-users] Did request come via SSL?
>
> tis 2007-05-22 klockan 10:02 +1200 skrev Grant McLean:
> > Hi All
> >
> > I'm setting up Squid for the first time, in accelerator
> mode in front of
> > an Apache/mod_perl app.  Squid is listening on both port 80
> (HTTP) and
> > port 443 (HTTPS).  The basics (including SSL cert stuff)
> are working but
> > I've hit a bit of a road block.
> >
> > Is there any way to tell that a particular request came in
> on the SSL
> > port?
>
> Yes.
>
> To have this forwarded to the backend server see the front-end-https
> cache_peer option.
>
> To detect this within Squid see the myport acl, or alternatively the
> proto acl (but see below).
>
> > It would be even better if I could achieve the redirect
> magic using a
> > squid redirector script, but once again, there doesn't seem to be
> > sufficient information passed to the redirector for it to
> know if the
> > request came over a secure channel.
>
> Well, for browsers you have the protocol. https vs http.
>
> But technically an http client could send a fully qualified
> https:// URI
> without using SSL if they insist on it so it's not a 100% indication
> that the request was received encrypted on an https_port.
>
> > Strangely, when I was playing around with this on Friday, I
> could have
> > sworn that the redirector script was receiving URLs that
> started with
> > 'https', but I can't reproduce that today so I must have
> imagined it :-)
>
> It does.. at least unless
>
> a) You tell your https_port to use http as the protocol identified.
>
> or
>
> b) If you are using Squid-2.5 and not the currently supported 2.6
> version. The https_port support in Squid-2.5 isn't very friendly..
>
> Regards
> Henri
>
Reply | Threaded
Open this post in threaded view
|

Re: Did request come via SSL?

Grant McLean-2
In reply to this post by Henrik Nordström
Hi Henrik

Thanks very much for your prompt reply which got me onto the right
track.


On Tue, 2007-05-22 at 00:30 +0200, Henrik Nordstrom wrote:

> tis 2007-05-22 klockan 10:02 +1200 skrev Grant McLean:
> > Hi All
> >
> > I'm setting up Squid for the first time, in accelerator mode in front of
> > an Apache/mod_perl app.  Squid is listening on both port 80 (HTTP) and
> > port 443 (HTTPS).  The basics (including SSL cert stuff) are working but
> > I've hit a bit of a road block.
> >
> > Is there any way to tell that a particular request came in on the SSL
> > port?
>
> Yes.
>
> To have this forwarded to the backend server see the front-end-https
> cache_peer option.
>
> To detect this within Squid see the myport acl, or alternatively the
> proto acl (but see below).

This response left me quite confused until I realised my main problem
was that I was using the packaged binary of Squid in Debian Sarge
(2.59).  Things have obviously changed a lot since that version - the
most obvious thing being that accelerator mode is now configured via
cache_peer rather than httpd_accel_host.

I had to rebuild the package to enable SSL support so it was just as
easy to build the Etch package (2.65) instead.  With that in place and
applying your advice, I now have my redirector processes happily
detecting insecure requests for secure data and issuing redirects.

Thanks again
Grant