最近，各大企业都在为一件事忙活——HTTPS化。因为苹果早在2016年WWDC大会就宣布了，2017年开始所有iOS设备将强制使用HTTPS连接。这也就意味着如果您的业务目前还不支持HTTPS访问，很有可能再过几个月，苹果用户会访问不了您的业务。
那么HTTPS到底意味着什么，全面HTTPS化带来的影响是什么？能否HTTP与HTTPS混合呈现？当业务全部使用HTTPS提供访问时，是否就绝对安全了呢？
在本期活动中，大家会围绕最近最热门的HTTPS化问题，探讨各企业进行HTTPS化面临的问题，HTTPS访问加速使用的办法，以及如何应对mix-content问题，以及如果保证业务访问安全可靠等开放性话题。

什么是HTTPS

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。超文本传输协议 (HTTP-Hypertext transfer protocol) 是一种详细规定了浏览器和万维网服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。

https协议需要到ca申请证书，一般免费证书很少，需要交费。http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。http的连接很简单,是无状态的HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全HTTPS解决的问题：

1 . 信任主机的问题.
采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书. 改证书只有用于对应的server 的时候,客户度才信任次主机. 所以目前所有的银行系统网站,关键部分应用都是https 的. 客户通过信任该证书,从而信任了该主机. 其实这样做效率很低,但是银行更侧重安全. 这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue 还是从公众的地方issue, 客户端都是自己人,所以我们也就肯定信任该server.

2 . 通讯过程中的数据的泄密和被窜改
（1）. 一般意义上的https, 就是 server 有一个证书.
a) 主要目的是保证server 就是他声称的server. 这个跟第一点一样.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的密钥,通过server 的证书来交换密钥. 一般意义上的握手过程.
ii. 加下来所有的信息往来就都是加密的. 第三方即使截获,也没有任何意义.因为他没有密钥. 当然窜改也就没有什么意义了.
（2）.少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.
b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response. 由于https 要还密钥和确认加密算法的需要.单握手就需要6/7 个往返.
i. 任何应用中,过多的round trip 肯定影响性能.
b) 接下来才是具体的http协议,每一次响应或者请求, 都要求客户端和服务端对会话的内容做加密/解密.
i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片. 如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求.
ii. 加密后数据量的影响. 所以，才会出现那么多的安全认证提示

总之，HTTPS是业内一种行之有效的对HTTP传输过程进行加密的方式，通过HTTPS可以有效的防止内容在传输过程中被篡改。

如何支持HTTPS

支持HTTPS需要购买并安装HTTPS证书，一般的流程是：
https证书购买流程
　　一、准备相关材料
　　1)提供域名信息;
　　2)提供最终用户联系人信息(包括名称、地址、电话、邮件、职位)
　　3)提供证书签名请求(会提供指导文档支持)
　　4)营业执照复印件
　　二、签定购买合同
　　买卖双方签定数字证书购买合同，可以以传真，扫描，快递等方式完成。
　　三、客户方付款
　　以电汇，支票等方式向CA机构支付数字证书款项。
　　四、提交数字证书申请资料
　　购买https证书的客户请提交以下资料：
　　1 最新年检的企业法人营业执照副本复印件
　　2 填写https证书申请表
　　3 提交CSR。
　　五、等待审核验证。
　　CA机构会严格的按照国际标准来做身份鉴证。
　　六、签发证书
　　最终数字证书以邮件的形式发到申请表中技术联系人的邮箱，并协助进行证书安装。

如何优化HTTPS

目前已经有了一些HTTPS优化的经验，比如：
Session resume
Session resume 顾名思义就是复用 session，实现简化握手。复用 session 的好处有两个：
1、减少了 CPU 消耗，因为不需要进行非对称密钥交换的计算。
2、提升访问速度，不需要进行完全握手阶段二，节省了一个 RTT 和计算耗时。
TLS 协议目前提供两种机制实现 session resume，分别介绍一下。

• Session cache
  Session cache 的原理是使用 client hello 中的 session id 查询服务端的 session cache, 如果服务端有对应的缓存，则直接使用已有的 session 信息提前完成握手，称为简化握手。
  Session cache 有两个缺点：
  1、需要消耗服务端内存来存储 session 内容。
  2、目前的开源软件包括 nginx,apache 只支持单机多进程间共享缓存，不支持多机间分布式缓存，对于百度或者其他大型互联网公司而言，单机 session cache 几乎没有作用。
• Session cache 也有一个非常大的优点：
  session id 是 TLS 协议的标准字段，市面上的浏览器全部都支持 session cache。
  百度通过对 TLS 握手协议及服务器端实现的优化，已经支持全局的 session cache，能够明显提升用户的访问速度，节省服务器计算资源。
• Session ticket
  session cache 的两个缺点，session ticket 能够弥补这些不足。
  Session ticket 的原理参考 RFC4507。简述如下：
  server 将 session 信息加密成 ticket 发送给浏览器，浏览器后续握手请求时会发送 ticket，server 端如果能成功解密和处理 ticket，就能完成简化握手。
  显然，session ticket 的优点是不需要服务端消耗大量资源来存储 session 内容。
  Session ticket 的缺点：
  1、session ticket 只是 TLS 协议的一个扩展特性，目前的支持率不是很广泛，只有 60% 左右。
  2、session ticket 需要维护一个全局的 key 来加解密，需要考虑 KEY 的安全性和部署效率。
  总体来讲，session ticket 的功能特性明显优于 session cache。希望客户端实现优先支持 session ticket。
