HTTP缺点

  1. 通信使用明文（不加密），内容可能被窃听
  2. 不验证通信方的身份，有可能遭遇伪装
  3. 无法证明报文的完整性，有可能遭遇篡改

TCP/IP是可能被窃听的网络，通信内容在所有的通信线路上都有可能遭到窥视（抓包）

加密

  • 通信加密

    ​ HTTP没有加密机制，可以通过SSL(Secure Socket Layer,安全套接层)或TLS(Transport Layer Security)安全层传输协议的组合使用

    ​ HTTP+SSL=HTTPS

  • 内容加密

    报文首部未进行加密处理，报文主体会进行加密处理

    为了有效的内容加密，需要客户端和服务器同时具有加密和解密的机制

    主要应用在Web服务中

HTTPS = HTTP + 加密 + 认证 + 完整性保护

HTTPS不是新协议，只是在HTTP通信接口部分用SSL和TLS协议代替了

相当于多了个中间件

例如原先HTTP直接和TCP通信，而HTTPS是HTTP先和SSL通信，再由SSL与TCP通信

加密

加密方法中加密算法是公开的，密钥是保密，由此来保持加密方法的安全性

因此谁有了密钥，谁就能解密

  • 共享密钥加密（对称密钥加密）

    计算量小，加密速度快

    加密和解密用同一个密钥

    在网络中，使用共享密钥的方法时，必须要将密钥发给对方，但是在通信的过程中会发生抓包等现象，同时还要思考如何安全保存密钥的事情

  • 公开密钥加密（非对称密钥加密）

    使用一对非对称密钥，一把叫做私有密钥，一把叫做公开密钥。

    公开密钥可以被任何人都知道，而私有密钥则相反

    公钥和私钥是一起形成的，是一对

    使用这个加密方式： 发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密

    但是想要根据密文和公开密钥，恢复信息原文时困难的，至少现在是不现实的

    • 公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
    • 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。

  • 混合加密机制

    就是 共享密钥加密和公开密钥加密一起使用（处理速度慢）

    再交换密钥环节使用公开密钥加密方式 ；之后的通信交换报文阶段使用共享密钥加密方式

    1. 使用公开密钥加密方式安全交换稍后的共享密钥加密中要使用的密钥

    2. 确保交换的密钥是安全的前提下，使用共享密钥加密方式进行通信

    • 更加详细的过程

      假设A有一对非对称密钥（公钥Key1,密钥key2）,B有一对对称密钥（key3,key4）

    • 交换密钥-使用非对称加密

      1. A把key1给B
      2. B把下一阶段用来加密/解密报文的key4放到报文中，然后用A发来的公钥key1进行加密，再把报文发送给A
      3. A使用私钥key2解密报文，得到key4

    • 数据通信-使用对称加密

      A和B分别使用key3,key4对报文进行解密加密，key3,key4其实是一样的密钥

    • 但是上述所描述并不能证明一开始的公钥传递是否有中间人的介入，因此需要认证/DH密钥交换

    有几个要注意的点： 公开密钥加密中交换的是 密钥

    要确保密钥安全的前提下，再通信

    那么如何 确保密钥安全呢 —- 就需要认证了

注意：

加密密钥一般是公开的，称为公钥

解密密钥是保密的，称为私钥

公钥和私钥是一一对应的，不能单独生成，一对公钥和密钥统称为密钥对

公钥加密必须要私钥解密；私钥加密必须要公钥解密

摘要算法 + 数字签名

准确来说这块内容和上面的内容是差不多的，但是还是想规范一下术语

摘要算法：

摘要不同于加密算法，因为不存在解密，只不过从摘要反推原信息很难（可以认为能加密但无法解密还原，但可以用于比对）。类比到人的话：时间一直向前走 ，我没有办法从现在的你身上反观到你过去的样子，也没法从现在的他身上反观到他过去的样子……但你们现在的样子依然有作用，那就是在于“是否相同”：我可以通过比对现在的你和现在的他是否相同，来判断过去的你和他是否相同，而无需知道过去的你和过去的他具体是什么样子。

