浅谈HTTP和HTTPS
HTTP通信存在什么问题?
HTTP协议并不是一种很安全的协议。
通信使用明文（不加密），内容可能被窃听、篡改；不验证通信方的身份，因此有可能遭遇伪装。
比如会遭遇到中间人攻击的问题。就是中间人模拟客户端与服务器，当客户端给服务器发送消息时，截获，然后冒充客户端再给服务器发送消息，当服务器返回消息时，截获，又冒充服务器给客户端发送消息，这个其实就是通常所说的“抓包”，我们开发时候喜欢用的“花瓶”charles就是这个原理。
为什么会被HTTPS取代？
对此，HTTPS这种附带加密算法的协议就产生了。而且HTTPS正慢慢取代HTTP成为传输协议的主流。
HTTPS是一种安全的加密协议，它在TCP传输层与HTTP应用层之间增加了一层网络传输安全协议层（SSL/TLS协议），来保证数据传输的安全性与TCP连接建立的安全性，极大程度保证了避免中间人攻击的情况发生。
三类基本算法：散列函数 、对称加密和非对称加密
HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。
图片.png
对称加密
这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。
非对称加密
使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。
对称加密+非对称加密(HTTPS采用这种方式)
使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。HTTPS在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。
数字签名——解决报文可能遭篡改问题
网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？----校验数字签名。
数字签名的两种功效：
1、能确定消息确实是由发送方签名并发出来，因为别人假冒不了发送方的签名。
2、数字签名能确定消息的完整性，证明数据是否未被篡改过。
数字签名如何生成：
图片2.png
将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者。接下来就是接收者校验数字签名的流程了。
校验数字签名流程：
图片3.png
接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
假设消息传递在Kobe，James两人之间发生。James将消息连同数字签名一起发送给Kobe，Kobe接收到消息后，通过校验数字签名，就可以验证接收到的消息就是James发送的。当然，这个过程的前提是Kobe知道James的公钥。问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给Kobe,或者说拿到的公钥如何证明是James的。
此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，Kobe客户端内置了所有受信任CA的证书。CA对James的公钥（和其他信息）数字签名后生成证书。
数字证书——解决通信方身份可能被伪装的问题
数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。
我们来介绍一下数字证书认证机构的业务流程：
- 服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
- CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
- 如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;
- 客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
- 客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
- 客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
HTTPS工作流程
640.jpg
1.Client发起一个HTTPS（比如 https://juejin.im/user）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。
2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。
3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。
4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。
5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。
6.Server使用对称密钥加密“明文内容A”，发送给Client。
7.Client使用对称密钥解密响应的密文，得到“明文内容A”。
8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。
为何不所有的网站都使用HTTPS
既然HTTPS那么安全可靠，那为何不所有的Web网站都使用HTTPS？
首先，很多人还是会觉得HTTPS实施有门槛，这个门槛在于需要权威CA颁发的SSL证书。从证书的选择、购买到部署，传统的模式下都会比较耗时耗力。
其次，HTTPS普遍认为性能消耗要大于HTTP，因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。但事实并非如此，用户可以通过性能优化、把证书部署在SLB或CDN，来解决此问题。举个实际的例子，“双十一”期间，全站HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现，经过优化后的许多页面性能与HTTP持平甚至还有小幅提升，因此HTTPS经过优化之后其实并不慢。
除此之外，想要节约购买证书的开销也是原因之一。要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。
最后是安全意识。相比国内，国外互联网行业的安全意识和技术应用相对成熟，HTTPS部署趋势是由社会、企业、政府共同去推动的。
