1 前言
百度已经于近日上线了全站 HTTPS 的安全搜索，默认会将 HTTP 请求跳转成 HTTPS。本文重点介绍 HTTPS 协议, 并简单介绍部署全站 HTTPS 的意义。
2 HTTPS 协议概述
HTTPS 可以认为是 HTTP + TLS。HTTP 协议大家耳熟能详了，目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的。
TLS 是传输层加密协议，它的前身是 SSL 协议，最早由 netscape 公司于 1995 年发布，1999 年经过 IETF 讨论和规范后，改名为 TLS。如果没有特别说明，SSL 和 TLS 说的都是同一个协议。
HTTP 和 TLS 在协议层的位置以及 TLS 协议的组成如下图：
图 1 TLS 协议格式
TLS 协议主要有五部分：应用数据层协议，握手协议，报警协议，加密消息确认协议，心跳协议。
TLS 协议本身又是由 record 协议传输的，record 协议的格式如上图最右所示。
目前常用的 HTTP 协议是 HTTP1.1，常用的 TLS 协议版本有如下几个：TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 由于 POODLE 攻击已经被证明不安全，但统计发现依然有不到 1% 的浏览器使用 SSL3.0。TLS1.0 也存在部分安全漏洞，比如 RC4 和 BEAST 攻击。
TLS1.2 和 TLS1.1 暂时没有已知的安全漏洞，比较安全，同时有大量扩展提升速度和性能，推荐大家使用。
需要关注一点的就是 TLS1.3 将会是 TLS 协议一个非常重大的改革。不管是安全性还是用户访问速度都会有质的提升。不过目前没有明确的发布时间。
同时 HTTP2 也已经正式定稿，这个由 SPDY 协议演化而来的协议相比 HTTP1.1 又是一个非常重大的变动，能够明显提升应用层数据的传输效率。
3 HTTPS 功能介绍
百度使用 HTTPS 协议主要是为了保护用户隐私，防止流量劫持。
HTTP 本身是明文传输的，没有经过任何安全处理。例如用户在百度搜索了一个关键字，比如“苹果手机”，中间者完全能够查看到这个信息，并且有可能打电话过来骚扰 用户。也有一些用户投诉使用百度时，发现首页或者结果页面浮了一个很长很大的广告，这也肯定是中间者往页面插的广告内容。如果劫持技术比较低劣的话，用户 甚至无法访问百度。
这里提到的中间者主要指一些网络节点，是用户数据在浏览器和百度服务器中间传输必须要经过的节点。比如 WIFI 热点，路由器，防火墙，反向代理，缓存服务器等。
在 HTTP 协议下，中间者可以随意嗅探用户搜索内容，窃取隐私甚至篡改网页。不过 HTTPS 是这些劫持行为的克星，能够完全有效地防御。
总体来说，HTTPS 协议提供了三个强大的功能来对抗上述的劫持行为：
1， 内容加密。浏览器到百度服务器的内容都是以加密形式传输，中间者无法直接查看原始内容。
2， 身份认证。保证用户访问的是百度服务，即使被 DNS 劫持到了第三方站点，也会提醒用户没有访问百度服务，有可能被劫持
3， 数据完整性。防止内容被第三方冒充或者篡改。
那 HTTPS 是如何做到上述三点的呢？下面从原理角度介绍一下。
4 HTTPS 原理介绍
4.1 内容加密
加密算法一般分为两种，对称加密和非对称加密。所谓对称加密（也叫密钥加密）就是指加密和解密使用的是相同的密钥。而非对称加密（也叫公钥加密）就是指加密和解密使用了不同的密钥。
图 2 对称加密
图 3 非对称加密
对称内容加密强度非常高，一般破解不了。但存在一个很大的问题就是无法安全地生成和保管密钥。假如客户端软件和服务器之间每次会话都使用固定的，相 同的密钥加密和解密，肯定存在很大的安全隐患。如果有人从客户端端获取到了对称密钥，整个内容就不存在安全性了，而且管理海量的客户端密钥也是一件很复杂 的事情。
非对称加密主要用于密钥交换（也叫密钥协商），能够很好地解决这个问题。浏览器和服务器每次新建会话时都使用非对称密钥交换算法协商出对称密钥，使 用这些对称密钥完成应用数据的加解密和验证，整个会话过程中的密钥只在内存中生成和保存，而且每个会话的对称密钥都不相同（除非会话复用），中间者无法窃 取。
非对称密钥交换很安全，但同时也是 HTTPS 性能和速度严重降低的“罪魁祸首”。想要知道 HTTPS 为什么影响速度，为什么消耗资源，就一定要理解非对称密钥交换的整个过程。
下面重点介绍一下非对称密钥交换的数学原理及在 TLS 握手过程中的应用。
4.2 身份认证
身份认证主要涉及到 PKI 和数字证书。通常来讲 PKI（公钥基础设施）包含如下部分：
- End entity：终端实体，可以是一个终端硬件或者网站。
- CA：证书签发机构。
- RA：证书注册及审核机构。比如审查申请网站或者公司的真实性。
- CRL issuer：负责证书撤销列表的发布和维护。
- Repository：负责数字证书及 CRL 内容存储和分发。
申请一个受信任的数字证书通常有如下流程：
1， 终端实体生成公私钥和证书请求。
2， RA 检查实体的合法性。如果个人或者小网站，这一步不是必须的。
3， CA 签发证书，发送给申请者。
4， 证书更新到 repository，终端后续从 repository 更新证书，查询证书状态等。
目前百度使用的证书是 X509v3 格式，由如下三个部分组成：
1， tbsCertificate(to be signed certificate 待签名证书内容)，这部分包含了 10 个要素，分别是版本号，序列号，签名算法标识，发行者名称，有效期，证书主体名，证书主体公钥信息，发行商唯一标识，主体唯一标识，扩展等。
2， signatureAlgorithm，签名算法标识，指定对 tbsCertificate 进行签名的算法。
3， signaturValue（签名值），使用 signatureAlgorithm 对 tbsCertificate 进行计算得到签名值。
数字证书有两个作用：
1， 身份授权。确保浏览器访问的网站是经过 CA 验证的可信任的网站。
2， 分发公钥。每个数字证书都包含了注册者生成的公钥。在 SSL 握手时会通过 certificate 消息传输给客户端。比如前文提到的 RSA 证书公钥加密及 ECDHE 的签名都是使用的这个公钥。
申请者拿到 CA 的证书并部署在网站服务器端，那浏览器发起握手接收到证书后，如何确认这个证书就是 CA 签发的呢？怎样避免第三方伪造这个证书？
答案就是数字签名（digital signature）。数字签名是证书的防伪标签，目前使用最广泛的 SHA-RSA 数字签名的制作和验证过程如下：
1， 数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用 CA 自己的私钥对消息摘要进行加密。
2， 数字签名的校验。使用 CA 的公钥解密签名，然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。
图 8 数字签名生成及校验
这里有几点需要说明：
- 数字签名签发和校验使用的密钥对是 CA 自己的公私密钥，跟证书申请者提交的公钥没有关系。
- 数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。
- 现在大的 CA 都会有证书链，证书链的好处一是安全，保持根 CA 的私钥离线使用。第二个好处是方便部署和撤销，即如果证书出现问题，只需要撤销相应级别的证书，根证书依然安全。
- 根 CA 证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。
- 怎样获取根 CA 和多级 CA 的密钥对？它们是否可信？当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的公钥都默认装到了浏览器或者操作系统环境里。比如firefox 就自己维护了一个可信任的 CA 列表，而chrome 和 IE 使用的是操作系统的 CA 列表。
4.3 数据完整性
这部分内容比较好理解，跟平时的 md5 签名类似，只不过安全要求要高很多。openssl 现在使用的完整性校验算法有两种：MD5 或者 SHA。由于 MD5 在实际应用中存在冲突的可能性比较大，所以尽量别采用 MD5 来验证内容一致性。SHA 也不能使用 SHA0 和 SHA1，中国山东大学的王小云教授在 2005 年就宣布破解了 SHA-1 完整版算法。
微软和 google 都已经宣布 16 年及 17 年之后不再支持 sha1 签名证书。
5 HTTPS 使用成本
HTTPS 目前唯一的问题就是它还没有得到大规模应用，受到的关注和研究都比较少。至于使用成本和额外开销，完全不用太过担心。
一般来讲，使用 HTTPS 前大家可能会非常关注如下问题：
- 证书费用以及更新维护。大家觉得申请证书很麻烦，证书也很贵，可是证书其实一点都不贵，便宜的一年几十块钱，最多也就几百。而且现在也有了免费的 证书机构，比如著名的 mozilla 发起的免费证书项目：let’s encrypt（https://letsencrypt.org/）就支持免费证书安装和自动更新。这个项目将于今年中旬投入正式使用。
数字证书的费用其实也不高，对于中小网站可以使用便宜甚至免费的数字证书服务（可能存在安全隐患），像著名的 verisign 公司的证书一般也就几千到几万块一年不等。当然如果公司对证书的需求比较大，定制性要求高，可以建立自己的 CA 站点，比如 google，能够随意签发 google 相关证书。
