https ?
 

Will this web server act as a reverse proxy for multiple https backend servers?
Is there an example configaround if it does?

Thanks
BC

Hmm...Is it possible or practical to proxy HTTPS content at all in the application proxy level?

I know for sure a load balancer could do a HTTPS cluster at the simple TCP socket level just not sure about the actuall HTTPS connection/negotiation level.

BC, curious at how you plan to deploy your HTTP servers and HTTPS servers behind the proxy. Care to elaborate?

I'm only a lsws user so I will also be inerested to see what they, the developers, have to say about this. You learn something new everyday. =)

well I use a ip based virtual host scenario with https on apache as the back end and currently use squid as the reverse proxy. I am looking to go for a different solution to help with some issues I am having. Its not really about load balanceing its about conservation of hardware. Essentially all of the websites are on the same box they are just on different virtual IP's (and ports)

BC

So you want to do this right?

WAN --> PROXY (cache) --> HTTP + HTTPS Backend

Usually, HTTPS content are secure, time sensitive, so instead of proxying, I have done the following myself in the past to reduce overhead.

WAN --> PROXY (cache) --> HTTP Backend

Plus one of the following:

1) WAN --> Have my router/firewall forward all HTTPS port content straight to --> HTTPS BACKEND bypassing the proxy altogether to reduce latency.

2) Or WAN --> Dedicated HTTPS hardware based compressor which interecept all HTTPS port action --> Proxy (cache) --> HTTP Backend.

This is assuming you do not need to HTTPS cached content. Do you need to HTTPS cached content?

No I do not need the https content cached. I am really only using the reverse proxy as a director for the https. My firewall is not capable of redirecting ports based on names (if you know one let me know). I have limited hardware so I need to run multiple ssl vhosts. The only way I am aware that I can do this is to set a reverse proxy in font of it to interpret the host header and route it to the backend box based on an ip/port combination. Squid does this job for me now, but I would like to switch solutions for various reasons.
I know Apache does it also, but I like the web interface LSWS has.


BC

You can host multiple ssl virtual hosts with one litespeed web server without using a reverse proxy. Actually, I think Apache can do that as well, so I am confused a little bit by the reason why you need a squid reverse proxy in front of apache, especially when all the servers are on the same machine. Is that because each Apache instance runs as a different user for each virtual host for security reason?

Please correct me if I was wrong, in your case, squid already decrypts ssl connection and forwards decrypted content to backend apache based on the host header.

Litespeed can do the same as well.

That is true about the multiple ssl hosts in apache. My problem occurs because I am natting 1 real address to multiple internals. Because of the chicken and egg scenario with ssl I cannot do named virtuals on the apache server with ssl (only ip based virtuals) so I need a method that will forward the request based on the host headers. The method I came up with was to use squid in reverse mode.

So are you telling me I can use your webserver and have multiple named ssl virtuals? If I can you have an instant sale.

I need this because I host some e-commerce sites for different customers. they each have their own ssl cert so a wildcard cert will not work.

Thanks

I am confused. :?
Are you talking about have squid listen on port 443 only and dispatch ssl requests to NATed internal address based on the host header in the encrypted request header? or squid listen on multiple ports, each port is associated with one backend virtual host?

If it is former, I must be missing something because I think it is impossible for squid to decrypt the request with the right ssl private key in order to know the content of host header.

If it is later, why not have the backend Apache listen on those ports directly.

A unique IP:PORT combination must be assigned for each SSL certificate. It is impossible to do name based SSL virtual hosting as SSL handshake is the first step and host header is not available yet.
With one IP, you can use different port for different SSL certificate though.

I guess you are telling me I am not doing what I am doing so I am attaching (with some stuff removed) a commented squid conf that shows the ssl options. I am sorry that all of this has become so difficult. Please notice the vhosts options.

Usage: [ip:]port cert=certificate.pem [key=key.pem] [options...]

The socket address where Squid will listen for HTTPS client
requests.

This is really only useful for situations where you are running
squid in accelerator mode and you want to do the SSL work at the
accelerator level.

You may specify multiple socket addresses on multiple lines,
each with their own SSL certificate and/or options.

Options:

defaultsite= The name of the https site presented on
this port

protocol= Protocol to reconstruct accelerated requests
with. Defaults to https

cert= Path to SSL certificate (PEM format)

key= Path to SSL private key file (PEM format)
if not specified, the certificate file is
assumed to be a combined certificate and
key file

version= The version of SSL/TLS supported
1 automatic (default)
2 SSLv2 only
3 SSLv3 only
4 TLSv1 only

cipher= Colon separated list of supported ciphers

options= Varions SSL engine options. The most important
being:
NO_SSLv2 Disallow the use of SSLv2
NO_SSLv3 Disallow the use of SSLv3
NO_TLSv1 Disallow the use of TLSv1
SINGLE_DH_USE Always create a new key when using
temporary/ephemeral DH key exchanges
See src/ssl_support.c or OpenSSL SSL_CTX_set_options
documentation for a complete list of options

clientca= File containing the list of CAs to use when
requesting a client certificate

cafile= File containing additional CA certificates to
use when verifying client certificates. If unset
clientca will be used

capath= Directory containing additional CA certificates
to use when verifying client certificates

dhparams= File containing DH parameters for temporary/ephemeral
DH key exchanges

sslflags= Various flags modifying the use of SSL:
DELAYED_AUTH
Don't request client certificates
immediately, but wait until acl processing
requires a certificate
NO_DEFAULT_CA
Don't use the default CA list built in
to OpenSSL

accel Accelerator mode. Also set implicit by the other
accelerator directives

vhost Accelerator mode using Host header for virtual
domain support

vport Accelerator with IP based virtual host support

vport=NN As above, but uses specified port number rather
than the https_port number

Thanks for your guys help. I found my solution. ssl accelerator hardware appliance. unfortunatly more $$ but ultimatly a cleaner solution.