前言
目前网上文章看完感觉还是一头雾水,为啥突然出来一个随机数?到底客户端和服务器传输了什么导致后续可以使用对称加密的方式?自己看完就是觉得差点意思,深入一问就不清楚了,故了解清楚再分享出去。
首先得明白的4个点
-
HTTPS和HTTP的区别
-
若HTTP无了解的,可以看看下文:HTTP协议
-
HTTP是不安全的,故有了HTTPS,它是由HTTP经过SSL(TLS是SSL的新的别称)协议进行加密生成的。
-
-
先非对称校验后对称传输
- 虽说HTTPS是采用了非对称加密,但要明白,这个非对称加密是在建立关系,校验的时候使用,实际真正传输数据的时候还是采用了对称加密,因为性能更高。
-
非对称加密是咋样的
- 咱们有一把钥匙和一把锁,谁想要传输小秘密给咱们就过来请求咱们的锁,然后就给他一把锁,他锁上了小秘密后再发回给咱们,只有咱们才有钥匙打开这个锁,看到里面的内容。这样就能够保障就是是半路拦截了,也看不到内容。这里公布的锁就叫公钥,钥匙就是私钥,采用这种把公钥给出去加密,私钥解密的就叫非对称加密。至于对称加密就是一个带上钥匙的锁。
-
密钥交换算法是咋样的(本文重点方向)
-
密钥交换算法,既是DH算法解决了密钥在双方不直接传递密钥的情况下完成密钥交换,这个神奇的交换原理完全由数学理论支持。
我们来看DH算法交换密钥的步骤。假设甲乙双方需要传递密钥,他们之间可以这么做:
-
甲首选选择一个素数
p
,例如509,底数g
,任选,例如5,随机数a
,例如123,然后计算A=g^a mod p
,结果是215,然后,甲发送p=509
,g=5
,A=215
给乙; -
乙方收到后,也选择一个随机数
b
,例如,456,然后计算B=g^b mod p
,结果是181,乙再同时计算s=A^b mod p
,结果是121; -
乙把计算的
B=181
发给甲,甲计算s=B^a mod p
的余数,计算结果与乙算出的结果一样,都是121。
所以最终双方协商出的密钥
s
是121。注意到这个密钥s
并没有在网络上传输。而通过网络传输的p
,g
,A
和B
是无法推算出s
的,因为实际算法选择的素数是非常大的。 -
-
具体过程
用上面提到的交互算法举例HTTPS交互的过程:
-
客户端发起请求,携带支持的加密组件列表(加密组件:加密算法及密钥长度等信息)
-
服务器从加密组件列表选择一种加密方式,就是上面的A=g^a mod p(g异或a求余p),再加上公钥生成证书响应给客户端。这一步发送了A、g、p告诉客户端,保留了随机数a,同时还有公钥生成CA证书发送给客户端。
-
客户端接送到证书后,先验证CA证书是否正确,正确就再继续。
-
客户端这里的校验证书主要是为了防止中间人冒充了服务器发送公钥过来。这个证书是由第三方信得过机构颁发的,验证过程也是非对称加密。服务器先向机构申请证书,机构就把要发送的内容用私钥进行加密,然后客户端接受到的时候由于浏览器内置可信的公钥将会解析并校验是否真的是咱们请求的服务器,以及是否被篡改过的。
-
客户端校验完证书后,也选择一个随机数b,然后使用服务器返回的加密方式进行运算这个随机数,B=g^b mod p,同时还计算s=A^b mod p,最后把B结果再发回给服务器。
-
-
服务器得到了这个加密后的随机数B,再同一开始保留的随机数a进行运算校验s=B^a mod p。这样两边没通过传输密钥,都得出了一个密钥S,接下来再互通一下S是否一致,一致的话就说明是对的人。
-
至此完成了校验身份的阶段,再接着通过S就可以走对称加密了。
用图说话
最后想说一下,博文终究是别人总结的和理解过的,推荐多多看书和看官网。看到这里,还不给个三连吗?不给?点个赞总行吧!它对我真的很重要!
我是芸芸众生中的一棵想出头的韭菜。
参考
-
<<图解HTTP>>