Hi Shawn,
> I've been tasked with making our websites more responsive, particularly > with TLS. I was given this video to watch: > > https://www.youtube.com/watch?v=0EB7zh_7UE4 > > This video specifically mentions haproxy, and I can see conversations > including Ilya on my mailing list history, which is really awesome. > > Thank you to everyone who has made possible all the technologies > mentioned in the video. > > I have some questions. > > I started out with haproxy 1.5.8 from source on CentOS 5. It quickly > became apparent that this system would not accommodate any of the cool > technologies that Ilya talked about. I don't follow, can you elaborate? I didn't watch the video, but Ilya's record size optimizations are in fact in 1.5 [1]. > I have upgraded one of our load > balancer machines to Ubuntu 14, so I would have a modern kernel and > openssl version. If I should have started with a different distribution > for additional capability, please let me know. I don't see anything wrong with it. > The video talks about SPDY/HTTP2. What I was hoping to find was that I > could enable spdy/2 on haproxy and have it use HTTP to the backend, but > it appears that this doesn't work ... Currently HAProxy doesn't support SPDY nor HTTP2. You can however configure NPN/ALPN accordingly and forward such content to a SPDY/HTTP2 capable backend, if that what you would like todo. Once HTTP2 is fully implemented, this will no longer be necessary. > What's the timeframe for HTTP2 support in haproxy? I don't think there is an ETA for this, but I may be wrong. You most certainly don't want to hold your breath until it is supported though. > Is it still required to build a script and a cronjob to update the ocsp > response for stapling, or is there a way to get haproxy itself to do this? No, if you need OCSP stapling, a script feeding HAProxy with uptodate OCSP informations is still needed (HAProxy internals lack for example a DNS resolver). Be advisted that OCSP stapling is slowly dying , check [2] and [3]. > I'm seeing fairly long "time to first byte", even with the new software > stack. I suspect you will have to analyze what actually happens on the wire with a sniffer. TLS inefficiencies are not the only reason for high TTFB's. > Ilya's video talks about dynamic TLS record sizes as a way to > reduce that time. What do I need to implement that? Can it be set in > haproxy, or do I need to make changes to the apache->tomcat backends? Take a look at [1]. I think you have more pressing performance issues to resolve in your setup though. > The openssl version I'm using is 1.0.1f-1ubuntu2.7 ... which apparently > does not support ALPN. What is the minimum version required for ALPN? ALPN is in OpenSSL 1.0.2. You can build from current 1.0.2 branches if ALPN is a strong requirement. But be aware that a "apt-get upgrade" will not update your setup when all hell breaks loose because of another OpenSSL vulnerability. > What would the procedure be if I want to compile another version of > openssl or boringssl in addition to the packaged version, and then use > it to compile haproxy? Check README, I added some instructions to statically link against openssl some time ago. You probably want to avoid boringssl aslong as you don't want to dive really deep into this crypto stuff. Boringssl as-is isn't really optimized for production, doesn't have OCSP stapling and only works with HAProxy 1.6. If you want get all alternative, I suggest to use latest LibreSSL, which is production ready and has some pretty nice improvements. It also works fine in HAProxy stable. > In order to ensure the links are correct, I also use SSL on the > backends, and I force RC4-MD5 so that is efficient as possible. Do you mean that the only reason for using SSL to connect to your backends is that the backend knows that the client connected in https? Then you are doing it for the wrong reason. You can use some specific headers to signal your backend that the frontent session is https [4], without actually encrypting the backend traffic. SSL Handshake on the backend side will kill performance if not very carefully optimized (keep-alive and SSL session caching). > What changes should I make to Apache and/or Tomcat to help with the > speed seen by the end user talking to haproxy? My suggestion to move ALPN, TLS record sizing, OCSP stapling at the end of your list and start with some basic things: - is keep-alive configured and correctly working on both front and backend? - do you really need SSL on the backend side? - is SSL session id caching properly configured *and properly working*? - are TLS tickets properly working? Regards, Lukas [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-tune.ssl.maxrecord [2] https://www.imperialviolet.org/2014/04/19/revchecking.html [3] https://wiki.mozilla.org/CA:ImprovingRevocation#OCSP_Stapling [4] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#7.3.4-ssl_fc
