Live data from Hacker News

SSL session caching in nginx

hezmatt.org

1–10 of 18 posts

Re: SSL session caching in nginx

#3
Very cool post - not only is it informative, but you've taken the "oh-so-rare" extra step of actually coding up a solution to what you're talking about - rather than taking the easier approach and just telling others what they're doing wrong but presenting no practical alternatives. Kudos!

Re: SSL session caching in nginx

#4
post #2

I had to check several times I hadn't accidentally hit zoom a few times. Sounds useful, but how many visitors do you need to have for this to be worth doing?

The number of visitors you have is irrelevant.

If you have any visitors you are doing them a huge disservice if you do not have SSL session caching.

You would use external SSL caching like this if you have more than one SSL termination point (typically a webserver like nginx/Apache) behind a load-balancer.

Re: SSL session caching in nginx

#5
You'll usually run out of entropy before cpu usage becomes relevant with SSL processing, I've seen old versions of apache hang with little or no entropy to process SSL connections. I recommend some sort of RNG or a poor mans software version such as http://www.issihosts.com/haveged/

Re: SSL session caching in nginx

#6
Crypto hardware acceleration is commodity. I believe that Broadcom sold the chips for There surely are reasons not to integrate at the load balancer, but they're not because the load balancer will melt down.

Re: SSL session caching in nginx

#7
One downside of this approach (without some funky iptables/networking-fu) is that you loose the source IP from the original request. Adding headers like X-Forwarded-For only works after the request has been decrypted, so all the traffic will appear to source from the load balancer, which can present its own issues.

IMO (and I believe Google agrees - http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...) the advantages of terminating SSL at the load balancer outweigh the horizontal scalability of this approach, at least in most cases.

Re: SSL session caching in nginx

#9

One downside of this approach (without some funky iptables/networking-fu) is that you loose the source IP from the original request. Adding headers like X-Forwarded-For only works after the request has been decrypted, so all the traffic will appear to source from the load balancer, which can present its own issues. IMO (and I believe Google agrees - http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht... ) th…

Transparent load balancers exist and don't have the issues you are talking about.

Re: SSL session caching in nginx

#10

One downside of this approach (without some funky iptables/networking-fu) is that you loose the source IP from the original request. Adding headers like X-Forwarded-For only works after the request has been decrypted, so all the traffic will appear to source from the load balancer, which can present its own issues. IMO (and I believe Google agrees - http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht... ) th…

Transparent load balancers exist and don't have the issues you are talking about.

Hardware or software? There's some hacks with TPROXY/HAproxy I've seen that would do the transparent proxy but the setup seems like more trouble than it's worth.
Post reply on HN