• Ocsp stapling
  Ocsp 全称在线证书状态检查协议 (rfc6960)，用来向 CA 站点查询证书状态，比如是否撤销。通常情况下，浏览器使用 OCSP 协议发起查询请求，CA 返回证书状态内容，然后浏览器接受证书是否可信的状态。
  这个过程非常消耗时间，因为 CA 站点有可能在国外，网络不稳定，RTT 也比较大。那有没有办法不直接向 CA 站点请求 OCSP 内容呢？ocsp stapling 就能实现这个功能。
  详细介绍参考 RFC6066 第 8 节。简述原理就是浏览器发起 client hello 时会携带一个 certificate status request 的扩展，服务端看到这个扩展后将 OCSP 内容直接返回给浏览器，完成证书状态检查。
  由于浏览器不需要直接向 CA 站点查询证书状态，这个功能对访问速度的提升非常明显。

经典问题：

问：HTTP与HTTPS混合是否会出现不匹配或者不兼容等问题
答：对，混合的就叫mix content，mix-content在不同浏览器会有不同的警告行为，总之不会正常。
所以我们必须杜绝mix content的出现

问：HTTPS的性能是不是比HTTP差
答：https分为两个阶段，非对称加密和对称加密，非对称加密确实会慢一些，但对称加密几乎没有什么性能损失，因为算法是线性的。
经过优化后，不会差太多，你可以理解不会差一个数量级以上，网上有一些性能对比，可以参考，http://www.cs.nyu.edu/artg/research/comparison/comparison.html

问：引用第三方非https协议内容的时候，浏览器的警告有没有办法解决
我们的业务有时候在https页面中会嵌入第三方的图片或者脚本，但它们并不支持https,在用户访问的时候浏览器就会发出警告，用户体验很糟糕。请问有没有同行遇到此类问题，如何解决的。谢谢啦
答：这种情况的术语就是mix content，目前唯一可行的解决办法，就是通过一层proxy替换，后端指向原来的源（非https），而对外暴露一个新的https的地址，相当于把非https的链接替换为https链接，因为这些url都是诸如link类的，点开还是原来的内容，对终端用户没什么影响。
如果你们嫌麻烦，也可以直接使用我司的产品，我司的产品就是提供一个API，输入就是任一个http url地址（图片、js、css等），输出一个我司域名下的https地址，然后你把链接一替换即可

问：全站https访问设计需要从那几个方面考虑？注意事项是什么？
答：
1，https后带来的性能损失问题，具体损失多少需要实际测试，看是否需要扩容
2，https后带来的对于运维的影响，比如之前能抓明文流量分析，现在不行了等等
3，https中对于第三方域名下的resource的https化的问题，这个我在别的帖子里介绍了一个办法，如果嫌麻烦，也可以使用我司现有产品，来解决mix content问题
4，有些cdn厂商不支持https或者支持的不好，所以要选择对https支持得力的cdn公司

问：针对目前已经存在的已有的HTTP应用，如何转到更安全的https应用？
针对目前已经存在的已有的HTTP应用，如何转到更安全的https应用？
随着国内目前对安全的认识和要求越来越高，从安全管理要求来说，非常有必要转到https的应用上。但目前我们更多的是基于HTTP的应用在使用。从我经常使用的互联网网站来看，已经有越来越多的网站已转向基于HPPTS的应用，如百度（https://www.baidu.com/），毒霸网址大全（https://www.duba.com/）等等。
但是，基于目前更多的是应用在HTTP环境下，如何快速转向HTTPS环境下的应用？如何逐步实现更多的基于HTTPS方面的应用？还请相关专家，同仁，结合自己的应用实践，发表分享自己的一些观点和建议，一起推动和提高我们的应用环境的安全，做到安全可靠地使用和管理。
答：
对于网站来讲：
1，购买证书并安装，确保本域名可以通过https访问
2，进行测试和优化，或者扩容，确保https后的正常快速访问
3，对于非本域名的第三方的http resource，可以使用类似proxy转换的方式进行地址转换替换（我司提供这样的服务）
4，注意并行访问，在一段时间内80和443共存，最终过渡到443
5，对于移动App来讲，要想彻底防止劫持篡改，最好配备https dns在域名解析阶段进行保护

问：HTTPS化以后,公司网络如何做到有效的黑白名单访问控制?
传统的黑白名单都是针对三层IP地址过滤和七层URL进行过滤.当对方网站进行HTTPS化以后,访问都是加密访问,我们在网络部署时候可以怎么对其进行有效的访问控制吗?如何控制?原理是什么?
答：如果是3层的话，跟之前是没区别的，因为https在3层之上，换句话说，在https上取TCP包，会看到准确的源IP和目的IP，这样跟原来基本一样