网络协议 -- HTTPS

  1. 浏览器与服务器约定一个密钥,浏览器发送请求的时候用这个密钥进行加密,服务器用同样的密钥解密
  2. 但如何约定密钥呢?假设用密钥B的来加密密钥A,但又怎么约定密钥B呢,因此这样会陷入 死循环

非对称加密

  1. 非对称加密的私钥放在服务器,不会在网络上传输,保证 私钥的私密性 ,而私钥对应的 公钥 是可以在网上 随意传播
  2. 浏览器用服务器的公钥加密信息发送给服务器,中间哪怕被黑客截获,也是无法解密的,因为只能用服务端的私钥解密
    • 但服务器响应的信息却是 所有人 都能解密,因为是用服务器的私钥加密的,用对应的公钥就能够解密 – 不安全
  3. 另外,如果只有一对公钥私钥,黑客是可以模拟正常的用户行为,因为服务器的 公钥 是公开的
  4. 由此看来,一对公钥私钥是不够的,浏览器也需要自己的公钥和私钥
    • 浏览器请求服务器时,用服务器的公钥加密;而服务器响应浏览器时,用浏览器的公钥加密
    • 这样,黑客就没有办法去模拟浏览器去获取信息,或者截取响应消息,因为黑客没有浏览器或服务器的私钥,无法解密

数字证书

  1. 公钥只能解决你是你的问题,但不能解决你是谁的问题,因此需要借助证书
  2. 由于所有人都能创建私钥和公钥,因此需要权威部门介入,而 权威部门 颁发的称为 证书 (Certificate)
  3. 证书的内容包括 公钥 、证书的 所有者 、证书的 发布机构 、证书的 有效期
  4. 生成证书需要发起一个 证书请求 ,然后发给一个权威机构( CA ,Certificate Authority)去认证
  5. 权威机构会用 自身的私钥 给证书签名( 签名算法

签名证书

  1. 对信息做一个 Hash计算 ,得到一个Hash值,这个过程式 不可逆
  2. CA的私钥 将这个Hash值 加密 作为一个 签名 ,然后和信息一起发出去
  3. 简单表述: signature = encrypt(hash(msg), ca_private_key)
  4. 背书: CA用自己的私钥给网站A的公钥签名!!

Issuer:谁颁发的;Subject:证书是颁发给谁的;Validity:证书期限,Public Key:公钥内容;Signature Algorithm:签名算法

openssl x509 -in server-cert.pem -noout -text
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 11689652687981033366 (0xa239fd2f6eccb796)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer:
        Validity
            Not Before: Aug 19 03:53:44 2019 GMT
            Not After : Aug 18 03:53:44 2020 GMT
        Subject: CN=zhongmingmao.me
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:be:75:a7:9d:85:c1:a5:d1:e7:d6:59:66:6e:3a:
                    ...
                    3a:6a:e9
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         a5:b9:65:10:4e:46:50:1e:3f:b0:ae:3f:bf:a0:88:94:e4:e2:
         ...
         c2:ca:81:06:e4:9c:6b:66

层层授信

  1. 这样一来,浏览器从网站A得到的不再是一个公钥,而是会得到一个 证书 ,该证书会有一个签发机构CA
  2. 只需要得到该签发机构 CA的公钥 ,去解密网站A的证书的签名,如果解密成功,Hash也对的上,说明网站的公钥没什么问题
  3. 验证证书的过程中,需要CA的公钥,那如何确定CA公钥是对的?
    • CA的公钥需要更高级的CA给它签名,然后形成CA证书
    • 要想知道某个CA的证书是否可靠,需要查看CA的上级证书的公钥,能不能解开这个CA的签名
    • 这样层层上去,直到rootCA,做最后的背书,通过这种 层层授信背书 的方式,保证 非对称加密 模式的正常运转

HTTPS的工作模式

  1. 非对称加密在 性能 上不如对称加密
  2. 非对称加密的公钥密钥主要用于传输对称加密的密钥,而真正的大量数据通信通过对称加密完成
  1. 登录HTTPS网站时,客户端会首先发送 Client Hello 消息到服务器
    • 明文 传输 TLS版本信息加密套件候选列表压缩算法候选列表
    • 另外还会有一个 随机数 ,用户后续的 对称密钥协商
  2. 网站会返回 Server Hello 消息
    • 告诉客户端,服务器 选择 使用的 协议版本加密套件压缩算法
    • 另外还会有一个 随机数 ,用户后续的 对称密钥协商
  3. 网站会发送 Server Certificate 消息,里面包含 服务器端的证书 ,最后网站会发送 Server Hello Done 消息
  4. 客户端肯定不会直接信任该证书,于是会从 它自己信任的CA仓库 中,拿 CA证书的公钥 去解密网站的证书
    • 如果能成功,说明网站是可信的
    • 这个过程可能会不断地 往上追溯 ,直到一个授信的CA
  5. 客户端在验证完服务端的证书后,会计算产生随机数 pre-master ,发送 Client Key Exchange
    • 服务器证书中的公钥 加密,再发送给服务器,服务器可以通过私钥进行解密
    • 到目前为止,无论是客户端还是服务器,都已经有了 三个随机数
    • 通过这三个随机数,可以在客户端和服务端产生 相同的对称密钥
  6. 计算出对称密钥后,客户端会发送 Change Cipher Spec 消息,表示后面都采用协商的 通信密钥加密算法 进行加密通信
  7. 客户端发送 Encrypted Handshake Message 消息
    • 将已经商定好的参数,采用 协商密钥 进行加密,发送给服务器用于 数据和握手验证
  8. 服务器也可以发送 Change Cipher Spec 消息和 Encrypted Handshake Message 消息,目的与客户端的一致
  9. 双方握手结束后 ,就可以用 对称密钥 进行加密传输了
    • 这个过程除了 加密解密 外,其他过程与HTTP是一样的
  10. 上面的过程只包含了HTTPS的 单向认证 ,即客户端验证服务器端的证书
    • 在对安全要求更严格的场景下,可以启用 双向认证 ,即服务器也会验证客户端的证书

重放和篡改

  1. 重放
    • 有了加密和解密,黑客即使截获了包,也无法打开,但可以选择 重放
    • 解决方案:把 TimestampNonce随机数 联合起来,做一个 不可逆的签名
    • Nonce随机数保证唯一,或者Timestamp和Nonce随机数联合起来保证唯一,同样的请求只接受一次
    • 服务器多次收到相同的Timestamp和Nonce随机数,则视为无效
  2. 篡改
    • 签名是 不可逆 的,相当于具有了 不可篡改性
    • 黑客只能修改Timestamp和Nonce随机数,但无法修改签名,服务器用签名算法解出来会发现两者对不上,会直接丢弃
我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章