Anyone using any Linux SSL proxies?
Howdy, I am wondering what folks are recommending/using these days for Linux SSL proxies? I need to build a linux box that basically acts as an SSL offloader would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, decrypt the SSL and then forward the request onto the webserver on port 80. DSR is not required. Any suggestions? Offlist replies would probably be more appropriate. Thank You in advance. Cheers, Mike
On Sat, 14 Mar 2009 21:56:26 PDT, Mike Lyon said:
Howdy,
I am wondering what folks are recommending/using these days for Linux SSL proxies? I need to build a linux box that basically acts as an SSL offloader would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, decrypt the SSL and then forward the request onto the webserver on port 80.
How much traffic? That would be a major consideration....
Valdis.Kletnieks@vt.edu wrote:
On Sat, 14 Mar 2009 21:56:26 PDT, Mike Lyon said:
Howdy,
I am wondering what folks are recommending/using these days for Linux SSL proxies? I need to build a linux box that basically acts as an SSL offloader would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, decrypt the SSL and then forward the request onto the webserver on port 80.
How much traffic? That would be a major consideration....
Check out http://www.apsis.ch/pound/ It would appear the magic search term on google is linux reverse ssl proxy .... I started searching for linux ssl proxy. That turned up a lot of stuff for wrapping plain text in encryption, not the other way around. :) And yes how much traffic is a major consideration. If a lot, then you would want to utilize an accelerator card supported by openssl.
Hello Mike: On 3/14/09 9:56 PM, "Mike Lyon" <mike.lyon@gmail.com> wrote:
Howdy,
I am wondering what folks are recommending/using these days for Linux SSL proxies? I need to build a linux box that basically acts as an SSL offloader would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, decrypt the SSL and then forward the request onto the webserver on port 80. DSR is not required.
Any suggestions?
Offlist replies would probably be more appropriate.
Thank You in advance.
Cheers, Mike
We use Apache with mod_security and mod_proxy to do this, although the application is more as an application layer firewall than an SSL offloader. It works well for lower traffic applications; I haven't tested it under the loads that are advertised by the hardware vendors you mentioned. Regards, Mike
On Sun, Mar 15, 2009, Michael K. Smith wrote:
We use Apache with mod_security and mod_proxy to do this, although the application is more as an application layer firewall than an SSL offloader. It works well for lower traffic applications; I haven't tested it under the loads that are advertised by the hardware vendors you mentioned.
Don't forget Squid and its various project forks. Adrian
On 15 Mar 2009, at 18:04, Michael K. Smith wrote:
We use Apache with mod_security and mod_proxy to do this, although the application is more as an application layer firewall than an SSL offloader. It works well for lower traffic applications; I haven't tested it under the loads that are advertised by the hardware vendors you mentioned.
hi If you have multiple back end worker web services, then you should investigate the mod_proxy_balancer module, as it gives you an extended feature set that helps in this regard. Best wishes Andy Davidson
On 2009-03-15, Mike Lyon <mike.lyon@gmail.com> wrote:
Howdy,
I am wondering what folks are recommending/using these days for Linux SSL proxies? I need to build a linux box that basically acts as an SSL offloader would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, decrypt the SSL and then forward the request onto the webserver on port 80.
Pound works ok for this. OpenBSD's relayd also supports this, and if it's on a machine in the network path in front of the backend server/s, there's a transparent mode that maintain the source IP address from the original connection.
DSR is not required.
Just as well, if you think about it... :-)
participants (7)
-
Adrian Chadd -
Andy Davidson -
Charles Wyble -
Michael K. Smith -
Mike Lyon -
Stuart Henderson -
Valdis.Kletnieks＠vt.edu