haproxy自1.5版开始引入了原生SSL支持，因此可以用来做SSL Termination或者SSL
Offload。但在做https负载的时候，有一些点需要注意一下，以下文字可能前后逻辑性不太强，是因为我本人对加密算法这些东西也是一头雾水，只是将我看到的一些文档转述一下，尽我所能写明白一些吧。
![]()
![]()
![]()
![]()
![]()
一、HTTPS慢在哪里？
使用https会明显感觉网站响应变慢了，为什么？慢在哪里了呢？
第一个因素，是初始化SSL连接消耗了时间。
在开始web页面内容下载之前，对于一个SSL session，用户的浏览器会与web
server间有至少4个RTT用来协商加密算法，交换公钥。
而根据Yslow的前段优化建议，大的站点可能有多个域名用来分散图片,css,js等文件，一边浏览器并行下载这些文件，使用了https以后，则针对每一个域名，都需要进行上边所说的4个RTT协商！
能不慢吗？这个部分是有一些方法可以进行优化的，后边细说。
第二个因素，是OCSP和CRL
网站SSL证书一般是由一些证书机构(CA)签发的，这些证书由于某些原因，可能丢失了或者被盗了，因此需要对这些有问题的证书进行吊销。证书机构会有Certificate
Revocation List
(CRL)用于保存哪些证书被吊销了，当用户浏览一个使用https的网站时，浏览器会去CA的站点下载CRL用于比对或者使用Online
Certificate Status Protocol (OCSP)去检查。
问题在于这些CA的站点往往没有针对全球用户进行地域优化，所以导致用户访问CA的站点是非常慢的。例如最大的CA，Verisign的平均OCSP响应时间在300ms，这也就意味着，如果你使用Verisign签发的证书，则用户访问你的站点，需要多花300ms！这个数字已经很成问题了。
这个部分，作为用户的我们是没有办法的，只能在买证书之前，尽可能的找OCSP响应快的CA，例如 Globalsign
二、如何加速SSL
1. 选用带有SSL加速指令的CPU和针对这些CPU优化的openssl版本
Intel新的xeon
CPU中集成了一些指令，专门针对ssl加密进行了优化。所有选择硬件的时候，尽可能选择这样的CPU。另外，openssl有很多版本，其中1.0.2这个分支，专门针对Intel这些指令做了优化，所以要使用这个分支，才能最大化CPU的功能，两者相辅相成。
2. 简化cipher suite
openssl支持很多种加密算法，但其中一些是过时的，另外一些是不安全的，还有一些是非常耗CPU的。因此，我们要简化一下cipher
suite，这个部分我不懂，所以找了mozilla的一个在线工具，可以生成只支持比较新的浏览器的cipher
suite，至于坚守Windows XP,使用IE6的用户，就算了吧。
工具地址: https://mozilla.github.io/server-side-tls/ssl-config-generator/
该工具也可以生成haproxy，apache，nginx，Lighttpd ,AWS ELB的配置文件。
下边是使用该工具生成的haproxy的配置文件，
-----------------------------------------------------
使用openssl查看一下具体支持的算法:
3. 开启KeepAlive
前边说了每个SSL
session要进行至少4个RTT来初始化，所以我们不想与同一server所建立的多个connection都走一遍这个过程，因此开启KeepAlive非常必要。
4. 提供中间证书
在SSL初始化握手的时候，需要校验证书是被受信CA所签发的。而大的CA一般不会直接用自己的根证书给用户签名，而是生成下一级证书或者更多级证书用于给用户签名。例如会给每个授权经销商一个证书，经销商可以用自己的证书给用户签名。这就是所谓SSL证书链，经销商使用的证书被称为"中间证书"。
如果浏览器不能识别“中间证书”，就会沿着证书链一级级去验证，直到验证成功，这个过程中，SSL握手会一直处于block状态。所以必须提供完整的证书链文件，以避免这种情况。这个可以找你的证书经销商要。
例子:
bind 10.20.30.40:443 ssl
crt /etc/haproxy/pem/server.pem ca-file
/etc/haproxy/pem/client-chain.pem verify optional crt-ignore-err
all crl-file /etc/haproxy/crl/haproxy.pem
5. 缓存静态文件
使用了https以后，默认浏览器不会对进过加密的任何内容作缓存，这也就是说所有静态文件会每次都要重新请求一遍，这个必须避免。方法是使用HTTP头，"Cache-Control:
public"
对于nginx来说，配置如下:
注： firefox貌似不支持这个。
参考文档:
https://software.intel.com/zh-cn/articles/accelerating-ssl-load-balancers-with-intel-xeon-v3-processors
http://blog.haproxy.com/2011/09/16/benchmarking_ssl_performance/
https://serversforhackers.com/using-ssl-certificates-with-haproxy
http://blog.onefellow.com/post/82478335338/haproxy-mapping-process-to-cpu-core-for-maximum
https://www.haproxy.com/doc/hapee/1.5/system/tunning.html
http://op.baidu.com/2015/04/https-s01a03/
http://blog.haproxy.com/2015/06/09/haproxy-and-http-strict-transport-security-hsts-header-in-http-redirects/
https://s3-eu-west-1.amazonaws.com/ssl247/1415979645_Webinar-SSL_EN.pdf
https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04
https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-with-http-2-support-on-ubuntu-16-04
http://arstechnica.com/information-technology/2015/05/web-served-how-to-make-your-site-all-https-all-the-time-for-everyone/
https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/
https://raymii.org/s/snippets/haproxy_ssl_backends.html
http://virtuallyhyper.com/2013/05/configure-haproxy-to-load-balance-sites-with-ssl/
https://bjornjohansen.no/optimizing-https-nginx
http://arstechnica.com/information-technology/2015/05/web-served-how-to-make-your-site-all-https-all-the-time-for-everyone/
https://raymii.org/s/snippets/haproxy_set_specific_ssl_ciphers.html
https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
http://www.systutorials.com/5450/improving-sshscp-performance-by-choosing-ciphers/
https://blog.cloudflare.com/how-cloudflare-is-making-ssl-fast/
https://mozilla.github.io/server-side-tls/ssl-config-generator/
https://www.troyhunt.com/understanding-http-strict-transport/
https://www.ietf.org/proceedings/92/slides/slides-92-saag-2.pdf
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html
https://blog.qualys.com/securitylabs/2016/03/28/the-importance-of-a-proper-http-strict-transport-security-implementation-on-your-web-server
https://gold.xitu.io/entry/58252932da2f60005d2b8ac8
https://androidtest.org/gohttps/
http://www.jianshu.com/p/e3aa175e232c
