HTTP 与 HTTPS
HTTP 与 HTTPS 有哪些区别？
- HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
- HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
- 两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
- HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
HTTPS 解决了 HTTP 的哪些问题？
- 混合加密：
什么是加密：加密就是在发送方在发送数据（明文）之前先使用加密算法和密钥对数据进行加密（密文），接受方使用密钥对接收到的密文进行解密，得到明文。
在讲混合加密之前先来了解一下什么是对称加密和非对称加密：
- 对称加密：发送方和接收方对数据进行加密和解密时，用的是同一个密钥
- 非对称加密：双发加密和解密时用的是一对密钥：公钥和密钥，而且双方都各有一对密钥。公钥可以随意分发，而私钥就必须保留在自己手上不为人所知。
对称加密很好理解，非对称加密是如何操作的呢？
假设我们使用密钥加密，公钥解密的方式，那么就有以下过程：
- 首先B方准备好自己的密钥B和公钥B，公钥B发布给A方。
- A方用B方给的公钥B对明文加密，发送密文给B方，同时密文夹带着A方的公钥A
- B方接收到密文后用自己的密钥B解密，得到明文。
- 若B方打算发数据给A方，由于之前以及得到了A方的公钥，所以可以进行以上的类似操作
HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：
在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
采用「混合加密」的方式的原因：
- 对称加密只使用一个密钥，运算速度快，但没有安全性，适合在双方建立连接后使用
- 非对称加密使用两个密钥，由于需要密钥交换，速度会降低，适合尝试建立连接使用
- 摘要算法+数字签名
前面通过混合加密的方法能够保证数据在传输过程中不被第三者解析出（机密性），但是却无法保证数据不会被篡改。
因此我们需要对数据内容生成一个[指纹]，来保证数据的唯一性，然后同内容一同发送。
对方收到后，先是对内容也计算出一个「指纹」，然后跟发送方发送的「指纹」做一个比较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。
那么，在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。
哈希算法虽然能保证内容不被篡改，但无法保证 [ 内容+哈希值 ] 不会被完全替换*(因为被完全替换的话，接收方对内容进行哈希然后比对两个哈希值也是可以认证成功的)*。
那为了避免这种情况，计算机里会用非对称加密算法来解决，但密钥要用来加密还用来解密呢？
流程不同，结果也会不一样：
- 公钥加密，私钥解密：这种方式能够保证数据内容的安全（不可知性），因为数据被公钥后只有密钥才能解析出明文，即使传输过中被截获中间人也无法解析出明文
- 私钥加密，公钥解密：这种方式能够保证数据不会被冒充，因为加密数据的私钥是唯一可知的，如果公钥无法解析出明文，说明这个数据不是来源于持有私钥身份的人发送的。
一般我们不会用非对称加密来加密实际的传输内容，因为非对称加密的计算比较耗费性能的。
所以非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。
总的来说：在双方连接之前，使用摘要算法（哈希函数）计算出明文的哈希值，然后通过非对称加密（私钥加密，公钥解密）对着哈希值进行加密（称这个机密后的哈希值为数字签名），来保证数据来源的可靠性
- 数字证书
前面我们知道：
- 可以通过哈希算法来保证消息的完整性（验证哈希值）；
- 可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）；
但是这还远远不够，还缺少身份验证的环节，万一公钥是被伪造的呢？也就是说，要如何证明这个公钥的来源是真实可信的呢？
在计算机里，存在一个 CA （数字证书认证机构），相当于一个中间认证人。
服务器把自己的公钥注册到CA中，CA用自己的私钥对服务器的【传输信息+数字签名+公钥】打包称一个数字证书，客户端收到数字证书后用CA的公钥确认数字证书的真实性。通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。
HTTPS 是如何建立连接的？其间交互了什么？
- 一开始客户端和服务端双方都各自随机生成一个非常大的整数（Client Random和Server Random），然后先后向对方发送Hello的请求（用于告知对方己方生成的随机数以及协商好TLS协议的版本和密钥交换算法（比如RSA算法）），同时服务端发送Hello请求的时候附带上数字证书（带有服务端的公钥）
注意，这时候双方都拥有一对一样的由双方共同生成的随机大整数，这对大整数是用于RSA算法的
- 客户端验证数字证书然后拿出服务端公钥，然后再随机生成一个大整数（pre-master key），该整数会被客户端使用服务端公钥加密后发送给服务端，服务端解密得到pre-master key。至此，双方都持有一样的三个大整数
- 服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」
- 最后双方进行握手结束通知，接下来改用HTTP协议，使用这个会话密钥加密内容，加密方式由非对称加密改为对称加密。
HTTPS一定安全可靠吗？
首先说结论：HTTPS本身是安全可靠的，但由于客户端的问题会导致客户端发起的HTTPS连接变得不可靠
假设有一个中间服务器B在客户端A充当服务端，在目的服务端C充当客户端，此时客户端与中间人进行 TLS 握手，中间人与服务端进行 TLS 握手。
中间人要想与客户端握手成功必须有一个前提：就是中间人的数字证书被客户端认证接受了。但实际上中间人发送自己伪造的数字证书是会被客户端（浏览器）识别出非法的，于是就会提醒用户该证书存在问题。
但如果用户执意信任该假证书，那么后续的请求都是在与中间人连接，就会被中间人监听了。
另外也有一种可能是本地电脑中病毒，被恶意安装中间人的根证书，这样中间人发过来的数字证书就被成功认证。
所以，HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。
为什么抓包工具能截取 HTTPS 数据？
抓包工具能够抓包的关键是客户端会往系统受信任的根证书列表中导入抓包工具生成的证书，而这个证书会被浏览器信任，也就是抓包工具给自己创建了一个认证中心 CA，客户端拿着中间人签发的证书去中间人自己的 CA 去认证，当然认为这个证书是有效的。
