网络协议 -- HTTPS

加密

  1. 对称加密算法中,加密和解密使用的密钥是相同的,因此,对称加密算法要保证安全的话,密钥需要保密
  2. 非对称加密算法中,加密和解密使用的密钥是不相同的,一把是公钥,一把是私钥
    • 公钥加密的信息,只有私钥才能解密,私钥加密的信息,只有公钥才能解密
  3. 效率性能方面,对称加密算法要优于非对称加密算法

对称加密

  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:签名算法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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随机数,但无法修改签名,服务器用签名算法解出来会发现两者对不上,会直接丢弃

小结

  1. 加密分为对称加密和非对称加密
    • 对称加密效率高,但无法解决密钥传输问题
    • 非对称加密可以解决这个问题,但效率不高
  2. 非对称加密需要通过证书权威机构CA来验证服务端公钥的合法性
  3. HTTPS是综合了对称加密算法和非对称加密算法的HTTP协议,既能保证传输安全,又能保证传输效率
0%