2、HTTPS能有效保护用户隐私

HTTPS就等于HTTP加上TLS(SSL)，HTTPS协议的目标主要有三个：

● 数据保密性。保证内容在传输过程中不会被第三方查看到。就像快递员传递包裹时都进行了封装，别人无法知道里面装了什么东西。

● 数据完整性。及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收。

● 身份校验。保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方。

通俗地描述上述三个目标就是封装加密，防篡改掉包，防止身份冒充，那TLS是如何做到上述三点的呢？我分别简述一下。

　　2.1 数据保密性

　　2.1.1 非对称加密及密钥交换

数据的保密性主要是通过加密完成的。加密算法一般分为两种，一种是非对称加密(也叫公钥加密)，另外一种是对称加密(也叫密钥加密)。所谓非对称加密就是指加密和解密使用的密钥不一样，如下图：

 

HTTPS使用非对称加解密主要有两个作用，一个是密钥协商，另外可以用来做数字签名。所谓密钥协商简单说就是根据双方各自的信息计算得出双方传输内容时对称加解密需要使用的密钥。 公钥加密过程一般都是服务器掌握私钥，客户端掌握公钥，私钥用来解密，公钥用来加密。公钥可以发放给任何人知道，但是私钥只有服务器掌握，所以公钥加解密非常安全。当然这个安全性必须建立在公钥长度足够大的基础上，目前公钥最低安全长度也需要达到2048位。大的CA也不再支持2048位以下的企业级证书申请。因为1024位及以下的公钥长度已经不再安全，可以被高性能计算机比如量子计算机强行破解。计算性能基本会随着公钥的长度而呈2的指数级下降。

既然如此为什么还需要对称加密？为什么不一直使用非对称加密算法来完成全部的加解密过程？主要是两点：

1、非对称加解密对性能的消耗非常大，一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的95%。而对称加密的计算量只相当于非对称加密的0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。

2、非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。

目前常用的非对称加密算法是RSA，想强调一点的就是RSA是整个PKI体系及加解密领域里最重要的算法。如果想深入理解HTTPS的各个方面，RSA是必需要掌握的知识点。它的原理主要依赖于三点：

1、乘法的不可逆特性。即我们很容易由两个乘数求出它们的积，但是给定一个乘积，很难求出它是由哪两个乘数因子相乘得出的。

2、欧拉函数。欧拉函数 是小于或等于n的正整数中与n 互质 的数的数目

3、费马小定理。假如a是一个整数，p是一个质数，那么 是p的倍数。

这篇中文博客对RSA的原理解释得比较清楚易懂： RSA算法原理 。

RSA算法是第一个也是目前唯一一个既能用于密钥交换又能用于数字签名的算法。另外一个非常重要的密钥协商算法是diffie-hellman(DH).DH不需要预先知道通信双方的信息就能完成密钥的协商，它使用一个素数P的整数乘法群以及原根G，理论依据就是离散对数。

openssl目前只支持如下密钥交换算法：RSA，DH，ECDH， DHE，ECDHE。各个算法的性能和对速度的影响可以参考后面章节，由于篇幅有限，具体实现不再做详细介绍。

　　2.1.2 对称加密

对称加密就是加密和解密都使用的是同一个密钥。如下图：

 

采用非对称密码算法的密钥协商过程结束之后就已经得出了本次会话需要使用的对称密钥。对称加密又分为两种模式：流式加密和分组加密。流式加密现在常用的就是RC4，不过 RC4已经不再安全 ，微软也 建议网站尽量不要使用RC4流式加密 。支付宝可能没有意识到这一点，也可能是由于其他原因，他们仍然在使用RC4算法和TLS1.0协议。

 

一种新的替代RC4的流式加密算法叫ChaCha20，它是google推出的速度更快，更安全的加密算法。目前已经被android和chrome采用，也编译进了google的开源openssl分支---boring ssl，并且 nginx 1.7.4也支持编译boringssl 。我目前还没有比较这种算法的性能，但部分资料显示这个算法对性能的消耗比较小，特别是移动端提升比较明显。

分组加密以前常用的模式是AES-CBC，但是CBC已经被证明容易遭受 BEAST 和LUCKY13攻击 。目前建议使用的分组加密模式是AES-GCM，不过它的缺点是计算量大，性能和电量消耗都比较高，不适用于移动电话和平板电脑。尽管如此，它仍然是我们的优先选择。

　　2.2 数据完整性

这部分内容相对比较简单，openssl现在使用的完整性校验算法有两种：MD5或者SHA。由于MD5在实际应用中存在冲突的可能性比较大，所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA1，中国山东大学的王小云教授在2005年就牛逼地宣布破解了SHA-1完整版算法。建议使用SHA2算法，即输出的摘要长度超过224位。

　　2.3 身份验证和授权

这里主要介绍的就是PKI和数字证书。数字证书有两个作用：

1、身份验证。确保客户端访问的网站是经过CA验证的可信任的网站。

2、分发公钥。每个数字证书都包含了注册者生成的公钥。在SSL握手时会通过certificate消息传输给客户端。

这里简单介绍一下数字证书是如何验证网站身份的。

证书申请者首先会生成一对密钥，包含公钥和密钥，然后把公钥及域名还有CU等资料制作成CSR格式的请求发送给RA，RA验证完这些内容之后(RA会请独立的第三方机构和律师团队确认申请者的身份)再将CSR发送给CA，CA然后制作X.509格式的证书。

那好，申请者拿到CA的证书并部署在网站服务器端，那浏览器访问时接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？

答案就是数字签名(digital signature)。数字签名可以认为是一个证书的防伪标签，目前使用最广泛的SHA-RSA数字签名的制作和验证过程如下：

1、数字签名的签发。首先是使用哈希函数对证书数据哈希，生成消息摘要，然后使用CA自己的私钥对证书内容和消息摘要进行加密。

2、数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对证书内容进行签名并和服务端的数字签名里的签名内容进行比较，如果相同就认为校验成功。

图形表示如下：

 

这里有几点需要说明：

1、数字签名签发和校验使用的密钥对是CA自己的公私密钥，跟证书申请者提交的公钥没有关系。

2、数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。

3、现在大的CA都会有证书链，证书链的好处一是安全，保持根CA的私钥离线使用。第二个好处是方便部署和撤销，即如何证书出现问题，只需要撤销相应级别的证书，根证书依然安全。

4、根CA证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。

5、怎样获取根CA和多级CA的密钥对？它们是否可信？当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的公钥都默认装到了浏览器或者操作系统环境里。比如 firefox就自己维护了一个可信任的CA列表 ，而 chrome和IE使用的是操作系统的CA列表 。

数字证书的费用其实也不高，对于中小网站可以使用 便宜甚至免费的数字证书服务(可能存在安全隐患)，像著名的verisign公司的证书一般也就几千到几万块一年不等。当然如果公司对证书的需求比较大，定制性要求高，可以建立自己的CA站点，比如google，能够随意签发google相关证书。

(责任编辑：安博涛)