http、https(加密解密、签名验签、ca证书签发机构).看完十来篇文章的总结_基于http协议数据传输加解密安全机制 验签

1. http协议
   hypertext transfer protocol 超文本传输协议.主要就是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器.

2. http1.0和http1.1区别

• 缓存处理
  http1.0中主要使用header中的if-modified-since、expires来作为缓存判断的标准.在http1.1中则引入了更多的缓存控制策略例如entity tag、if-unmodified-since、if-match、if-none-match等更多可供选择的缓存头来控制缓存策略.
• 带宽优化及网络连接的使用.
  http1.0中存在带宽浪费的情况,当客户端只需要某个对象的一部分的时候,而服务器却将整个对象传送过来.并且不支持断点续传(当在传输过程中下载/上传中断,下次可以从上次中断处开始.并且在下载/上传过程中会将文件划分为多个部分,同时进行)的功能.http1.1中引入了range头域,它允许只请求资源的某个部分.
• http1.1中新增了24个错误状态响应码
  比如410表示服务器上的某个资源被永久性的删除.
• host头处理
  http1.0中认为每台服务器绑定一个ip地址,所以请求消息中的url没有传递主机名(hostname).随着虚拟主机的发展,一台服务服务器可以存在多个虚拟主机,并且共享一个ip地址.http1.1的请求头中必须要有host字段,否则报400错误.
• http1.1默认长连接.即默认开启connection: keep-alive.在http1.0默认短连接,每次请求都要建立连接.

3. http和https的区别

• http的起始是http://,默认端口是80; https的起始是https://,默认端口是443
• http协议运行于tcp上,所有传输的内容是明文传输.https运行于ssl(安全套接字层)/tls(传输层安全协议),ssl/tls运行于tcp之上,所有传输的内容都是经过加密的.传输内容的加密采用对称加密的方式,但是对称加密的密钥使用服务器方的证书的非对称加密方式进行传输的.
• https协议由于是加密传输而不是明文传输,可以有效防止被运营商劫持,运营商对劫持的内容修改,会推送很多的运营商广告.
  注: ssl/tls位于传输层和应用层之间,主要有三个功能: 信息加密解密(对称加密/非对称加密)、身份验证(私钥签名,公钥验签)、消息完整性验证(通过MAC消息验证码,即通过哈希函数处理成固定长度大小的字符串,比如MD5便是其中一种)

4. 加密解密

• 对称加密
  加密和解密的密钥是同一个.
  优点: 加密速度快
  缺点: 密钥管理和分发比较困难.
  密钥在传输过程中可能会被劫持导致泄漏; 双方的密钥有一方被泄漏,就不安全了; 每对用户每次使用对称加密算法时,都需要使用其他人不知道的唯一秘钥,这会使得收、发双方所拥有的钥匙数量巨大,密钥管理成为双方的负担.
• 非对称加密
  加密和解密的密钥不是同一个.一般使用公钥加密,私钥解密.这样即使黑客获取客户端的公钥,也无法获取信息的内容,因为需要服务器的私钥进行解密.
  优点: 安全性高
  缺点: 加密速度慢
• 混合加密
  为了解决这两种方式的缺点.采用对称加密+非对称加密混合的方式.
  服务器端生成公钥-私钥对,公开公钥,私钥自己保存.客户端采用公钥对对称加密的密钥进行加密传输,服务器端使用自己的私钥进行解密,获取对称加密的密钥,以后通过对称加密的密钥传输数据.

5. 签名验签
   为了验证发送信息方的身份是正确的,使用私钥加密,公钥解密.因为私钥只有自己持有,公钥公开的.

6. 通过MAC进行消息完整性验证
   MAC(消息验证码,即带密钥的hash函数).它的输入包括任意长度的消息和一个发送者与接收者之间的共享密钥，然后输出固定长度的数据，这个数据称为MAC值.然后将MAC值和消息一块发送到接受端,接受端使用共享密钥对接收到的消息进行加密处理,将生成的值和传送过来的MAC值进行比较,如果相等,则说明消息是完整的.

7. 那么加密解密、签名验签、完整性怎么结合在一起的呢?
   由内到外一次是MAC完整性–>签名验签–>加密解密.
   需要消息传输的密钥Pub1,签名验签的Pub2、Pri2,以及MAC消息验证码中的对称加密的公钥Pub3.
   发送方: 将消息使用Pub3进行加密得到MAC值(保证信息完整性),MAC值连同消息m使用Pri2进行签名(身份验证),然后在使用Pub1进行加密(防止被劫持获取传输内容),进行发送.
   接受方: 使用Pub1对接收的信息进行解密,使用Pub2再进行解密,得到m和MAC,再对原文信息m使用Pub3加密,得到另一个MAC值,比较两个MAC值是否一样,如果一样则说明信息再传输过程中是完整的,没有任何修改.因为信息有一点修改,得到的MAC值就是完全不同的.

8. 还有其他的问题吗?
   经过之前的陈述,我们知道在信息传输过程中使用对称加密的方式进行,这样可以保证传输的速率.而对称加密的密钥使用非对称加密的方式进行传输的.即客户端使用服务器发送给自己的公钥对信息传输中使用的公钥进行加密,发送给服务器端,服务器端使用自己的私钥进行解密,然后获取在实际的数据传输过程中使用的对称加密的密钥.
   那么服务器端发送给客户端的非对称加密公钥是怎么发送的呢?安全吗?
   在服务器向客户端发送公钥的过程中,由于无法确保服务器身份的合法性(因为公钥并不包含服务器的信息),所以存在安全隐患.
   那么可能会想:无法确保服务器身份的合法性,这个学过呀,使用非对称加密的方式私钥签名、公钥验签呀…那么验签的公钥怎么传递呢?从而陷入了无限循环…

9. 那么服务器向客户端发送公钥,不保证服务器身份的合法性,能出现什么问题呢?

• 中间人攻击
  客户端C和服务器S进行通信,中间节点M截获了二者的通信.节点M自己计算产生一对公钥pub_M和私钥pri_M.
  C向S请求公钥时,M把自己的公钥pub_M发给了C;C使用公钥 pub_M加密的数据能够被M解密,因为M掌握对应的私钥pri_M,而 C无法根据公钥信息判断服务器的身份,从而 C和 M之间建立了"可信"加密连接;中间节点M和服务器S之间再建立合法的连接,因此 C和 S之间通信被M完全掌握,M可以进行信息的窃听、篡改等操作.
  
• 信息抵赖
  服务器也可以对自己的发出的信息进行否认,不承认相关信息是自己发出.
  

10. 所以为了解决上面的问题,引入了认证中心ca

• 服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证（不交私钥）
• CA通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等
• 如信息审核通过,CA会向申请者签发认证文件-证书
  证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名
  签名的产生算法：首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用CA的私钥对信息摘要进行加密,密文即签名
• 客户端 C 向服务器 S 发出请求时,S 返回证书文件
• 客户端 C读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应CA的公钥解密签名数据,对比证书的信息摘要,如果一致(信息具有完整性),则可以确认证书的合法性,即公钥合法
• 客户端然后验证证书相关的域名信息、有效时间等信息;
• 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
  在这个过程注意几点：
  a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握;
  b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;
  c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）
  d.证书=公钥（服务方生成密码对中的公钥）+申请者与颁发者信息+签名（用CA机构生成的密码对的私钥进行签名）
  即便有人截取服务器A证书，再发给客户端，想冒充服务器A，也无法实现。因为证书和url的域名是绑定的。

主要参考文章: HTTPS中CA证书的签发及使用过程