搞懂HTTPS

总结下HTTPS相关知识点

HTTP协议

HTTP (HyperText Transfer Protocol,超文本传输协议) 是因特网上应用最为普遍的一种网络传输协议,全部的WWW文件都必须遵照这个标准。算法

  • 缺点

HTTP协议是明文传输协议,通讯过程当中被中间人进行劫持、监听、篡改,会形成我的隐私泄露等严重的安全问题segmentfault

HTTPS

在传输层和应用层加了TSL/SSL浏览器

  1. 如何加密?
  • 对称加密

Client -> Server 经过密钥进行发送方加密、接收方解密安全

问题?如何安全传输密钥,密钥被中间人劫持,一切加密解密都是浪费时间服务器

  • 非对称加密

也叫公开密钥加密,有私钥和公钥网络

  1. Client发送消息给ServerClientServer的公钥进行加密,server用本身的私钥进行解密,反之亦然。
  2. 一切看似很完美,但其实还有问题

中间人劫持

若是咱们使用非对称加密传输数据,会有以下问题:session

客户端如何获取服务器的公钥?dom

  1. 三次握手阶段:Server发送本身的公钥给Client,中间人H拿到Server的公钥,而后发送本身的公钥给client
  2. ClientH的公钥进行加密,发给Server,中间人H劫持到消息,用本身的私钥进行解密,而后用server的公钥进行加密,发送给ServerServer用本身的私钥进行解密,获得消息。
  3. ClientServer都以为消息在正常传输,可是已经被中间人劫持了。

引入第三方CA (Certificate Authority证书颁发机构)

  1. 数字证书出场,server主动去权威机构申请
  2. Server把本身的公钥、域名等信息发送给CA
  3. CA拿到后用本身的私钥进行加密
  4. 权威本身用本身的私钥进行加密了, 那应该如何解密?你发送给Client,中间人不是同样能够劫持吗?。鸡生蛋,蛋生鸡的悖论了。
  5. 答案是权威机构的公钥不须要传输,由于权威机构会跟主流的浏览器或操做系统合做,将他们的公钥内置到浏览器或操做系统环境中。
  6. Client收到数字证书后,从数字证书中找到权威机构的信息,从本地找到权威机构的公钥,就能正确解密Server的公钥。

数字证书保证传输安全

若是不校验,中间人也能够向权威机构申请数字证书,而后劫持Server发送的证书,而后发送本身的数字证书给ClientClient接受到后,用本地的公钥解密,拿到中间人的公钥。函数

解决方案:签名

  1. 数字证书中包含了Server的公钥,机构信息,还包括了证书内容的签名、签名计算方法、证书对应的域名

签名 等于 Server的公钥、其余信息经过HASH函数计算获得证书的数字摘要,权威机构的私钥加密获得数字签名网络传输协议

  1. Client使用公钥解密,获得服务器的公钥、证书的数字签名、签名计算方法。从新计算签名,对比签名是否一致。判断证书是否被中间人篡改。
  2. 若是中间人拿到权威机构的公钥,能解析证书内容并篡改,可是篡改后须要对证书进行加密。中间人没有权威机构的私钥进行加密,强行乱加密,Client就没法用CA的本地公钥进行解密。
  3. 证书调包,中间人向权威机构申请一份证书,Server发送证书给Client,中间人直接替换成本身的证书,Client用本地权威机构的公钥解密,对比证书签名也没问题。可是Client检查证书中的域名和当前访问的是否一致。不一致也会发出警告。

HTTPS通讯过程

  1. Client发送Client Hello报文给Server开启SSL通讯,报文中包含Random_1

  2. 服务器支持SSL通讯的话,发送Server Hello报文回应,报文中包含Random_2

  3. 服务器以后发送Certificate报文,报文中包含数字证书

  4. 服务器再发送Server Hello Done通知Client,最初的SSL握手阶段协商部分结束

  5. Client对数字证书校验,正确后,解密获得服务器的公钥。经过RSA算法随机生成Pre-Master Secret,而且用服务器的公钥进行加密,包含在Client Key Exchange报文中,发送给Server

  6. 客户端继续发送Change Cipher Spec报文,告知Server端,客户端切换协商的加密套件,准备使用协商的加密套件加密数据并传输。

  7. Client发送Finished报文,该报文包含了链接至今所有报文的总体校验值(也就是hash值)

  8. Server接收到Client的请求,用私钥解密,把Pre-master secret取出来。Server发送一样的Change Cipher Spec报文

  9. Server一样发送Finished报文,提供Client校验

  10. ServerClientFinished报文交换完毕,SLL链接创建。开始通讯。

随机数如何生成?

  1. ClientServer都经过Random_1andom_2Pre-Master Secret三个随机数,经过伪随机函数PRF生成Master Secret。再根据master secret 推导出hash secretsesson secret

此时用对称加密算法进行通信,使用哪一个做为共享密钥呢?

  1. 双方使用对称加密算法进行加密,用hash secretHTTP报文作一次运算生成一个MAC,附在HTTP报文的后面,而后用session-secret加密全部数据(HTTP+MAC),而后发送。
  2. 接收方则先用session-secret解密数据,而后获得HTTP+MAC,再用相同的算法计算出本身的MAC,若是两个MAC相等,证实数据没有被篡改。

随机数的做用

  1. pre-master secret自己就是一个随机数,再加上HelloServer消息中的随机,三个随机数经过一个密钥导出器最终导出一个对称密钥
  2. 三个随机数让随机数十分接近随机。每次生成对称密钥也是为了若是此次通讯被破解,不会致使之前的数据被破解。
  3. 拦截人重复发送报文,扰乱正常通讯,Server接收到重复的随机数,能够中断通讯。

参考文章

  1. 解析HTTPS
相关文章
相关标签/搜索