数字签名：

摘要经过加密，就得到数字签名

简单的步骤就是（以用户的密码举例：）

  1. 用户传来明文密码
  2. 将明文密码进行hash转化得到哈希值
  3. 将哈希值进行摘要算法加密
  4. 如果用户要登录的时候就输入密码，密码会经过相应的hash和摘要算法加密与数据库中的密文相比对，只要比对成功，就说明这个密码是正确的
  5. 因此，签名为什么叫做签名就是因为他只是来证明你是这个人的标识，不用管里面具体的内容，只要比对成功就行。

证书认证

缺少身份验证的环节

为了保证“公钥”是可信的，数字证书应运而生。

在一开始服务端将公钥传给

使用有数字证书认证机构（CA，Cerfifiate Authority）和其他相关机关颁发的公开密钥证书

数字证书认证机构的认证流程

  1. 服务器的运营人员向机构提出公开密钥的申请
  2. 机构判明后对已申请的公开密钥做数字签名
  3. 分配公开密钥，将其放入公钥证书后绑定在一起
  4. 服务器将公钥证书发送给客户端，以进行公开密钥加密方式通信

公钥证书也叫做数字证书或证书

整体流程

  1. 服务器把公开密钥登录到数字证书认证机构
  2. 数字证书认证机构用自己的私有密钥向服务器的公开密码署数字签名并办法公钥证书
  3. 客户端拿到服务端的公钥证书后，使用数字证书认证机构的公开密钥，向数字证书认证机构验证公钥证书上的数字签名，以确认服务器的公开密钥的真实性
  4. 使用服务器的公开密钥对报文加密后发送
  5. 服务器用私有密钥对报文解密

数字证书认证机构的公开密钥已事先植入到浏览器里了

证书

  1. 证明通信一方的服务器是否规范

  2. 服务器背后的企业是否真实存在（EV SSL证书）

    持有EV SSL证书的Web网站的浏览器地址栏背景是绿的

  3. 客户端证书，证明客户端是服务器预料之内的

协商

好吧上面的东西都当我在放屁

eson给我讲了一下具体的过程，图解HTTP一坨，尼玛

混合加密机制的实现的本质是协商

证书的作用：

  1. 判断客户端的权限/合法性

  2. 判断服务端的合法性

    但是证书是无法真正遏制中间人的活动的

  • SSH 完整过程

    1. 假设有A,B两方，A客户端Client，B服务器Server

    2. A , B会先协商使用的加密算法和其他的参数啥的（Diffe-Hellman就是其中一个算法）

    3. 服务器向客户端发送 证书，临时公钥B

    4. A接受后 验证证书的有效性（CA），获得临时公钥B，然后用临时公钥B加密自己的临时公钥A发送给B，还有自己的证书

    5. B接受后 验证证书有效性， 然后用私钥B解开临时公钥B加密的报文，获得临时公钥A

    6. 现在A有临时公钥A，私钥A，临时公钥B；B有临时公钥B，私钥B，临时公钥A

    7. A,B通过这些值通过随机的方式各自生成一个 session key，但是两个钥匙却是一样的

    8. Session key就是最重要的东西，用这个东西来实现对称加密实体

    9. 这些临时密钥用过了会销毁，以后被截获了也没啥用了

      为什么明明A,B手中的钥匙类型有一把是不一样的（私钥），却能够生成相同的session key

      因为这里使用了Diffe-Hellman算法，这个算法很巧妙，就是数学的神奇性

    以上，感谢eson

    其实还有一个问题就是怎么保证服务端与客户端之间的公钥交换双方是一定的，而不是中间人在和服务器交换公钥，嘿嘿，这里就要使用哈希值加密，具体实现BING吧

完整性保护

使用一种MAC（Message Authentication Code）的报文摘要

MAC能够查知报文是否遭到篡改，从而保护报文的完整性

为什么不一直使用HTTPS

  1. 加密通信会消耗更多的CPU和内存资源
  2. 证书收费太贵了，还是金钱惹的祸