最近在梳理计算机网络相关知识，刚好梳理到 HTTPS 这一块，关于 HTTPS，在我的概念中就是更安全，需要服务器配置证书，但是到底什么是 HTTPS，为什么会更安全，整套流程又是如何实现的，在脑子里没有具体的概念，所以打算抽些时间，通过参考一些文章，来梳理一下 HTTPS 整套机制的实现，本文主要通过以下三个方面来进行梳理
HTTP通信存在什么问题HTTPS如何改进HTTP存在那些问题HTTPS工作原理是什么
HTTP
HTTP 是属于应用层的协议，它是基于 TCP/IP 的，所以它只是规定一些要传输的内容，以及头部信息，然后通过 TCP 协议进行传输，依靠 IP 协议进行寻址
客户端发出请求，服务端进行响应，就是这么简单，在整个过程中，没有任何加密的东西，所以它是不安全的，中间人可以进行拦截，获取传输和响应的数据，造成数据泄露
什么是 HTTPS
HTTPS 是在 HTTP 上建立 SSL 加密层，并对传输数据进行加密，是 HTTP 协议的安全版，现在它被广泛用于万维网上安全敏感的通讯，HTTPS 主要作用是
- 对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全
- 对网站服务器进行真实身份认证
我们经常会在 Web 的登录页面和购物结算界面等使用 HTTPS 通信，使用 HTTPS 通信时，不再用 http://，而是改用 https://，另外，当浏览器访问 HTTPS 通信有效的 Web 网站时，浏览器的地址栏内会出现一个带锁的标记，对 HTTPS 的显示方式会因浏览器的不同而有所改变
HTTP 与 HTTPS 的区别
HTTP 是明文传输协议，HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全
主要的区别有以下这些
HTTP是明文传输协议，HTTPS协议是由SSL + HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO，像谷歌、百度都会优先索引HTTPS网页HTTPS标准端口443，HTTP标准端口80HTTPS需要用到SSL证书，而HTTP不用
其实简单来说，就两点
- 对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全
- 对网站服务器进行真实身份认证，
为什么需要 HTTPS
在 HTTP 协议中有可能存在信息窃取或身份伪装等安全问题，使用 HTTPS 通信机制可以有效地防止这些问题，接下来我们先来了解下 HTTP 协议存在哪些问题
通信使用明文（不加密），内容可能被窃听
由于 HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用 HTTP 协议通信的请求和响应的内容）进行加密，即 HTTP 报文使用明文（指未经过加密的报文）方式发送
HTTP 明文协议的缺陷是导致数据泄露、数据篡改、流量劫持、钓鱼攻击等安全问题的重要原因，HTTP 协议无法加密数据，所有通信数据都在网络中明文裸奔，通过网络的嗅探设备及一些技术手段，就可还原 HTTP 报文内容
无法证明报文的完整性，所以可能遭篡改
所谓完整性是指信息的准确度，若无法证明其完整性，通常也就意味着无法判断信息是否准确，由于 HTTP 协议无法证明通信的报文完整性，因此在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉
换句话说，没有任何办法确认，发出的 请求/响应 和接收到的 请求/响应 是前后相同的
不验证通信方的身份，因此有可能遭遇伪装
HTTP 协议中的请求和响应不会对通信方进行确认，在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求，另外服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）
HTTP 协议无法验证通信方身份，任何人都可以伪造虚假服务器欺骗用户，实现钓鱼欺诈，用户无法察觉，反观 HTTPS 协议，它比 HTTP 协议相比多了以下优势
- 数据隐私性，内容经过对称加密，每个连接生成一个唯一的加密密钥
- 数据完整性，内容传输经过完整性校验
- 身份认证，第三方无法伪造服务端（客户端）身份
HTTPS 如何解决 HTTP 上述问题
HTTPS 并非是应用层的一种新协议，只是 HTTP 通信接口部分用 SSL 和 TLS 协议代替而已，通常 HTTP 直接和 TCP 通信，当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了，简言之所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP
在采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能，也就是说 HTTP 加上加密处理和认证以及完整性保护后即是 HTTPS
HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法，『散列函数』、『对称加密』和『非对称加密』，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性
下面我们就来看看 HTTPS 是如何解决我们上面提到过的几个问题
解决内容可能被窃听的问题（加密）
主要有三种方式
对称加密
这种方式加密和解密同用一个密钥，加密和解密都会用到密钥，没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了，但是此时我们虽然对数据进行加密了，但是随之会产生一些问题
以对称加密方式加密时必须将密钥也发给对方，可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落人攻击者之手，同时也就失去了加密的意义，另外还得设法安全地保管接收到的密钥
非对称加密
在对称加密的路上走不通了，我们换个思路，还有一种加密方式叫『非对称加密』，采用非对称加密时，客户端和服务端均拥有一个公钥和私钥顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密，利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走
非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但是这种方式也是存在一定缺点的
- 公钥是公开的，所以针对私钥加密的信息，中间人截获后可以使用公钥进行解密，获取其中的内容
- 公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改
- 使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率
对称加密 + 非对称加密
这种方式也是 HTTPS 采用的方式，使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的，所以我们可以将对称加密与非对称加密结合起来，充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式
具体做法是，发送密文的一方使用对方的公钥进行加密处理『对称的密钥』，然后对方用自己的私钥解密拿到『对称的密钥』，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信，所以 HTTPS 采用对称加密和非对称加密两者并用的混合加密机制
解决报文可能遭篡改问题（数字签名）
网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？在这种情况下我们就可以考虑使用校验数字签名，通常数字签名有两种功效
- 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名
- 数字签名能确定消息的完整性,证明数据是否未被篡改过
下面我们再来看看数字签名如何生成，如下所示
1 | +---------------------+ |
将一段文本先用 Hash 函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文一起传送给接收者，接下来就是接收者校验数字签名的流程了，如下
1 | +---------------------+ |
接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用 Hash 函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比，如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性
解决通信方身份可能被伪装的问题（数字证书）
上面我们提到了数字签名，很美好，你可以使用公钥来进行解密，说明确实是私钥方发送的，但是有没有想过，万一这把公钥本身，就被人做了手脚呢？所以为了保证公钥是可信的，这里就引出了证书颁发机构（Certificate Authority，简称 CA，也就是所谓的第三方认证中心）
这里唯一不同的是，假设对网站信息加密的算法是 MD5，通过 MD5 加密后，然后通过第三方机构的私钥再次对其加密，这样的话，数字证书包含有两个特别重要的信息，即某网站公钥 + 数字签名，假如中间人拦截后把服务器的公钥替换为自己的公钥，因为数字签名的存在，会导致客户端验证签名不匹配，这样就防止了中间人替换公钥的问题
下面我们来看一下客户端是如何去对比两者数字签名的
- 浏览器会去安装一些比较权威的第三方认证机构的公钥，比如
VeriSign、Symantec以及GlobalSign等等 - 验证数字签名的时候，会直接从本地拿到相应的第三方的公钥，对私钥加密后的数字签名进行解密得到真正的签名
- 然后客户端利用签名生成规则进行签名生成，看两个签名是否匹配，如果匹配认证通过，不匹配则获取证书失败
这里存在一个问题，那就是既然有第三方认证，为什么我们不直接使用第三方认证的方式来进行加密呢？
这是因为第三方认证机构是一个公开的平台，中间人可以去获取，如果只是对网站信息进行第三方机构私钥加密的话，还是会受到欺骗
因为没有认证，所以中间人也向第三方认证机构进行申请，然后拦截后把所有的信息都替换成自己的，客户端仍然可以解密，并且无法判断这是服务器的还是中间人的，最后造成数据泄露，这其实也就是数字签名作用
HTTPS 工作流程
Client发起一个HTTPS的请求，连接443端口，这个过程可以理解成是请求公钥的过程Server端收到请求后，通过第三方机构私钥加密，会把数字证书（也可以认为是公钥证书）发送给ClientClient验证公钥证书，比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书），如果验证通过则继续，不通过则显示警告信息Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给ServerServer使用自己的私钥（private key）解密这个消息，得到对称密钥，至此，Client和Server双方都持有了相同的对称密钥Server使用对称密钥加密明文内容A，发送给ClientClient使用对称密钥解密响应的密文，得到明文内容AClient再次发起HTTPS的请求，使用对称密钥加密请求的明文内容B，然后Server使用对称密钥解密密文，得到明文内容B
为何不所有的网站都使用 HTTPS
既然 HTTPS 那么安全可靠，那为何不所有的 Web 网站都使用 HTTPS 呢？
首先，很多人还是会觉得 HTTPS 实施有门槛，这个门槛在于需要权威 CA 颁发的 SSL 证书，从证书的选择、购买到部署，传统的模式下都会比较耗时耗力
其次，HTTPS 普遍认为性能消耗要大于 HTTP，因为与纯文本通信相比，加密通信会消耗更多的 CPU 及内存资源，如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少，但事实并非如此，用户可以通过性能优化、把证书部署在 SLB 或 CDN，来解决此问题
除此之外，想要节约购买证书的开销也是原因之一，要进行 HTTPS 通信，证书是必不可少的，而使用的证书必须向认证机构（CA）购买
总结
HTTPS就是使用SSL/TLS协议进行加密- 传输大致流程是客户端拿到服务器的公钥（是正确的），然后客户端随机生成一个对称加密的秘钥，使用该公钥加密，传输给服务端，服务端再通过解密拿到该对称秘钥，后续的所有信息都通过该对称秘钥进行加密解密，完成整个
HTTPS的流程 - 第三方认证，最重要的是数字签名，避免了获取的公钥是中间人的
