HTTPS中的数字证书认证过程解析

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如何保证安全?

简要说明一下,假设现在有一对密钥(公钥和私钥),如果客户端持有公钥,服务器持有该公钥对应的私钥,那么根据我们前面论述的RSA非对称加密的作用,客户端和服务器通过这一对密钥进行数据的加密传输不会有问题,即数据不会被第三方窃听。

如何保证客户端所持有的公钥就是某合法服务器声明的公钥?

即服务器端如何安全地把它的公钥下发给客户端(这里的客户端一般指的是浏览器)。如果不能保证这一点,那么客户端发送的信息就有可能存在被窃听的风险,因为客户端用此公钥加密的数据可以被其对应的私钥拥有者获取,而该私钥并不在客户端所认为的服务器上。 相当于攻击者给了客户端一个它自己的公钥,让客户端认为这个公钥是某合法服务器的公钥,于是客户端用此公钥对数据进行加密传送,攻击者将此加密数据截获并用自己的私钥进行解密。由于客户端用来加密的公钥就是攻击者给客户端的,因此攻击者能够获取解密之后的明文,从而窃取客户端的信息。

可采用一个权威机构进行证书的颁发,所谓证书就是包含了服务器声明的公钥以及组织名称等信息,这里我们只考虑最关键的公钥信息。该权威机构会对申请证书的组织进行审核,确保其身份合法,然后将服务器公钥信息发布给客户端,客户端可利用该公钥与对应的服务器进行通信。整个过程可归纳为以下几步:

1.服务器生成一对密钥,私钥自己留着,公钥交给数字证书认证机构(CA)
2.CA进行审核,并用CA自己的私钥对服务器提供的公钥进行签名(参照上文RSA签名)
3.客户端从CA获取证书(即获取服务器端公钥),从而拿到了服务器端的公钥。

如何保证客户端拿到的证书确实是权威机构(CA)颁发的证书?

要保证这一点,上面第2步中的CA用自己的私钥对服务器提供的公钥进行签名就起到了作用。为确保该证书确实是CA颁发的,因此需要用到上面论述的RSA签名防篡改的功能。客户端需要用CA的公钥对签名的证书进行验证,比对一致,说明该服务器公钥确实是CA颁发的。(不知道此时读者是否能想到CA发给客户端的证书信息不只有服务器的公钥,还有CA对此公钥进行的签名。)而CA又作为权威机构保证该公钥的确是服务器端提供的,从而可以确认该证书中的公钥确实是合法服务器端提供的。

那么问题又来了:

如何保证客户端所持有的CA公钥确实是CA的私钥所对应的公钥?

也就是说CA的公钥必须要安全地转交给客户端,这真是一个先有鸡还是先有蛋的问题。幸运的是,CA的公钥一般来说由浏览器开发商内置在浏览器的内部。于是,CA的公钥就安全地转交给了客户端(浏览器)。

也许你又要问了,万一我的浏览器就有问题呢?那我只能说:兄弟,少用盗版,实在不行,卸载重装吧。好吧,开个玩笑_

由此可见:所谓的安全的HTTP,其实也是要建立在信任的机制上。

总结

整个过程涉及2对公私密钥对:

  • 一对由服务器产生,用于加密
  • 一对由CA产生,用于签名。

整个过程还涉及2个信任:

  • 客户端信任CA颁发的证书中的公钥就是合法服务器的公钥
  • 客户端信任浏览器内置的CA公钥就是与CA私钥对应的公钥

最后要说明的是,由于非对称加密算法的效率不高,非对称加密在HTTPS中只是用来对对称加密密钥进行协商的过程才使用,在两端协商完对称加密的密钥之后,数据的加密传输均采用对称加密的方式。

您的关注是我不断创作的动力源泉!期待认识更多的朋友,一起交流Java相关技术栈,共同进步!阅读更多技术文章,可关注我的公众号:codecrazy4j

阿斌哥的博客

你可能感兴趣的:(HTTPS中的数字证书认证过程解析)