HTTPS是如何保证数据传输安全的？

1. HTTP存在的问题

传统的不使用SSL/TLS的HTTP协议，是不加密的通讯。不管是客户端发送给服务端的请求体，仍是服务端响应给客户端的响应体，都是明文传输的，这会带来几个问题：

1. 窃听 第三方劫持请求后能够获取通讯内容。对于一些敏感数据，这是不被容许的。

2. 篡改 第三方劫持请求后能够篡改通讯内容。例如银行系统中，张三原本要给李四转帐，第三方劫持请求后篡改了请求数据，将收款方改成本身，致使用户资金流失。

3. 冒充 第三方能够冒充客户端发送数据。因为是明文传输，没有「加签/验签」操做，服务端没法保证请求来源的合法性。

正是由于这些问题，HTTP通讯存在巨大的安全隐患，因而HTTPS出现了。 本文将一步步深刻，看看HTTPS是如何解决这些问题的。

---

2. SSL/TLS

在介绍HTTPS以前，必须先了解SSL/TLS协议，由于HTTPS是构建在此基础之上的，了解了SSL/TLS基本也就清楚HTTPS的工做原理了。

SSL（Secure Sockets Layer）译为「安全套接字协议」，TLS（Transport Layer Security）译为「传输层安全性协议」。

简单回顾一下它们的发展历史吧：

• 1994年，网景公司设计了SSL协议（Secure Sockets Layer）的1.0版，可是未发布。
• 1995年，网景公司发布SSL 2.0版，但很快发现有严重漏洞。
• 1996年，SSL 3.0版问世，获得大规模应用。
• 1999年，互联网标准化组织ISOC接替网景公司，发布了SSL的升级版TLS 1.0版。
• 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。

SSL/TLS协议处于「传输层」和「应用层」之间，主要做用是对网络链接进行加解密，以下图：

2.1 防窃听：加密

先来看看第一个问题：窃听。既然明文传输能够被第三方窃听数据，那么改成加密传输不就好了吗？ 方向是对的，可是如何加密才能保证数据的安全呢？

2.1.1 对称加密

采用单钥密码系统的加密方法，同一个密钥能够同时用做信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。

例如DES就是一种对称加密算法，甲乙双方约定一个密钥「Key」，双方发送数据前都用该密钥对数据进行加密传输，收到数据后再解密成明文便可。这种方式，只要保证密钥不被泄漏，理论上也是安全的。

可是这会带来一个新的问题：密钥如何保存？

对于PC端来讲，浏览器页面是明文的，确定不能存储密钥。对于iOS/Android来讲，即便把密钥藏在安装包的某个位置，也很容易被第三方拆包破解。

既然客户端保存不靠谱，那么密钥只在服务端保存，客户端去向服务端拿密钥是否可行？

依然不可行，服务端要怎么把密钥给你呢？明文确定不行，若是要加密，又要用到密钥B，密钥B的传输又要用到密钥C，如此循环，无解。

2.1.2 非对称加密

非对称加密算法须要两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。公钥与私钥是一对，若是用公钥对数据进行加密，只有用对应的私钥才能解密。由于加密和解密使用的是两个不一样的密钥，因此这种算法叫做非对称加密算法。

甲乙双方各有一套本身的密钥对，互相公开彼此的公钥，当甲方要发送数据给乙方时，用乙方公钥加密，这样密文就只有乙方本身能解开了，就算请求被劫持，第三方拿到了数据，因为没有乙方的私钥，也没法解密，这样就保证了数据被窃听。

单向非对称加密 绝大多数互联网网站对外是彻底公开的，全部人均可以访问，服务端不必验证全部客户端的合法性，只有客户端须要验证服务端的合法性。例如用户在访问电商网站时，必须确保不是钓鱼网站，以防资金损失。

这种状况下，只须要单向加密便可。服务端发送给客户端的通常不会有敏感信息，明文传输便可。可是客户端发送给服务端的就颇有多是敏感信息，例如用户修改密码，这时就必须加密传输了。

双向非对称加密 有时，服务端也须要验证客户端的合法性，例如银行系统。因为涉及到金钱，所以系统必须设计的足够安全。除了客户端发送给服务端的数据是加密的，服务端发送给客户端的数据也必须加密。

怎么作的呢？通常银行会给用户一个U盘，里面存储的就是一套密钥对，客户端告诉服务端本身的公钥，服务端根据公钥加密后再传输给客户端。

2.2 防篡改：加签

经过非对称加密的密文传输，能够防止数据被窃听，可是若是存在这种场景呢？

