大家好，又见面了，我是你们的朋友全栈君。
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账号...
