well... the performance loss would be high, I know that from other applications. Also, each server (there are 50) would need it's own 'proxy' that probably is a little impractical. We're moving a lot of data... machines that cache run out of memory to actually cache in no time. caching would only work with little bits of data. On 12/03/2015 10:32 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Jakob Bohm >> Sent: Thursday, December 03, 2015 21:11 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] explicitly including other ciphers. >> >> On 04/12/2015 03:03, Michael Wojcik wrote: >>> So rather than connecting directly to Apache, how about connecting to a >> TLS proxy like stunnel, which would then connect to Apache over vanilla >> HTTP. Configure Apache to only bind to loopback addresses (127/8 and/or >> ::1), so no one can bypass the proxy. >>> >> Wouldn't that extra hop via stunnel cost performance >> (noting that Ron is apparently running at faster than >> gigabit speed). > > Yes, but depending on the actual application behavior, it might be negligible compared to the cost of certificate validation and the like. I don't know enough about the situation to guess whether the impact would be an issue, so I thought I'd propose this as one possible alternative. > > The application might even be such that a caching proxy could be used in front of Apache for a performance gain - for example if the same content is re-read frequently and the HTTP cache control mechanisms allow it to be usefully cached. >