张三登录银行系统，要给李四转一笔钱，数据经过服务端的公钥PubB加密传输，可是第三方劫持了这个请求，篡改了报文数据，写入的是「给王五转钱」，由于服务端的公钥是公开的，谁都能拿到，所以第三方也能够正常加密传输，服务端正常解密后进行了错误的操做，致使用户资金流失。

对于涉及到资金的操做，服务端必需要验证数据的合法性，确保数据没有被篡改，这就须要客户端对数据进行加签了。

非对称加密除了能够「公钥加密，私钥解密」外，还能够「私钥加签，公钥验签」。

银行给用户一个U盘，里面有一套密钥对。客户端在发送转帐请求前，先对请求体加签，获得签名「sign」，而后再用服务端公钥加密，获得密文「data」，客户端将签名和密文一块儿发送给服务端，服务端解密后，还须要用客户端的公钥对「sign」进行验签，只有验签经过才能进行后续操做，不然就是非法请求了。 这样，即便请求被第三方劫持了，第三方能够篡改数据，可是签名它改不了，服务端解密后会发现数据和「sign」对不上，说明数据是被篡改过的。

2.3 防冒充：证书

经过加密防止数据被窃听，经过加签防止数据被篡改，如今看来好像已经很安全了，可是别忘了，有个前提是：公钥的传输是安全的。不幸的是，公钥的安全传输很难保证。

中间人攻击 假设存在这样一种场景，客户端和服务端想互换公钥，可是请求都被一个中间人劫持了，结果就是：服务端和客户端觉得是和双方互换公钥了，结果是客户端和服务端都和中间人互换公钥了。 一旦出现这种问题就很是严重，前面讲到的加密解密、加签验签都失效了。客户端觉得中间人就是服务端，服务端觉得中间人就是客户端，双方觉得是在和对方通讯，其实都是在和中间人通讯，中间人能够随意的窃听和篡改数据。

这个问题之因此会出现，就是由于公钥的传输是不安全的。客户端和服务端之间互换公钥时，如何确保公钥就是对方发出的，没有被篡改过呢？？？

2.3.1 数字证书与认证中心

在以前的基础上，引入一个中间角色：证书认证中心CA。当服务端要把公钥发送给客户端时，不是直接发送公钥，而是先把公钥发送给CA，CA根据公钥生成一份「证书」给到服务端，服务端将证书给客户端。客户端拿到证书后去CA验证证书的合法性，确保证书是服务端下发的。

CA就相似于「公证处」，也是一台服务器，它本身自己也有一套密钥对。它的工做就是根据服务端的公钥生成证书，而后帮助客户端来验证证书的合法性。

2.3.2 CA被冒充怎么办？

引入CA能够保证公钥的传输安全，可是有一个前提，客户端和服务端是信任CA的，也就是说CA必须是安全可信任的，若是CA被冒充，就又会出现上面的问题。 基于这个问题，就引入了「根证书」和「CA信任链」的概念。

要让客户端和服务端信任CA，其实CA也面临着一样的问题，那就是：如何保证CA的公钥是安全不被篡改的？答案也是同样的，就是给CA也颁发证书，那这个证书由谁来颁发呢？天然是CA的上一级CA了。CA的上一级CA如何保证安全？那就CA的上一级CA的上一级CA给它颁发证书了。最终就会造成一个证书信用链，以下： 客户端要想验证服务器的C3证书是否合法，会跑去CA2验证，要验证CA2就去CA1验证，以此类推。对于根证书，是无法验证的，只能无条件相信。由于Root CA都是国际上公认的机构，通常用户的操做系统或浏览器在发布时，就会在里面嵌入这些机构的Root证书。

以下是百度官网的证书，点击浏览器地址栏旁边的锁标识就能看到了。

2.4 SSL/TLS 四次握手

了解了底层的实现，加密、加签、证书等概念后，再来看SSL/TLS协议就很容易理解了。SSL/TLS须要四次握手的过程：

1. 客户端向服务端全部证书。
2. 服务端发送证书。
3. 客户端验证证书，提取公钥，发送对称加密的密钥。
4. 服务端收到密钥，响应OK。

3. 再看HTTPS

了解SSL/TLS，再回过头来看HTTPS就很简单了，HTTPS=HTTP+SSL/TLS。

使用HTTPS进行通讯时，先是创建传输层TCP的链接，完成三次握手，而后再是SSL/TLS协议的四次握手，双方协商出对称加密的密钥，以后的通讯数据会利用该密钥进行加密传输。 HTTP1.1开始支持长链接了，只要链接不关闭，七次握手只须要执行一次，性能损耗不会太大，并且数据传输采用的是对称加密，相比于非对称加密，性能损耗也小得多。所以HTTPS相比于HTTP，性能会有必定影响，但不会太大，相比之下，数据传输安全显得更加剧要！