HTTPS协议和原理(7)
4、浏览器使用证书公钥 P 将 premaster_secrect 加密后发送给服务器。
5、服务端使用私钥解密得到 premaster_secrect。又由于服务端之前就收到了随机数 1，所以服务端根据相同的生成算法，在相同的输入参数下，求出了相同的 master secrect。
RSA 密钥协商握手过程图示如下：
图 6 RSA 密钥协商过程
可以看出，密钥协商过程需要 2 个 RTT，这也是 HTTPS 慢的一个重要原因。而 RSA 发挥的关键作用就是对 premaster_secrect 进行了加密和解密。中间者不可能破解 RSA 算法，也就不可能知道 premaster_secrect，从而保证了密钥协商过程的安全性。
4.1.1.2 ECDHE 密钥协商
4.1.1.2.1 DH 与 ECC 算法原理
ECDHE 算法实现要复杂很多，主要分为两部分：diffie-hellman 算法(简称为 DH)及 ECC(椭圆曲线算术)。他们的安全性都是建立在离散对数计算很困难的基础上。
简单介绍一下 dh 算法的实现，先介绍两个基本概念：
本原根：如果整数 a 是素数 p 的本原根，则 a, a^2, …, a^(p-1) 在 mod p 下都不相同。
离散对数：对任意整数 b 和素数 p 的本原根 a，存在唯一的指数 i 满足:
b ≡ a^i mod p (0≤i≤p-1)
则称 i 是 b 的以 a 为底的模 p 的离散对数。
理解这两个概念，dh 算法就非常简单了，示例如下：
假设 client 和 server 需要协商密钥，p=2579，则本原根 a = 2。
1、Client 选择随机数 Kc = 123 做为自己的私钥，计算 Yc = a^Kc mod p = 2^123 mod 2579 = 2400，把 Yc 作为公钥发送给 server。
2、Server 选择随机数 Ks = 293 作为私钥，计算 Ys = a^Ks mod p = s^293 mod 2579 = 968，把 Ys 作为公钥发送给 client。
3、Client 计算共享密钥：secrect = Ys^Kc mod (p) = 968^123 mod(2579) = 434
4、Server 计算共享密钥：secrect = Yc^Ks mod(p) =2400^293 mod(2579) =434
上述公式中的 Ys,Yc,P, a, 都是公开信息，可以被中间者查看，只有 Ks,Kc 作为私钥没有公开，当私钥较小时，通过穷举攻击能够计算出共享密钥，但是当私钥非常大时，穷举攻击肯定是不可行的。
DH 算法有一个比较大的缺陷就是需要提供足够大的私钥来保证安全性，所以比较消耗 CPU 计算资源。ECC 椭圆曲线算术能够很好的解决这个问题，224 位的密钥长度就能达到 RSA2048 位的安全强度。
ECC 的曲线公式描述的其实不是椭圆，只是跟椭圆曲线周长公式形似才叫椭圆曲线加密算术。ECC 涉及到了有限域、群等近世代数的多个概念，就不做详细介绍了。
ECC 安全性依赖于这样一个事实：
P = kQ, 已知 k, Q 求出 P 相对简单，但是已知 P 和 Q 求出 k 却非常困难。
上式看起来非常简单，但有如下约束条件：
1、Q 是一个非常大的质数，p, k, q 都是椭圆曲线有限域上的离散点。
2、有限域定义了自己的加法和乘法法则，即使 kQ 的运算也非常复杂。
ECC 应用于 Diffie-Hellman 密钥交换过程如下：
1、定义一个满足椭圆方程的有限域，即挑选 p, a, b 满足如下方程：
y^2 mod p = (x^3+ax +b) mod p
2、挑选基点 G = (x, y)，G 的阶为 n。n 为满足 nG = 0 的最小正整数。
3、Client 选择私钥 Kc (0
4、server 选择私钥 Ks 并产生公钥 Ys =Ks*G
5、client 计算共享密钥 K = Kc*Ys ，server 端计算共享密钥 Ks*Yc ，这两者的结果是一样的，因为：
Kc*Ys = Kc*(Ks*G) = Ks*(Kc*G) = Ks*Yc
由上面描述可知，只要确定 p, a, b 就能确定一条有限域上的椭圆曲线，由于不是所有的椭圆曲线都能够用于加密，所以 p, a, b 的选取非常讲究，直接关系曲线的安全性和计算速度。
Openssl 实现的，也是 FIPS 推荐的 256 位素数域上的椭圆曲线参数定义如下：
质数 p = 115792089210356248762697446949407573530086143415290314195533631308867097853951 阶 n = 115792089210356248762697446949407573529996955224135760342422259061068512044369SEED = c49d3608 86e70493 6a6678e1 139d26b7 819f7e90c = 7efba166 2985be94 03cb055c 75d4f7e0 ce8d84a9 c5114abcaf317768 0104fa0d 椭圆曲线的系数 a = 0 椭圆曲线的系统 b = 5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f63bce3c3e 27d2604b 基点 G x = 6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0f4a13945 d898c296 基点 G y = 4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ececbb64068 37bf51f5
4.1.1.2.2 握手过程中的 ECDHE 密钥协商
简单介绍了 ECC 和 DH 算法的数学原理，我们看下 ECDHE 在 TLS 握手过程中的应用。
相比 RSA，ECDHE 需要多发送一个 server_key_exchange 的握手消息才能完成密钥协商。
同样以 TLS1.2 为例，简单描述一下过程：
1、浏览器发送 client_hello，包含一个随机数 random1，同时需要有 2 个扩展：
a) Elliptic_curves：客户端支持的曲线类型和有限域参数。现在使用最多的是 256 位的素数域，参数定义如上节所述。
b) Ec_point_formats：支持的曲线点格式，默认都是 uncompressed。
2、服务端回复 server_hello，包含一个随机数 random2 及 ECC 扩展。
3、服务端回复 certificate，携带了证书公钥。
4、服务端生成 ECDH 临时公钥，同时回复 server_key_exchange，包含三部分重要内容：
a) ECC 相关的参数。
b) ECDH 临时公钥。
c) ECC 参数和公钥生成的签名值，用于客户端校验。
5、浏览器接收 server_key_exchange 之后，使用证书公钥进行签名解密和校验，获取服务器端的 ECDH 临时公钥，生成会话所需要的共享密钥。
至此，浏览器端完成了密钥协商。
6、浏览器生成 ECDH 临时公钥和 client_key_exchange 消息，跟 RSA 密钥协商不同的是，这个消息不需要加密了。
7、服务器处理 client_key_exchang 消息，获取客户端 ECDH 临时公钥。
8、服务器生成会话所需要的共享密钥。
9、Server 端密钥协商过程结束。
图示如下：
图 7 ECDHE 密钥协商过程
4.1.2 对称内容加密
非对称密钥交换过程结束之后就得出了本次会话需要使用的对称密钥。对称加密又分为两种模式：流式加密和分组加密。流式加密现在常用的就是 RC4，不过 RC4 已经不再安全，微软也建议网站尽量不要使用 RC4 流式加密。
一种新的替代 RC4 的流式加密算法叫 ChaCha20，它是 google 推出的速度更快，更安全的加密算法。目前已经被 android 和 chrome 采用，也编译进了 google 的开源 openssl 分支 —boring ssl，并且nginx 1.7.4 也支持编译 boringssl。
分组加密以前常用的模式是 AES-CBC，但是 CBC 已经被证明容易遭受BEAST和LUCKY13 攻击。目前建议使用的分组加密模式是 AES-GCM，不过它的缺点是计算量大，性能和电量消耗都比较高，不适用于移动电话和平板电脑。
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 前大家可能会非常关注如下问题：
1、证书费用以及更新维护。大家觉得申请证书很麻烦，证书也很贵，可是证书其实一点都不贵，便宜的一年几十块钱，最多也就几百。而且现在也有了免费的证书机构，比如著名的 mozilla 发起的免费证书项目：let’s encrypt(https://letsencrypt.org/)就支持免费证书安装和自动更新。这个项目将于今年中旬投入正式使用。
数字证书的费用其实也不高，对于中小网站可以使用便宜甚至免费的数字证书服务(可能存在安全隐患)，像著名的 verisign 公司的证书一般也就几千到几万块一年不等。当然如果公司对证书的需求比较大，定制性要求高，可以建立自己的 CA 站点，比如 google，能够随意签发 google 相关证书。
2、HTTPS 降低用户访问速度。HTTPS 对速度会有一定程度的降低，但是只要经过合理优化和部署，HTTPS 对速度的影响完全可以接受。在很多场景下，HTTPS 速度完全不逊于 HTTP，如果使用 SPDY，HTTPS 的速度甚至还要比 HTTP 快。
大家现在使用百度 HTTPS 安全搜索，有感觉到慢吗?
3、HTTPS 消耗 CPU 资源，需要增加大量机器。前面介绍过非对称密钥交换，这是消耗 CPU 计算资源的大户，此外，对称加解密，也需要 CPU 的计算。
同样地，只要合理优化，HTTPS 的机器成本也不会明显增加。对于中小网站，完全不需要增加机器也能满足性能需求。
6 后记
国外的大型互联网公司很多已经启用了全站 HTTPS，这也是未来互联网的趋势。国内的大型互联网并没有全站部署 HTTPS，只是在一些涉及账户或者交易的子页面 / 子请求上启用了 HTTPS。百度搜索首次全站部署 HTTPS，对国内互联网的全站 HTTPS 进程必将有着巨大的推动作用。
目前互联网上关于 HTTPS 的中文资料比较少，本文就着重介绍了 HTTPS 协议涉及到的重要知识点和平时不太容易理解的盲区，希望能对大家理解 HTTPS 协议有帮助。百度 HTTPS 性能优化涉及到大量内容，从前端页面、后端架构、协议特性、加密算法、流量调度、架构和运维、安全等方面都做了大量工作。本系列的文章将一一进行介绍。S，这也是未来互联网的趋势。国内的大型互联网并没有全站部署 HTTPS，只是在一些涉及账户或者交易的子页面 / 子请求上启用了 HTTPS。百度搜索首次全站部署 HTTPS，对国内互联网的全站 HTTPS 进程必将有着巨大的推动作用。
目前互联网上关于 HTTPS 的中文资料比较少，本文就着重介绍了 HTTPS 协议涉及到的重要知识点和平时不太容易理解的盲区，希望能对大家理解 HTTPS 协议有帮助。百度 HTTPS 性能优化涉及到大量内容，从前端页面、后端架构、协议特性、加密算法、流量调度、架构和运维、安全等方面都做了大量工作。本系列的文章将一一进行介绍。