来自:Weizhao的博客算法
在上已一节中介绍了两种加密方法浏览器
其中对称加密性能高,可是有泄露密钥的风险,而非对称加密相反,加密性能较差,可是密钥不易泄露,那么能不能把他们进行一下结合呢?安全
HTTPS经由HTTP进行通讯,但利用SSL/TLS来加密数据包,而SSL/TLS的加密方式就是采用了对称加密与非对称加密的结合。服务器
SSL/TLS考虑到非对称加密的性能较低,因此在初始协商对称加密密钥时,使用了非对称加密,当对称加密密钥协商完成后,则后续全部的通信,所有采用对称加密进行通信。 dom
没法证实公开密钥就是真实服务器的公开密钥性能
好比与B服务器进行通讯,怎么确认公开密钥是B服务器的,后续在公开密钥传输途中已经被替换了,可是却发现不了。加密
因为任何人均可以访问服务器,因此不可能一一把公钥告诉他们,那么能不能提供一个公钥下载的地方让客户机访问服务器时先下载公钥,可是下载公钥的地址也有多是假的,不可取。3d
那么有没有更好的方式,既能安全的获取公钥又能确保访问的服务器是真实的?答案:由数字证书认证机构颁发(CA)公开密钥证书cdn
数字证书认证机构是客户端和服务器端均可以信赖的第三方机构,VeriSign就是一家数字证书机构。流程以下:blog
这里应该有人好奇,证书签发机构的公钥是怎么传到客户端的?浏览器在发布时,已经包含了主流的认证的机构的公开密钥了,因此是不须要传输的。
上图大体描述了 SSL/TLS 的握手过程,具体细节以下:
握手第一步是客户端向服务端发送 Client Hello 消息,这个消息里包含了一个客户端生成的随机数 Random一、客户端支持的加密套件(Support Ciphers)和 SSL Version 等信息。经过 Wireshark 抓包,咱们能够看到以下信息:
第二步是服务端向客户端发送 Server Hello 消息,这个消息会从 Client Hello 传过来的 Support Ciphers 里肯定一份加密套件,这个套件决定了后续加密和生成摘要时具体使用哪些算法,另外还会生成一份随机数 Random2。注意,至此客户端和服务端都拥有了两个随机数(Random1+ Random2),这两个随机数会在后续生成对称秘钥时用到。
这一步是服务端将本身的证书下发给客户端,让客户端验证本身的身份,客户端验证经过后取出证书中的公钥。
Server Hello Done 通知客户端 Server Hello 过程结束。
客户端收到服务端传来的证书后,先从 CA 验证该证书的合法性,验证经过后取出证书中的服务端公钥,再生成一个随机数 Random3,再用服务端公钥非对称加密 Random3生成 PreMaster Key。
Client Key Exchange 就是将这个 key 传给服务端,服务端再用本身的私钥解出这个 PreMaster Key 获得客户端生成的 Random3。至此,客户端和服务端都拥有 Random1 + Random2 + Random3,两边再根据一样的算法就能够生成一份秘钥,握手结束后的应用层数据都是使用这个秘钥进行对称加密。为何要使用三个随机数呢?这是由于 SSL/TLS 握手过程的数据都是明文传输的,而且多个随机数种子来生成秘钥不容易被暴力破解出来。客户端将 PreMaster Key 传给服务端的过程以下图所示:
这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了,是一条事件消息。
这一步对应的是 Client Finish 消息,客户端将前面的握手消息生成摘要再用协商好的秘钥加密,这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密,能解出来讲明前面协商出来的秘钥是一致的。
这一步是服务端通知客户端后面再发送的消息都会使用加密,也是一条事件消息。
这一步对应的是 Server Finish 消息,服务端也会将握手过程的消息生成摘要再用秘钥加密,这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密,能解出来讲明协商的秘钥是一致的。
应用层协议通讯即发送HTTP请求。
参考: