大家好,又见面了,我是你们的朋友全栈君。
https://blog.csdn.net/abinge317/article/details/51791856
RSA非对称加密的2个用途:
加密(防窃听)
RSA非对称加密会用到一对密钥,分别称为公钥和私钥,公钥加密之后的数据可以通过私钥来进行解密,私钥加密的数据也同样可以用对应的公钥进行解密。在web数据传输过程中,由于客户端和服务器端是多对一的关系,因此可以让所有的客户端持有相同的公钥,服务器持有私钥,这样一来就能方便地实现数据的加密传输。
签名(防篡改)
由于私钥只在某一个体手中,因此可以通过这一点来进行身份识别。比如用户A和B分别有一对密钥中的私钥和公钥,现在A向B发送消息”abc”,可进行如下操作:A用私钥对该文本进行加密之后变成密文”#¥%”,并附加上原文,组合成文本”#¥%:abc”(冒号起分隔作用,并无其他含义,具体实现中可自行处理)一起发送,B接收到该文本之后利用公钥对密文进行解密,将得到的解密后文本与传送过来的文本”abc”之间进行比对,如果一切正常,那么公钥解密之后的文本就是私钥加密之前的文本”abc”,比对结果一致,因此可以说明这段”abc”文本确实是A发送过来的,因为只有A才有对文本进行签名的私钥。能得到这个结论的前提是——A所用的私钥跟B所用的公钥确实是一对。
假如在传送途中别人篡改了”abc”,改成”aaa”,由于中间人没有A所持有的私钥,因此无法对篡改之后的数据生成新的正确签名,那么B在收到数据之后用公钥进行解密,再与传送的文本进行比对的话就不会一致。或者中间人篡改了数据之后用另一私钥对篡改之后的数据进行签名,同样由于B没有中间人的私钥对应的公钥,因此比对也不会一致。记住一点:B的公钥所对应的私钥只在A的手中,因此比对一致就说明该文本来自A。
https如何保证安全?
如何保证客户端所持有的公钥就是某合法服务器声明的公钥?
如果不能保证这一点,那么客户端发送的信息就有可能存在被窃听的危险,因为用此公钥加密的数据可以被其对应的私钥拥有者获取,而该私钥并不在客户端所认为的服务器上。
因此可采用一个权威机构进行证书的颁发,所谓证书就是包含了服务器声明的公钥以及组织名称等信息,这里我们只考虑最关键的公钥信息。该权威机构会对申请证书的组织进行审核,确保其身份合法,然后将服务器公钥信息发布给客户端,客户端可利用该公钥与对应的服务器进行通信。整个过程可归纳为以下几步:
1、服务器生成一对密钥,私钥自己留着,公钥交给数字证书认证机构(CA)
2、CA进行审核,并用CA自己的私钥对服务器提供的公钥进行签名(参照上文RSA签名)
3、客户端从CA获取证书(即服务器端公钥),用CA的公钥对签名的证书进行验证,比对一致,说明该服务器公钥确实是CA颁发的(得此结论有一个前提就是:客户端的CA公钥确实是CA的公钥,即该CA的公钥与CA对证书进行签名的私钥确实是一对。参照上文RSA签名中所论述的情况),而CA又作为权威机构保证该公钥的确是服务器端提供的,从而可以确认该证书中的公钥确实是合法服务器端提供的注:为保证第3步中提到的前提条件,CA的公钥必须要安全地转交给客户端,因此,CA的公钥一般来说由浏览器开发商内置在浏览器的内部。于是,该前提条件在各种信任机制上,基本保证成立。
由此可见:所谓的安全的HTTP,其实也是要建立在信任的机制上。
总结:整个过程涉及2对公私密钥对,一对由服务器产生,用于加密,一对由CA产生,用于签名。
整个过程还涉及2个信任:客户端信任CA,CA发布的证书中的公钥就是合法服务器的公钥。客户端信任浏览器内置的CA公钥就是与CA私钥对应的公钥。最后要说明的是,非对称加密在https中只是用来对对称加密密钥进行协商的过程才使用,在两端协商完对称加密的密钥之后,数据的加密传输均采用对称加密的方式。
水平有限,如有不当之处,还望指正!
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/128812.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...