前沿
据悉苹果强制APP在2016年底使用ATS协议,所以公司准备将部分站点http统一替换成https。所有我们就得测试下
1.首先原有的haproxy1.5升级到了1.7版本支持ssl
2.查看相关文档,测试
3.如果站点经过CDN加速,还需要确认CDN是否支持https或者支持是否收取额外费用
4.等等。。。。。。
1.现有环境
2.haproxy代理ssl模式
haproxy 代理 ssl 有两种方式
1、haproxy 本身提供ssl 证书,后面的web 服务器走正常的http (偷懒方式)
2、haproxy 本身只提供代理,后面的web服务器https
-
第一种是我们选择的模式,在haproxy这里设定SSL,这样我们可以继续使用七层负载均衡。SSL连接终止在负载均衡器haproxy ----->解码SSL连接并发送非加密连接到后端应用tomcat,这意味着负载均衡器负责解码SSL连接,这与SSL穿透相反,它是直接向代理服务器发送SSL连接的。
-
第二种使用SSL穿透,SSL连接在每个tomcat服务器终止,将CPU负载都分散到tomcat服务器。然而,这样做会让你失去增加或修改HTTP报头的能力,因为连接只是简单地从负载均衡器路由到tomcat服务器,这意味着应用服务器会失去获取 X-Forwarded-* 报头的能力,这个报头包含了客户端IP地址、端口和使用的协议。
-
有两种策略的组合做法,那就是第三种,SSL连接在负载均衡器处终止,按需求调整,然后作为新的SSL连接代理到后台服务器。这可能会提供最大的安全性和发送客户端信息的能力。这样做的代价是更多的CPU能耗和稍复杂一点的配置。
-
选择哪个策略取决于你及应用的需求。SSL终端为我所见过最典型的策略,但SSL穿透可能会更安全。
ps:这段是招扒的wangzan18的。在此谢谢
第一种方式
需要编译haproxy 支持ssl,编译参数:
make TARGET=linux26 USE_OPENSSL=1 ADDLIB=-lz ldd haproxy | grep ssl libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007fb0485e5000)
配置参数:
frontend https_frontend bind *:443 ssl crt /etc/ssl/certs/servername.pem mode http option httpclose option forwardfor reqadd X-Forwarded-Proto: https default_backend web_server backend web_server mode http balance roundrobin cookie SERVERID insert indirect nocache server s1 192.168.250.47:80 check cookie s1 server s2 192.168.250.49:80 check cookie s2
注意:这里的pem 文件是下面两个文件合并而成:
cat servername.crt servername.key |tee servername.pem
第二种方式配置
不需要重新编译支持ssl,简单方便。需要后面的web服务器配置好ssl 即可。
frontend https_frontend
bind *:443
mode tcp
default_backend web_server
backend web_server
mode tcp
balance roundrobin
stick-table type ip size 200k expire 30m
stick on src
server s1 192.168.250.47:443
server s2 192.168.250.49:443
注意:这种模式下mode 必须是tcp 模式
3.配置说明
这一行要加,要不然reload会警告
tune.ssl.default-dh-param 2048
保留80,同时支持443 ssl,后面指定证书文件
redirect scheme https if !{ ssl_fc }
这一行是仅支持ssl,效果是:访问80端口是自动跳转到443的ssl
这是针对node生效,如果想全局使用的话,可以把这句话添加到frontend下
这是针对node生效,如果想全局使用的话,可以把这句话添加到frontend下