3、写在前面
说到HTTPS，那就得回到HTTP协议。
对于HTTP协议，大家肯定都熟得不能再熟了。那么HTTPS和HTTP的区别大家了解吗？
对于这个经典的面试题，大部分人会这么回答：
- 1）HTTPS比HTTP多了一个S(Secure)：也就是说HTTPS是安全版的HTTP；
- 2）端口号不同：HTTP使用80端口，HTTPS使用443端口；
- 3）加密算法：HTTPS用的是非对称加密算法。
上面的回答能给几分？等看完本文我们可以再回头来看下这个回答。
那么，HTTPS是如何实现安全的短连接数据传输呢？想彻底搞明白这个问题，还是要从HTTP的发展历程说起 ......
4、HTTP协议回顾
4.1基础常识
HTTP是Hypertext Transfer Protocal 的缩写，中文全称是超文本传输协议（详见《深入浅出，全面理解HTTP协议》）。
通俗了解释就是：
- 1）超文本是指包含但不限于文本外的图片、音频、视频等多媒体资源；
- 2）协议是通信双方约定好的数据传输格式以及通信规则。
HTTP是TCP/IP协议簇的最高层——应用层协议：
<ignore_js_op>
▲ 上图引用自《深入浅出，全面理解HTTP协议》
浏览器和服务器在使用HTTP协议相互传递超文本数据时，将数据放入报文体内，同时填充首部（请求头或响应头）构成完整HTTP报文并交到下层传输层，之后每一层加上相应的首部（控制部分）便一层层的下发，最终由物理层将二进制数据以电信号的形式发送出去。
HTTP的请求如下图所示：
<ignore_js_op>
▲ 上图引用自《深入浅出，全面理解HTTP协议》
HTTP报文结构如下
<ignore_js_op>
4.2发展历程
HTTP的发展历程如下：
<ignore_js_op>
由HTTP的发展历程来看，最开始版本的HTTP(HTTP1.0)在每次建立TCP连接后只能发起一次HTTP请求，请求完毕就释放TCP连接。
我们都知道TCP连接的建立需要经过三次握手的过程，而每次发送HTTP请求都需要重新建立TCP连接，毫无疑问是很低效的。所以HTTP1.1改善了这一点，使用长连接的机制，也就是“一次TCP连接，N次HTTP请求”。
HTTP协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
PS：对于IM开发者来说，为了与Socket长连接通道区分，通常认为HTTP就是“短连接”（虽然这个“短连接”不一定真的“短”）。
HTTP1.0若要开启长连接，需要加上Connection: keep-alive请求头。有关HTTP协议的详细发展历程可阅读《一文读懂HTTP协议的历史演变和设计思路》一文。
4.3安全问题
随着HTTP越来越广泛的使用，HTTP的安全性问题也逐渐暴露。
回忆一下多年前遍地都是的运营商劫持，当你访问一个本来很正常的网页，但页面上却莫名其妙出现了一些广告标签、跳转脚本、欺骗性的红包按钮，甚至有时候本来要下载一个文件，最后下载下来却变成了另外一个完全不同的东西，这些都是被运营商劫持了HTTP明文数据的现象。
下图就是似曾相识的运营商劫持效果图：
<ignore_js_op>
PS：关于运营商劫持问题，可以详细阅读《全面了解移动端DNS域名劫持等杂症：原理、根源、HttpDNS解决方案等》。
HTTP主要有以下3点安全性问题：
<ignore_js_op>
归纳一下就是：
- 1）数据保密性问题：因为HTTP无状态，而且又是明文传输，所有数据内容都在网络中裸奔，包用户括身份信息、支付账号与密码。这些敏感信息极易泄露造成安全隐患；
- 2）数据完整性问题：HTTP数据包在到达目的主机前会经过很多转发设备，每一个设备节点都可能会篡改或调包信息，无法验证数据的完整性；
- 3）身份校验问题：有可能遭受中间人攻击，我们无法验证通信的另一方就是我们的目标对象。
因此，为了保证数据传输的安全性，必须要对HTTP数据进行加密。
5、常见的加密方式
5.1基本情况
常见的加密方式分为三种：
- 1）对称加密；
- 2）非对称加密；
- 3）数字摘要。
前两种适合数据传输加密，而数字摘要不可逆的特性常被用于数字签名。
接下来，我们逐一简要学习一下这三种常见的加密方法。
5.2对称加密
对称加密也称为密钥加密或单向加密，就是使用同一套密钥来进行加密和解密。密钥可以理解为加密算法。
对称加密图示如下
广泛使用的对称加密有：
对称加密算法的优缺点和适用场景：
- 1）优点：算法公开、简单，加密解密容易，加密速度快，效率高；
- 2）缺点：相对来说不算特别安全，只有一把钥匙，密文如果被拦截，且密钥也被劫持，那么，信息很容易被破译；
- 3）适用场景：加解密速度快、效率高，因此适用于大量数据的加密场景。由于如何传输密钥是较为头痛的问题，因此适用于无需进行密钥交换的场景，如内部系统，事先就可以直接确定密钥。
PS：可以在线体验对称加密算法，链接是：http://www.jsons.cn/textencrypt/
小知识：base64编码也属于对称加密哦！
5.3非对称加密
非对称加密使用一对密钥（公钥和私钥）进行加密和解密。
非对称加密可以在不直接传递密钥的情况下，完成解密，具体步骤如下：
- 1）乙方生成两把密钥（公钥和私钥）。公钥是公开的，任何人都可以获得，私钥则是保密的；
- 2）甲方获取乙方的公钥，然后用它对信息加密；
- 3）乙方得到加密后的信息，用私钥解密。
以最典型的非对称加密算法RSA为例，举个例子：
想要彻底搞懂RSA，需要了解数论的知识，全部推导过程RSA加密算法。简单介绍思路：使用两个超大质数以及其乘积作为生成公钥和私钥的材料，想要从公钥推算出私钥是非常困难的（需要对超大数因式分解为两个很大质数的乘积）。目前被破解的最长RSA密钥是768个二进制位。也就是说，长度超过768位的密钥，还无法破解（至少没人公开宣布）。因此可以认为，1024位的RSA密钥基本安全，2048位的密钥极其安全。
非对称加密算法的优缺点和适用场景：
- 1）优点：强度高、安全性强于对称加密算法、无需传递私钥导致没有密钥泄露风险；
- 2）缺点：计算量大、速度慢；
- 3）适用场景：适用于需要密钥交换的场景，如互联网应用，无法事先约定密钥。
实践应用过程中，其实可以与对称加密算法结合：
- 1）利用非对称加密算法安全性较好的特点来传递对称加密算法的密钥。
- 2）利用对称加密算法加解密速度快的特点，进行数据内容比较大的加密场景的加密（如HTTPS）。
PS：对于IM开发者来说，《探讨组合加密算法在IM中的应用》一文值得一读。
5.4如何选择？
1）如果选择对称加密：
HTTP请求方使用对称算法加密数据，那么为了接收方能够解密，发送方还需要把密钥一同传递到接收方。在传递密钥的过程中还是可能遭到嗅探攻击，攻击者窃取密钥后依然可以解密从而得到发送的数据，所以这种方案不可行。
2）如果选择非对称加密：
接收方保留私钥，把公钥传递给发送方。发送方用公钥来加密数据，接收方使用私钥解密数据。攻击者虽然不能直接获取这些数据（因为没有私钥），但是可以通过拦截传递的公钥，然后把自己的公钥传给发送方，再用自己的私钥对发送方发送数据进行解密。
整个过程通信双方都不知道中间人的存在，但是中间人能够获得完整的数据信息。
<ignore_js_op>
3）两种加密方法的混合：
先使用非对称加密算法加密并传递对称加密的密钥，然后双方通过对称加密方式加密要发送的数据。看起来没什么问题，但事实是这样吗？
中间人依然可以拦截公钥的传递，并以自己的公钥作为替换，治标不治本。
想要治本，就要找到一个第三方公证人来证明公钥没有被替换，因此就引出了数字证书的概念，这也是下一节将分享的内容。
6、数字证书
6.1CA机构
CA就是 Certificate Authority，即颁发数字证书的机构。
作为受信任的第三方，CA承担公钥体系中公钥的合法性检验的责任。
证书就是源服务器向可信任的第三方机构申请的数据文件。这个证书除了表明这个域名是属于谁的，颁发日期等，还包括了第三方证书的私钥。
服务器将公钥放在数字证书中，只要证书是可信的，公钥就是可信的。
下面两图是飞书域名的证书中部分内容的信：
<ignore_js_op>
<ignore_js_op>
6.2数字签名
摘要算法：一般用哈希函数来实现，可以理解成一种定长的压缩算法，它能把任意长度的数据压缩到固定长度。这好比是给数据加了一把锁，对数据有任何微小的改动都会使摘要变得截然不同。
通常情况下：数字证书的申请人（服务器）将生成由私钥和公钥以及证书请求文件（Certificate Signing Request，CSR）组成的密钥对。CSR是一个编码的文本文件，其中包含公钥和其他将包含在证书中的信息（例如：域名、组织、电子邮件地址等）。密钥对和CSR生成通常在将要安装证书的服务器上完成，并且 CSR 中包含的信息类型取决于证书的验证级别。与公钥不同，申请人的私钥是安全的，永远不要向 CA（或其他任何人）展示。
生成 CSR 后：申请人将其发送给 CA，CA 会验证其包含的信息是否正确，如果正确，则使用颁发的私钥对证书进行数字签名，然后将签名放在证书内随证书一起发送给申请人。
<ignore_js_op>
在SSL握手阶段：浏览器在收到服务器的证书后，使用CA的公钥进行解密，取出证书中的数据、数字签名以及服务器的公钥。如果解密成功，则可验证服务器身份真实。之后浏览器再对数据做Hash运算，将结果与数字签名作对比，如果一致则可以认为内容没有收到篡改。
对称加密和非对称加密是公钥加密、私钥解密， 而数字签名正好相反——是私钥加密（签名）、公钥解密（验证），如下图所示。
<ignore_js_op>
限于篇幅，关于数字证书的内容本文就不再赘述，想详细了解的可以阅读：
7、为什么要使用HTTPS
《图解HTTP》一书中提到HTTPS就是身披SSL外壳的HTTP。
<ignore_js_op>
7.1SSL
SSL 在1999年被更名为TLS。
所以说：HTTPS 并不是一项新的应用层协议，只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。
具体就是：HTTP 会先直接和 TCP 进行通信，而HTTPS 会演变为先和 SSL 进行通信，然后再由 SSL 和 TCP 进行通信。
SSL是一个独立的协议，不只有 HTTP 可以使用，其他应用层协议也可以使用，比如FTP、SMTP都可以使用SSL来加密。
<ignore_js_op>
7.2HTTPS请求流程
HTTPS请求全流程如下图：
<ignore_js_op>
如上图所示：
- 1）用户在浏览器发起HTTPS请求，默认使用服务端的443端口进行连接；
- 2）HTTPS需要使用一套CA 数字证书，证书内会附带一个服务器的公钥Pub，而与之对应的私钥Private保留在服务端不公开；
- 3）服务端收到请求，返回配置好的包含公钥Pub的证书给客户端；
- 4）客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示HTTPS警告信息，如果通过则继续；
- 5）客户端生成一个用于对称加密的随机Key，并用证书内的公钥Pub进行加密，发送给服务端；
- 6）服务端收到随机Key的密文，使用与公钥Pub配对的私钥Private进行解密，得到客户端真正想发送的随机Key；
- 7）服务端使用客户端发送过来的随机Key对要传输的HTTP数据进行对称加密，将密文返回客户端；
- 8）客户端使用随机Key对称解密密文，得到HTTP数据明文；
- 9）后续HTTPS请求使用之前交换好的随机Key进行对称加解密。
7.3HTTPS到底解决了什么问题
HTTPS确实解决了HTTP的三个安全性问题：
- 1） 保密性：结合非对称加密和对称加密实现保密性。用非对称加密方式加密对称加密的秘钥，再用对称加密方式加密数据；
- 2） 完整性：通过第三方CA的数字签名解决完整性问题；
- 3） 身份校验：通过第三方CA的数字证书验证服务器的身份。
7.4HTTPS优缺点
最后我们总结一下HTTPS的优缺点：
<ignore_js_op>
可以看到：HTTPS的确是当今安全传输HTTP的最优解，但他并不是完美的，仍会有漏洞。