Chinaunix
标题: 【专家坐堂】全站 HTTPS——如何规划、部署、优化？（获奖名单已公布） [打印本页]
作者: Godbach 时间: 2016-11-28 14:27
标题: 【专家坐堂】全站 HTTPS——如何规划、部署、优化？（获奖名单已公布）
请以上获奖者在2017年1月20日前将姓名，公司，职务，行业，电话，邮箱，QQ，地址，站内短信发送给王楠w_n以便及时给您快递奖品。
由于年底快递业务已停，将于2月6日开始陆续发放图书。
发不了站短的，请在原帖下方跟帖留言。
至于QQ现因两个编辑轮番值班登陆，可能会有遗漏的情况，有任何问题请尽量在原帖下方跟帖留言或在站务版块反馈，谢谢！
注：因特殊原因，每次活动的获奖者我都会通知各位，如果大家在截止日期之前还未联系到管理员，那么本次活动的得奖资格将被取消，所以请大家及时的与管理员取得联系，谢谢合作！
============================================================
背景介绍：
2015 年阿里天猫、淘宝支持全站 HTTPS，并经历了两次双十一的洗礼，稳定的支撑了天量的交易。在此之前，百度的搜索也启用了 HTTPS。HTTPS 最直接的优势就是避免页面劫持。当然，随着各大主流浏览器对 HTTP/2 的支持，以及未来会将 HTTP 网站标记为不安全的等诸多因素，网站 HTTPS 是一个必然的趋势。
讨论话题（包括但不限于）
1. 网站改造 HTTPS 过程中跳过的坑或者要注意的问题
2. 影响甚至导致无法全站 HTTPS 的痛点或者障碍
3. 证书申请以及私钥管理上的一些注意事项
4. 部署 HTTPS 后，优化手段、遇到的问题以及解决方法
5. 负载均衡下或者 CDN 中部署 HTTPS 的一些经验
欢迎任选一个到多个话题畅所欲言。
特邀嘉宾：
杨洋（InfoHunter）前阿里巴巴 SSL/TLS、密码学和网络安全领域专家，曾负责阿里巴巴集团全站 HTTPS 和七层 DDoS 防御产品的核心设计和研发， 图书《HTTPS权威指南-在服务器和Web应用上部署SSL TLS和PKI》译者之一。
活动时间
2016.11.28--2016.12.27
活动奖励：
参与讨论质量最优秀的会员奖励《HTTPS权威指南-在服务器和Web应用上部署SSL TLS和PKI》图书一本，共6 本。
作者： [英] Ivan Risti
译者： 杨洋 李振宇 蒋锷 周辉 陈传文
丛书名： 图灵程序设计丛书
出版社：人民邮电出版社
ISBN：9787115432728
上架时间：2016-8-25
出版日期：2016 年9月
开本：16开
页码：436
版次：1-1
所属分类：计算机 > 计算机网络 > 网络协议 > 综合
内容简介：本书是集理论、协议细节、漏洞分析、部署建议于一体的详尽Web应用安全指南。书中具体内容包括：密码学基础，TLS协议，PKI体系及其安全性，HTTP和浏览器问题，协议漏洞；最新的攻击形式，如BEAST、CRIME、BREACH、Lucky 13等；详尽的部署建议；如何使用OpenSSL生成密钥和确认信息；如何使用Apache httpd、IIS、Nginx等进行安全配置。
试读样章：
第1章 SSL、TLS和密码学.doc
(525.29 KB, 下载次数: 218)
作者: GB_juno 时间: 2016-11-28 18:31
1. 网站改造 HTTPS 过程中跳过的坑或者要注意的问题
ssl卸载消耗比较大的cpu，对于常用的nginx反向代理来说，启用了https后每秒请求处理能力会降低了很多(本人测试过大概10分之1，不保证正确度)。因此如果原来能够支撑住网站的服务就进行操作比较大的扩容了。另外就是安全以及协议、加密算法的选择。安全上来说要尽量用比较新的openssl library，协议来说一般用tls了，原来的sslv1/2/3基本都不太安全了...最后加密算法主要在于看浏览器支持，基于安全的需要选择适当的算法。
2. 影响甚至导致无法全站 HTTPS 的痛点或者障碍
全站https就要求了引用的资源也必须https。万一这些资源没有https怎么办，只能见一个搞一个。
3. 证书申请以及私钥管理上的一些注意事项
私钥要保管好，只对涉及的运维人员放开。不要通过qq、邮箱这种方式传，万一泄漏了就完了。即使传也要加密，加密密码通过电话或者其他方式传。
4. 部署 HTTPS 后，优化手段、遇到的问题以及解决方法
最近碰到的麻烦是chrome 53版本对赛门铁克证书必须要求ct的事情..无能为力，黑天鹅
5. 负载均衡下或者 CDN 中部署 HTTPS 的一些经验
做好了网站的动静分离后，静态元素放在单独的域名下。对于cdn这种资源，因为在前端也要部署https证书，应该申请独立的域名，即使泄漏了也无关紧要，毕竟只是静态资源。
作者: Godbach 时间: 2016-11-28 18:48
回复 2# GB_juno
LS HTTPS 方面经验很丰富，赞一个！
作者: Godbach 时间: 2016-11-28 18:49
本帖最后由 Godbach 于 2016-12-09 12:24 编辑
回复 2# GB_juno
启用了https后每秒请求处理能力会降低了很多(本人测试过大概10分之1，不保证正确度
是的。我之前了解的数据，单纯测试新建能力，应该是下降这么多。如果用 keepalive 传输数据阶段，应该会好很多。
作者: InfoHunter 时间: 2016-11-28 20:05
赛门铁克被google强制CT的那个事情，如果证书被赛门铁克正确的记了log，应该没啥问题吧。不过Chrome 53也有bug：
https://knowledge.symantec.com/s ... nt&id=ALERT2160
作者: Godbach 时间: 2016-11-28 22:33
回复 5# InfoHunter
嘉宾出现了。各位可以多多问 SSL 的相关问题啊，InfoHunter 绝对是 SSL 方面的大牛。
作者: forgaoqiang 时间: 2016-11-29 09:58
本帖最后由 forgaoqiang 于 2016-12-15 19:37 编辑
1. 网站改造 HTTPS 过程中跳过的坑或者要注意的问题
以前改造的时候直接去网上复制了一段HTTPS的nginx配置文件，发现部分浏览器正常，对于新的火狐或者谷歌浏览器，居然访问报错
出问题的配置部分，怎么看都是语法正确的
- ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
火狐会给出下面的提示
SSL decrypt error during SSL handshake
chrome直接不给提示，站点不可访问
原因居然是加密选择过弱，需要下面的配置才能正常工作，因此正确的选择 加密套件 非常重要
- ssl_protocols SSLv3 TLSv1;
2. 影响甚至导致无法全站 HTTPS 的痛点或者障碍
HTTPS是无法被缓存的，这个是痛点，对于无关紧要的静态资源来说静态化必要性不大，而且开销过大，很划不来。HTTPS引用的资源要求是https否则现代浏览器都会警告报错
3. 证书申请以及私钥管理上的一些注意事项
证书需要放置到服务器上，私钥当然要尽量做到保密，管理员小心的备份私钥。申请证书当时用的沃通的服务，现在沃通的部分证书暂时不被苹果、谷歌、火狐他们接受，这也是个问题。因此还是要考虑选择靠谱点的证书服务商。
保存的话压缩加密备份，发送到邮箱备份还是很靠谱的，不容易出现丢失现象。
4. 部署 HTTPS 后，优化手段、遇到的问题以及解决方法
使用的证书是等级较低的，证书链不完整的话，会被当非法站点 。。。 重新签的证书
5. 负载均衡下或者 CDN 中部署 HTTPS 的一些经验
负载均衡或者CDN采用HTTPS部署使用单独的证书和独立域名，避免同域下的浏览器加载并发限制等问题。
另外网上对证书视乎没有好的总结，我个人总结一下证书类型：
IV（Identity Validation）
个人验证型（IdentityValidation SSL），适用于个人专业网站使用，显示个人姓名；
DV（Domain Validation) 证书
只认证网站域名是不是申请人所有，不验证单位，级别是Class 1 级别的。
OV（Organization Validation）证书
需要提供注册局（工商局）注册文档、组织机构代码证、法人**明等等资料，然后CA会去工商局网站核对，然后还会验证电话等等步骤；
适用于电子商务、电子政务、企事业管理单位。
EV（Extended Validation）证书
不仅需要进行上述的验证环节，还需要公司资料能够在第三方数据库中查询得到，包括：公司的电话需要在黄页上查询到，公司资料能够在D&B（邓白氏）等处查询到并且与注册信息一致
适用于银行金融类电子商务网站
相对来说IV和DV可以是免费的，但是OV和EV一般是越来越贵~
作者: Godbach 时间: 2016-11-29 09:59
InfoHunter 发表于 2016-11-28 20:05 
赛门铁克被google强制CT的那个事情，如果证书被赛门铁克正确的记了log，应该没啥问题吧。不过Chrome 53也 ...
InfoHunter 兄介绍一下ATS的要求吧
作者: cxsvip 时间: 2016-11-29 10:22
infoHunter这个名字好熟，往下一翻，前同事。。。。
作者: cxsvip 时间: 2016-11-29 10:48
没有接触过HTTPS相关的项目，但SSL/TLS使用硬件加速一下的话应该会对HTTPS有一定的好处，Intel的一个解决方案是QuickAssist，
Openssl项目Intel有专门的一个分支用于QuickAssisit的Patch，Nginx也有相应的Pacth，这些信息是几年前和Intel工程师讨论问题时得到的，不知道现在变成啥样了。
另外关于证书获取，开发过SCEP（简单证书注册协议），当时找支持SCEP的服务器真的很难。
证书大小不知道会不会对HTTPS有影响，x509证书一般比较大，做车载通信时接触过1609.2证书，这个证书特点就是小，大概就是100K左右，现在好像也有ssl over 1609.2的一些应用。
作者: Godbach 时间: 2016-11-29 13:51
回复 10# cxsvip
感谢分享。
证书小的话，至少网络传输上节省带宽。 ECDSA 现在势头比较猛。
作者: GB_juno 时间: 2016-11-29 15:57
回复 5# InfoHunter
HTTPs没有做CT策略(目前只有chrome支持CT)，所以悲剧了..
看新闻上面看到是赛门铁克之前未经域名拥有者同意，私自签发了75域名的测试证书（包括谷歌的域名），所以谷歌就要求了CT..神仙打架，吃瓜群众莫名中枪
作者: InfoHunter 时间: 2016-11-29 20:52
Intel QAT吧，那个用过，比较便宜，不过我们的nginx是改的比较大，所以没法用Intel给的patch，只能自己开发来调那些API
作者: InfoHunter 时间: 2016-11-29 20:59
对，很多CA都没少干这事，前段时间WoSign悲剧了，看新闻说360要把WoSign和StartCom再拆分开，不知道WoSign以后会咋样…………
其实强制CT也是好事
作者: InfoHunter 时间: 2016-11-29 21:05
嗯，ECC值得使用，淘宝和天猫现在就是ECDSA的证书
作者: InfoHunter 时间: 2016-11-29 23:20
OK，ATS全称是Apple Transport Security，实际上就是从iOS 9开始默认开启的一项功能，旨在让App发起的到服务端的请求都走HTTPS。最近各App、CDN的vendor们都比较关注这个事情，并且积极的准备应对，主要是因为在2016年6月的WWDC上Apple宣布从2017年1月开始强制执行ATS（之前是可以关闭的）。
然后ATS有这么几个细节，技术方面的：
- ATS只作用于high level的API，比如NSURLSession, NSURLConnection。。。socket层面不受ATS影响
- iOS 10之后SSL方面有这么几个变化：RC4默认禁用、SSL 3默认禁用，新增了针对本地网络不强制应用ATS的功能，新增了对CT(certificate transparency)的支持。。。
如果App已经支持了HTTPS，或者正在计划支持，那强制ATS影响不大，皆大欢喜。
但是如果因为某些原因无法实现HTTPS，那可能就比较麻烦了，因为明年开始不能像之前那样直接把ATS全局关闭来绕过，现在的手段主要是依赖于苹果的App Review，需要提出合理的理由（reasonable justification）给审核人员，但是这个就已经不是技术层面的问题，审核人员界定的理由的标准也不好判断。
其实Apple这次释放的信号已经很明显了，就是要增强安全，包括之前Google在搜索结果中会更偏向HTTPS网站的行为，其实都已经说明HTTPS已经是大势所趋，假以时日，待HTTP/2全面铺开，加密流量也会随之无处不在。
结论就是，如果你的App还在裸跑HTTP，也许真到该考虑使用HTTPS的时候了。
作者: Godbach 时间: 2016-11-29 23:28
回复 16# InfoHunter
回答的灰常给力 
作者: forgaoqiang 时间: 2016-11-29 23:55
回复 14# InfoHunter
苹果、火狐浏览器不信任沃通证书一年 加密安全算法太弱也是个问题
作者: Godbach 时间: 2016-11-30 08:56
forgaoqiang 发表于 2016-11-29 23:55
回复 14# InfoHunter
苹果、火狐浏览器不信任沃通证书一年 加密安全算法太弱也是个问题
有个CA资格多么难得，可以说一本万利。不好搞好维护，真不知道肿么想的
作者: devil3380 时间: 2016-11-30 11:45
沃通 呵呵. 现在chrome和firefox都对其采取不信任的措施,还不是自己找的
收购了StartCom,还把StartCom给搞臭了
看https://wiki.mozilla.org/CA:WoSign_Issues里面介绍的这样,还有谁会去用
问题1
沃通 CA 允许证书申请者选择任意端口进行验证，违反了限制端口和路径使用的规定；
问题2
证书申请者如果能证明控制了某个子域名，那么就能获得根域名的证书；
已经研究人员利用沃通的这个失误，获得了一张沃通签发的【GitHub 网站主域名的证书】。
问题3
被沃通并购的 StartCom（也是一家 CA），被发现允许对证书的签署日期进行【倒填】。关于这个“倒填日期”的问题，俺稍微解释一下：
由于如今的运算能力越来越强，SHA1 散列算法的可靠性越来越不够了。一些主流的浏览器，如果发现2016元旦之后签署的 CA 证书，依然采用 SHA1，会给出警告。
沃通的问题在于，它为了帮证书申请人规避浏览器警告，故意把签署日期伪造成2015年底。
问题4
除了英国程序员曝光的那3个问题，再来说一下其他人曝光的问题——
沃通在2015年4月9日到4月14日之间，签发了392个【相同序列号】的证书。
最近在折腾 Let's Encrypt了
作者: devil3380 时间: 2016-11-30 11:46
沃通 呵呵. 现在chrome和firefox都对其采取不信任的措施,还不是自己找的
收购了StartCom,还把StartCom给搞臭了
看https://wiki.mozilla.org/CA:WoSign_Issues里面介绍的这样,还有谁会去用
问题1
沃通 CA 允许证书申请者选择任意端口进行验证，违反了限制端口和路径使用的规定；
问题2
证书申请者如果能证明控制了某个子域名，那么就能获得根域名的证书；
已经研究人员利用沃通的这个失误，获得了一张沃通签发的【GitHub 网站主域名的证书】。
问题3
被沃通并购的 StartCom（也是一家 CA），被发现允许对证书的签署日期进行【倒填】。关于这个“倒填日期”的问题，俺稍微解释一下：
由于如今的运算能力越来越强，SHA1 散列算法的可靠性越来越不够了。一些主流的浏览器，如果发现2016元旦之后签署的 CA 证书，依然采用 SHA1，会给出警告。
沃通的问题在于，它为了帮证书申请人规避浏览器警告，故意把签署日期伪造成2015年底。
问题4
除了英国程序员曝光的那3个问题，再来说一下其他人曝光的问题——
沃通在2015年4月9日到4月14日之间，签发了392个【相同序列号】的证书。
最近在zhe
作者: Godbach 时间: 2016-11-30 17:23
回复 20# devil3380
涨姿势啊
作者: forgaoqiang 时间: 2016-12-02 09:13
回复 21# devil3380
火狐不再信任沃通的证书，的确部分证书因为安全和时间问题暂时停止信任了 绝对是作
作者: Godbach 时间: 2016-12-03 22:39
回复 23# forgaoqiang 对的。这么好的资源不好好维护，真是作。
作者: Godbach 时间: 2016-12-05 13:26
@InfoHunter
对于中间人攻击，可以简单介绍一下。通常只要 server 私钥不泄露，证书应该是被伪造的吧，作为 client，只要及时识别出来证书有问题，应该就不会被欺骗吧。
作者: forgaoqiang 时间: 2016-12-05 13:40
中间人攻击不太可能成功吧
首先你得有一个用户浏览器信任根证书签名的证书吧 这个怎么弄到手呢？ 正规的CA不会给你签发的吧 除非。。。
作者: Godbach 时间: 2016-12-05 13:46
回复 26# forgaoqiang
有些缺乏安全意识的用户，可能会忽略浏览器的警告。
作者: forgaoqiang 时间: 2016-12-05 14:14
回复 27# Godbach
好吧 ( ⊙ o ⊙ )
只不过这些用户和https就没有关系了吧 怎么都会中招 。。。。
作者: Fl_wolf 时间: 2016-12-06 11:34
改造成HTTPS没遇到什么坑，不过苹果在17年1月要全线HTTPS不是的好像是会不能使用吧，我们这边的游戏之前都用的是http的要全部改掉，登陆的改了但是升级的没有改，导致游戏不能升级，升级的要在CDN上面也要加https的配置= = 。。
作者: Godbach 时间: 2016-12-06 12:02
回复 29# Fl_wolf
看来升级很顺利，网页内容的资源引用啥的都不需要修改了？
作者: haishui 时间: 2016-12-06 16:15
现在IOS 都要求了。
作者: c3po 时间: 2016-12-07 09:13
请教大佬，是降了十分之一还是降到十分之一？
我用Nginx也在愁这个事情，还没机会大规模测试验证。
作者: Godbach 时间: 2016-12-07 09:54
本帖最后由 Godbach 于 2016-12-07 12:15 编辑
c3po 发表于 2016-12-07 09:13
请教大佬，是降了十分之一还是降到十分之一？
我用Nginx也在愁这个事情，还没机会大规模测试验证。
加密这么耗性能的，如果只损失十分之一的性能，那么又安全又好用，谁还不用呢。
作者: cjfeii 时间: 2016-12-07 15:58
我们的https改造，就是在原来的http服务器上加一个https的代理 ~~
作者: lnwu 时间: 2016-12-07 16:22
弱弱的问下：
前端一个公网IP，安装haproxy，haproxy使用的http模式，配置多个域名分别指向后端不同的服务器。
启用HTTPS的话，证书放在前端服务器，从haproxy到后端只能走http，不能走HTTPS对吗？
这种情况下怎么实现从haproxy到后端服务器这最后一公里实现全加密走HTTPS？
感觉要实现从haproxy到后端服务器走HTTPS的话就得使用tcp模式，但是tcp模式又不能判断域名从而
转发到不同的后端服务器。
想不明白这个改如何解决。
看到网上说有的网站有两级反向代理，Nginx+haproxy+server的，那种环境多域名一个的话怎样实现全
走https的呢？
作者: Godbach 时间: 2016-12-07 19:41
回复 35# lnwu
从haproxy到后端只能走http，不能走HTTPS对吗？
作者: Godbach 时间: 2016-12-07 19:44
回复 35# lnwu
感觉要实现从haproxy到后端服务器走HTTPS的话就得使用tcp模式，但是tcp模式又不能判断域名从而
转发到不同的后端服务器。
作者: c3po 时间: 2016-12-08 08:48
我心里也是这么猜的，被大佬挑明了好桑心啊。鱼和熊掌我都好咋办
作者: c3po 时间: 2016-12-08 08:58
回复 35# lnwu
我们在实践中一般不采用软式多级反代，只要条件允许，建议客户在公网入口部署有HA/LB能力的硬件，在四层向后面两个nginx分发，各个Nginx上再跑七层向后端分发，Nginx上面可以做很多逻辑控制。当然以上前提都是木有跑https，这个时候Linux/Freebsd下的Nginx接入能力超级强大足够为众多的后端应用服务器做代理。
现在大佬说了上https以后缩水90%的接入性能，就不知道咋办鸟。
以上是我这的经验希望对你有点用
作者: ccjsj1 时间: 2016-12-08 20:00
1.网站改造 HTTPS 过程中跳过的坑或者要注意的问题
目前的http还没改造成https，公司有这个计划了，真的改造起来不知道会遇到什末坑呢。
2.影响甚至导致无法全站 HTTPS 的痛点或者障碍
https是无法被缓存的觉得是个问题，干的活多了cpu消耗增大了。
3.证书申请以及私钥管理上的一些注意事项
证书的私钥文件要保管好，只对涉及的运维和开发人员放开。传输过程中要文件和密码分开途径传输，避免泄漏。
4.部署 HTTPS 后，优化手段、遇到的问题以及解决方法
使用的证书是等级较低的，证书链不完整的话，会被当非法站点，需要重新签。
5.负载均衡下或者 CDN 中部署 HTTPS 的一些经验
使用单独的证书和独立域名，避免同域下的浏览器加载并发限制等问题。
作者: Godbach 时间: 2016-12-09 12:19
回复 38# c3po
可以上一些好的架构，比如前段用 负载均衡处理。
作者: Godbach 时间: 2016-12-09 12:22
本帖最后由 Godbach 于 2016-12-09 12:24 编辑
回复 39# c3po
更正一下我的说法。我了解的结果，应该是单纯的测试新建。因为 SSL 握手是比较耗性能的，所以对比明显。
咱们通常用的 HTTP，都是 keepalive 模式，性能的影响肯定没有这么严重。至于具体数据，我手头没有。
作者: Godbach 时间: 2016-12-09 12:26
回复 40# ccjsj1
2.影响甚至导致无法全站 HTTPS 的痛点或者障碍
https是无法被缓存的觉得是个问题，干的活多了cpu消耗增大了。
另外，如果你需要加速的话，是可以考虑通过 CDN 的。这个 CDN 可以帮忙缓存。
作者: devil3380 时间: 2016-12-09 15:50
回复 33# Godbach
已经改造完毕,没有传说中那么慢.慢是慢了点.但是十分之一有点夸张
作者: ccjsj1 时间: 2016-12-09 22:02
回复 43# Godbach
涨知识了
作者: Godbach 时间: 2016-12-10 16:11
回复 44# devil3380
可以分享一下你的测试方法吗。
如果一个 HTTP 请求就关闭一次连接，看下这种条件下的性能。
作者: 1khaigou 时间: 2016-12-14 09:25
这个超级不错，赞一个
作者: c3po 时间: 2016-12-14 14:09
回复 42# Godbach
Thanks!
作者: Godbach 时间: 2016-12-14 14:58
回复 47# 1khaigou
多分享 
作者: forgaoqiang 时间: 2016-12-15 19:39
苹果公司要求1月1日 以后所有APP使用https连接，这样之前的微信连WIFI业务需要改造，对回调地址添加了https支持 只是部分业务提升到了https 整体没有感觉变慢
作者: InfoHunter 时间: 2016-12-15 22:03
forgaoqiang 发表于 2016-12-05 14:14
回复 27# Godbach
好吧 ( ⊙ o ⊙ )
移动端不提示证书非法也是一个问题
作者: forgaoqiang 时间: 2016-12-16 14:49
基本上都会提示吧
至少很多应用会提醒 比如UC、淘宝、微信等 用户很少看明白怎么回事
作者: Fl_wolf 时间: 2016-12-17 14:38
回复 30# Godbach
那些开发的事情啦
作者: 撒加 时间: 2016-12-21 13:16
1. 网站改造 HTTPS 过程中跳过的坑或者要注意的问题
1.1 近期我们公司也在逐步来上https，虽然我们在上之前做了一定的准备工作，但是上之后也遇上一些问题，我们指定的步骤是先上HTTPS，再上HTTP/2，测试我们的官网后，就像楼上说的那样，出现HTTP的资源无法访问，必须让页面加载的第三方资源也支持HTTPS。出现这个问题后，我找研发、测试、前端、APP各部门负责人开会讨论各自团队在上线HTTPS后的支持以及问题应对，例如将https:\\ http:\\ 都只保留\\来做自适应。
1.2 在部署HTTPS的时候，还是建议服务器的CPU使用E5 V3 V4的，主要原因是这两个系列的CPU支持AESNI，当然能够使用CPU AESNI引擎的openssl版本是1.0.2以上版本，1.0.1是不支持的，所以不管是Nginx还是Haproxy来做都需要重新编译（可以顺道带上chacha20的patch）。编译Nginx和Haproxy时建议使用cflags设置-mtune=native（我是这么用的）
1.3 编译openssl的话，默认最好带上
no-ssl3 no-ssl3-method编译，从OPENSSL就关闭SSLV3的支持，免得一些SA大意在Nginx和haproxy中忘记关闭SSL V3
1.4 AES-NI默认内核是没加载的，所以需要手动加载AESNI模块，modprobe aesni-intel,当然可以在内核里把这个功能默认就编译到kernel中，而不是以模块形式启用，当然openssl engine查看的时候是看不到AESNI引擎的。
1.5 SNI问题，openssl 1.0.2默认就支持SNI了，openssl 1.0.1默认不开启，在Nginx和Haproxy配置的时候必须注意OPENSSL版本，如果不得不用1.0.1的openssl在编译的时候需要加上enable-tlsext，另外判断nginx是否支持了SNI，可以用nginx -V,如果有TLS SNI support enabled ，那SNI就是开启的
1.6 Nginx使用SNI问题不大，Haproxy还是有点差别的，比如普通的HTTPS和HTTP/2，用到的参数貌似还不一样，比如req.ssl_sni和ssl_fc_sni（还请
Godbach简单聊聊啊）
2. 影响甚至导致无法全站 HTTPS 的痛点或者障碍
我认为还是影响HTTPS部署的因素有如下几个：
从APP来说，比如一些算法JDK 1.8支持的JDK 1.7就不支持，那高效的算法要使用，估计还得升级JDK，这个升级回来带来不确定性
从手机端系统来说，安卓不同的版本支持的算法也不一样，做兼容性测试，工作量也不小
从PC端来说，浏览器的兼容性、证书的类型啥的也都多少影响一些
代码来说，如果调用第三方的URL，第三方URL如果不是HTTPS还真是个头疼的事情
3. 证书申请以及私钥管理上的一些注意事项
用商业的证书我觉得问题不大
免费证书我觉得还是做好自动更新相关的东东吧
4. 部署 HTTPS 后，优化手段、遇到的问题以及解决方法
正常的业务部署HTTPS后，我认为还是算法的优化上，需要多做测试，我们目前正在进行中
我们业务里有Varnish,直接Varnish部署HTTPS感觉还是不靠谱，所以打算用其提供的hitch来做ssl proxy，将解密后的数据发送到Varnish
5. 负载均衡下或者 CDN 中部署 HTTPS 的一些经验
负载均衡下，怎么说呢，要是硬件负载均衡本身就带了SSL加速卡，没的说
软件负载均衡，除了上面说的SNI，还有AESNI外，性能还有更高要求那就得上专门的硬件加速卡了。
为了使用HTTPS，我们自己对Haproxy和OpenResty所用的系统又重新做了定制化，主要就是AESNI的支持，让其变成默认支持，而不是模块化支持
作者: Godbach 时间: 2016-12-21 14:00
回复 54# 撒加
灰常给力。赞一个！
作者: 撒加 时间: 2016-12-21 22:36
回复 55# Godbach
目前的研究成果也就这些了，后续再补充HTTP/2的，哈哈
作者: Godbach 时间: 2016-12-23 01:08
回复 56# 撒加
分析的内容很丰富啊。
作者: Godbach 时间: 2016-12-23 01:08
回复 56# 撒加
1.6 Nginx使用SNI问题不大，Haproxy还是有点差别的，比如普通的HTTPS和HTTP/2，用到的参数貌似还不一样，比如req.ssl_sni和ssl_fc_sni（还请Godbach简单聊聊啊）
这个地方你的问题再具体一点？ 你是说 HAProxy 对 SNI 的支持问题吗？
作者: 撒加 时间: 2016-12-23 10:29
回复 58# Godbach
在查阅相关资料的时候，发现个现象就是如果仅仅是Haproxy启用HTTPS，要使用SNI的话，用的指令是req.ssl_sni，如果是启用HTTPS且私用ALPN支持HTTP/2，看到使用的指令是ssl_fc_sni
作者: Godbach 时间: 2016-12-24 21:25
回复 59# 撒加
ssl_fc_sni 和 req.ssl_sni （HAProxy v1.7 不推荐使用 req_ssl_sni）最根本的区别：- ssl_fc_sni 是在 SSL offload 开启的情况下匹配 SNI 的。也就是，你配置 bind 的时候，还需要明确开启了 SSL，配置了证书和私钥。这个情况下，OpenSSL 库本身就帮你获取了这些信息的。
- req.ssl_sni 是在没有 SSL offload 时使用的。也就是你只配置了 TCP 模式，并且没有配置 SSL。其实就是一个 DPI（深度报文检测） 的过程，从 client 端的 TCP 请求数据中识别出来是 SSL 的传输，然后再此基础上提取 SNI。
这个应该是在 HAProxy 引入 SSL 之后，就是这么个区别的。当时我搞 SSL 的时候，特意看了一下这个区别。
作者: 撒加 时间: 2016-12-26 12:10
回复 60# Godbach
收到，看来还是用ssl_fc_sni更合适。
haproxy的版本发布太快了，我们采用1.5.18，这1.7.1都发布了
作者: Godbach 时间: 2016-12-26 14:37
回复 61# 撒加
是的。现在已经 1.8-dev 了。
不过 1.6 及之后版本确实增加了不少的新特性的。以后你会有用到的时候。
作者: dscyw 时间: 2017-01-06 21:45
Https为数不多的干货
作者: devil3380 时间: 2017-01-11 16:06
| 欢迎光临 Chinaunix (http://bbs.chinaunix.net/) |
Powered by Discuz! X3.2 |