总结下HTTPS相关知识点
HTTP协议
HTTP (HyperText Transfer Protocol
,超文本传输协议) 是因特网上应用最为广泛的一种网络传输协议,所有的WWW
文件都必须遵守这个标准。
- 缺点
HTTP
协议是明文传输协议,通信过程中被中间人进行劫持、监听、篡改,会造成个人隐私泄露等严重的安全问题
HTTPS
在传输层和应用层加了
TSL/SSL
- 如何加密?
- 对称加密
Client
->Server
通过密钥进行发送方加密、接收方解密
问题?如何安全传输密钥,密钥被中间人劫持,一切加密解密都是浪费时间
- 非对称加密
也叫公开密钥加密,有私钥和公钥
- 如
Client
发送消息给Server
,Client
用Server
的公钥进行加密,server用自己的私钥进行解密,反之亦然。 - 一切看似很完美,但其实还有问题
中间人劫持
如果我们使用非对称加密传输数据,会有如下问题:
客户端如何获取服务器的公钥?
- 三次握手阶段:
Server
发送自己的公钥给Client
,中间人H
拿到Server
的公钥,然后发送自己的公钥给client
。 Client
用H
的公钥进行加密,发给Server
,中间人H劫持到消息,用自己的私钥进行解密,然后用server
的公钥进行加密,发送给Server
,Server
用自己的私钥进行解密,得到消息。Client
、Server
都觉得消息在正常传输,但是已经被中间人劫持了。
引入第三方CA
(Certificate Authority
证书颁发机构)
- 数字证书出场,server主动去权威机构申请
Server
把自己的公钥、域名等信息发送给CA
CA
拿到后用自己的私钥进行加密- 权威自己用自己的私钥进行加密了, 那应该如何解密?你发送给
Client
,中间人不是一样可以劫持吗?。鸡生蛋,蛋生鸡的悖论了。 - 答案是权威机构的公钥不需要传输,因为权威机构会跟主流的浏览器或操作系统合作,将他们的公钥内置到浏览器或操作系统环境中。
Client
收到数字证书后,从数字证书中找到权威机构的信息,从本地找到权威机构的公钥,就能正确解密Server
的公钥。
数字证书保证传输安全
如果不校验,中间人也可以向权威机构申请数字证书,然后劫持
Server
发送的证书,然后发送自己的数字证书给Client
,Client
接受到后,用本地的公钥解密,拿到中间人的公钥。
解决方案:签名
- 数字证书中包含了
Server
的公钥,机构信息,还包括了证书内容的签名、签名计算方法、证书对应的域名
签名 等于
Server
的公钥、其他信息通过HASH
函数计算得到证书的数字摘要,权威机构的私钥加密得到数字签名
Client
使用公钥解密,得到服务器的公钥、证书的数字签名、签名计算方法。重新计算签名,对比签名是否一致。判断证书是否被中间人篡改。- 如果中间人拿到权威机构的公钥,能解析证书内容并篡改,但是篡改后需要对证书进行加密。中间人没有权威机构的私钥进行加密,强行乱加密,
Client
就无法用CA
的本地公钥进行解密。 - 证书调包,中间人向权威机构申请一份证书,
Server
发送证书给Client
,中间人直接替换成自己的证书,Client
用本地权威机构的公钥解密,对比证书签名也没问题。但是Client
检查证书中的域名和当前访问的是否一致。不一致也会发出警告。
HTTPS
通信过程
-
Client
发送Client Hello
报文给Server
开启SSL
通信,报文中包含Random_1
-
服务器支持
SSL
通信的话,发送Server Hello
报文回应,报文中包含Random_2
-
服务器之后发送
Certificate
报文,报文中包含数字证书 -
服务器再发送
Server Hello Done
通知Client
,最初的SSL
握手阶段协商部分结束 -
Client
对数字证书校验,正确后,解密得到服务器的公钥。通过RSA
算法随机生成Pre-Master Secret
,并且用服务器的公钥进行加密,包含在Client Key Exchange
报文中,发送给Server
-
客户端继续发送
Change Cipher Spec
报文,告知Server
端,客户端切换协商的加密套件,准备使用协商的加密套件加密数据并传输。 -
Client
发送Finished
报文,该报文包含了连接至今全部报文的整体校验值(也就是hash
值) -
Server
接收到Client
的请求,用私钥解密,把Pre-master secret
取出来。Server
发送同样的Change Cipher Spec
报文 -
Server
同样发送Finished
报文,提供Client
校验 -
Server
和Client
的Finished
报文交换完毕,SLL
连接建立。开始通信。
随机数如何生成?
Client
和Server
都通过Random_1
、andom_2
、Pre-Master Secret
三个随机数,通过伪随机函数PRF
生成Master Secret
。再根据master secret
推导出hash secret
和sesson secret
此时用对称加密算法进行通讯,使用哪个作为共享密钥呢?
- 双方使用对称加密算法进行加密,用
hash secret
对HTTP
报文做一次运算生成一个MAC
,附在HTTP
报文的后面,然后用session-secret
加密所有数据(HTTP+MAC
),然后发送。 - 接收方则先用
session-secret
解密数据,然后得到HTTP+MAC
,再用相同的算法计算出自己的MAC
,如果两个MAC
相等,证明数据没有被篡改。
随机数的作用
pre-master secret
本身就是一个随机数,再加上Hello
和Server
消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥- 三个随机数让随机数十分接近随机。每次生成对称密钥也是为了如果这次通信被破解,不会导致以前的数据被破解。
- 拦截人重复发送报文,扰乱正常通信,
Server
接收到重复的随机数,可以中断通信。