I'm new to this package (so please be gentle ;)

Pound is assisting with my DR solution for outages on our internet links
(it will be extended to do some failover/fallback in the future - for
now it's a specific task).

 

I intend to put a pound server behind each of my firewalls - and have
them all talk to the (for now) one backend "production" server via
internal paths.

Some of the sites are non-http - and these are working perfectly...

My problem is (most likely an understanding of) HTTPS "redirections".

 

I was of the understanding that - since 2.5c - if I put the HTTPS
directive in the Service, then the certificate presented to the client
will be from the webserver (not the listener interfaces).

As a test, I've a self-signed testing ssl known as
"proxy.mydomain.com.au") as a "catchall" on the listening interface:

Eg:

Listen

                Address <eth0 interface static>

                Port 80

                Service

                                HeadRequire "host:
nonsslsite.mydomain.com.au"

                                Backend

                                                Address
nonsslsite.mydomain.com.au

                                                Port 80

                                End

                End

End

 

ListenHTTPS

            Address <ETH3 Static Address>

            Port 443

            Cert "/usr/local/etc/local.server.pem"

                Service

                        HeadRequire "Host: securesite.mydomain.com.au"

                        Backend

                                Address securesite.mydomain.com.au

                                Port 443

                                HTTPS

                        End

                End

End

 

It "sort of" works -the an SSL client request does gets presented with a
certificate and the site is SSL secured.

However, the certificate is signed "proxy.mydomain.com.au"  (ie. The
interfaces' cert) - where I would have expected the webmailservers'
webmail.mydomain.com.au.

The only way that I can see this to work would be to put the
"production" ssl cert on each of Listener interfaces.

Doesn't the 2.5c HTTPS directive care of this (essentially tunnelling
the ssl session) and thus not require me to publish all the production
certs on the pound server?

 

Appreciate any feedback.

Mike

Melbourne, Aust.


#####################################################################################
This e-mail message has been scanned for Viruses and Content and cleared 
by NetIQ MailMarshal
#####################################################################################

#####################################################################################
The information contained in this email communication may be confidential.
You should only read, disclose, re-transmit, copy, distribute, act in reliance
on or commercialise the information if you are authorised to do so. If you are
not
the intended recipient of this email communication, please notify us
immediately by
email to administrator(at)wridgways.com.au or reply by email direct to the
sender and 
then destroy any electronic or paper copy of this message. Any views expressed
in 
this email communication are those of the individual sender, except where the
sender 
specifically states them to be the views of Wridgways The Removalists.  Any
personal 
information in this email must be handled in accordance with the Privacy Act
1988 
(Cth). Wridgways The Removalists does not represent, warrant or guarantee that
the 
integrity of this communication has been maintained nor that the communication
is 
free of errors, virus or interference.
#####################################################################################

Hello,

Michael Weinbergs <Michael.Weinbergs(at)wridgways.com.au> (Di 01 Jun 2010
07:30:36 CEST):[...]
And I'm not sure if I understood the problem well ;-)
(…)
[...]

To decode your request pound needs to access the session contents. On behalf of
this it needs to present the client a valid certificate. This is not
possible w/o the accompaning key.

If it would present the backend servers cert, it would need the backend
servers key. If you install this on your pound, you'll be done.
[...]

Yes.
[...]

To have a real tunnel you do not need pound.  W/o access to the session
contents pound can't redirect your request properly, as it does not have
access to the request headers.

    Best regards from Dresden/Germany
    Viele Grüße aus Dresden
    Heiko Schlittermann[...]

Sorry - missed your reply for some reason.

I suspected that I'd probably have to put the servers' certificate on the pound
server and "push" the certificate to the client workstation.
Eg.

Normal: Client <------------ssl--------------->https server
Pound:  Client <----ssl---> Pound <----ssl---->https server

For now I will have to evaluate the risks of de-composing the client request,
then re-requesting it. 
This is potentially only as a DR backup solution (when we have a serious
outage).. but there is a level of security to consider.

My only other option (via pound) could be dropping the SSL backend as non-ssl
and assume all comms between pound and the host is "secure".

Thanks for confirming my suspicions.
I was hoping that pound was a "do it all"... ;o)
Mike

Hello,

Michael Weinbergs <Michael.Weinbergs(at)wridgways.com.au> (Di 01 Jun 2010
07:30:36 CEST):[...]
And I'm not sure if I understood the problem well ;-)
(
)
[...]

To decode your request pound needs to access the session contents. On behalf of
this it needs to present the client a valid certificate. This is not
possible w/o the accompaning key.

If it would present the backend servers cert, it would need the backend
servers key. If you install this on your pound, you'll be done.
[...]

Yes.
[...]

To have a real tunnel you do not need pound.  W/o access to the session
contents pound can't redirect your request properly, as it does not have
access to the request headers.

    Best regards from Dresden/Germany
    Viele GrÌße aus Dresden
    Heiko Schlittermann[...]

#####################################################################################
This e-mail message has been scanned for Viruses and Content and cleared 
by NetIQ MailMarshal
#####################################################################################

#####################################################################################
The information contained in this email communication may be confidential.
You should only read, disclose, re-transmit, copy, distribute, act in reliance
on or commercialise the information if you are authorised to do so. If you are
not
the intended recipient of this email communication, please notify us
immediately by
email to administrator(at)wridgways.com.au or reply by email direct to the
sender and 
then destroy any electronic or paper copy of this message. Any views expressed
in 
this email communication are those of the individual sender, except where the
sender 
specifically states them to be the views of Wridgways The Removalists.  Any
personal 
information in this email must be handled in accordance with the Privacy Act
1988 
(Cth). Wridgways The Removalists does not represent, warrant or guarantee that
the 
integrity of this communication has been maintained nor that the communication
is 
free of errors, virus or interference.
#####################################################################################