https是http+SSL/TLS,这个SSL/TLS协议就是加密的重头戏,那么这个SSL/TLS协议是如何运作的呢?(TLS就是高版本的SSL,TLS 1.0通常被标示为SSL 3.1)

对称加密vs非对称加密

首先我们知道加密有对称加密和非对成加密,对称加密就是加密/解密的密钥是一样的,例如用123加的密,那么解密也是用123,常用的对称加密有AES,DES;非对称加密就是加密/解密的密钥不相同,例如用123加的密,可能要用abcd才能解开,非对称加密的两个密钥根据功能的不同,分为公钥和私钥,公钥就是可以对外公开的,私钥则是放在自己那,不公开的,常用的非对称加密有RSA,DSA。

这两种加密方法都有自己的优/缺点,对称加密速度快,可以在很短的时间内完成加密/解密,但是缺点就是密钥只有一个,如果用在https加密上,那么势必服务端会将密钥告诉客户端,这样很容易被中间人劫持,一旦得到密钥,后面的操作将没有意义。

非对称加密的优点就是保密性强,因为公钥可以给客户端,私钥自己保存在服务器,这样中间人就很难得到私钥;但是缺点就是如果加密的内容很大,那么加密/解密就会很耗时,无法正常使用。

https加密过程

上面我们了解了对称加密和非对称加密,并且大致了解了他们两种都无法独自完成https加密,真正的https是两者的混合应用。

同时因为https涉及到一些加密算法,因此要保证客户端/服务端的SSL/TLS版本,以及一些相关的版本相同才可以进行,因此客户端也会向服务端发送自己支持的版本,然后服务端根据自己支持的版本达成统一。

background Layer 1 客户端 服务端 客户端支持的协议版本/加密方法/压缩方法等 客户端产生的随机数(client random) 查看是否有客户端支持的版本/加密等 如果有匹配的,将公钥放在数字证书中 1. 2. 服务端产生随机数(server random) 确认数字证书有效,获取公钥 产生一个随机数(premaster key),并用公钥加密 3. 利用私钥解密,得到premaster key 利用上述三个随机数得到session key 利用上述三个随机数得到session key 以后都通过session key加密 利用session key加密

我们可以看到,https主要分成两大块,上面主要是靠非对称加密完成的,目的就是产生随机的session key,其中最主要的是第三步,因为此时客户端和服务端之间加密协议还没有建立好,此时的传输是属于明文传输,因此第一个随机数(client random)和第二个随机数(server random)很容易被中间人劫持。

第三步需要用服务端的公钥对premaster key进行加密,这样中间人就是拿到了,因为没有私钥,也无法破解。

历尽千辛万苦,得到了session key,它又是干嘛的呢?session key利用对称加密对以后的通话进行加密。那为啥不一开始就用非对称加密去加密通话呢?因为非对称对很大的内容加密/解密耗时很长,而对称加密的优点则是加密速度快,因此就要用非对称加密推导出对称加密的密钥。

为什么要把公钥放在数字证书中

上面有一个比较疑惑的地方,就是为啥要把公钥放在数字证书中?直接给不行吗?对不起,直接给真的不行,因为客户端不知道服务端给的这个公钥对不对啊!如果直接给,很容易被劫持。

background Layer 1 客户端 中间人 客户端支持的协议版本/加密方法/压缩方法等 客户端产生的随机数(client random) 查看是否有客户端支持的版本/加密等 如果有匹配的,传递公钥 1. 2. 服务端产生随机数(server random) 获取假公钥 产生一个随机数(premaster key),并用假公钥加密 3. 服务端 劫持client ramdom 支持的协议版本/加密方法/压缩方法等 产生的随机数(client random) 劫持server ramdom 劫持公钥 传递假公钥 传递假公钥 产生的随机数(server random) 假公钥加密内容, 得到premaster key 利用假私钥去解密 用真公钥加密premaster key传给服务器 得到(premaster key),并用真公钥加密

上面就是一个没有数字证书,中间人劫持的例子,中间人在客户端和服务端之间,两者均没有察觉有什么异常,然而中间人得到了所有的key。

那么为什么引入数字证书就可以保证公钥是真正的公钥呢?这个在CA,数字签名,数字证书中有讲解。

其他文章

0
我要评论

评论

返回
×

我要评论

回复:

昵称:(昵称不超过20个字)

图片:

提交
还可以输入500个字