Open pfan123 opened 4 years ago
https 是一种加密传输协议,基于非对称加密算法和对称加密算法的协作使用。https 主要作用:1.对数据加密 2.验证网站服务器身份
https
为什么不使用单一的加密算法?
单一使用对称加密
单一使用非对称加密 (RSA)
拦截客户端报文,伪造公钥 当客户端初次向服务器请求公钥时,报文可能被黑客截获,黑客伪装服务器向客户端返回一个黑客生成的公钥,并且自己保留私钥。当客户端使用该黑客虚假公钥加密发送报文时,黑客就可以用私钥解密客户端发送的报文信息。
拦截服务端报文,伪造公钥 当客户端初次向服务器请求秘钥时,服务器返回公钥报文,中途被黑客截获,并且黑客修改报文中的公钥信息为黑客生成的公钥。当客户端发送使用黑客虚假公钥加密的报文给服务器时,可能被黑客截获报文信息并且用黑客私钥解密。
拦截服务端报文,解密返回给客户的报文信息 当客户端安全获得服务器发放公钥并且请求服务器时,服务器返回加密后报文信息。黑客可以截获服务器返回的报文信息,并且用公钥解密(因为公钥是大家都知道的),从而盗取服务器响应报文。
从上面几种情况,可以看出
因此,最终我们的实际通信过程只能通过对称加密来实现,这样才能实现双向的安全通信,并且要解决的问题是安全地协商出一个对称秘钥。这个过程就是 https 加密的总体思路。
要安全地协商出一个对称加密密钥 DK,只能通过一个安全的通道来进行,也就是需要对协商 DK 的报文进行再次加密,显然不能再使用对称加密方式来进行加密协商报文。自然而然就想到使用非对称加密的方式。
DK
我们假设非对称公钥 FK.pub 能够安全的发布到客户端,那么我们客户端只要把 DK 用 FK.pub 进行加密发送给服务端,服务器端用非对称私钥 FK.pri解密,这样服务器和客户端都能获取到了 DK 。基于只有客户端和服务器端的知道的 DK 进行加密通信的过程是安全的。
FK.pub
FK.pri
那么问题就流转到 FK.pub 如何安全地发布到客户端?这就是我们需要解决的根源问题。
下面是我们整体分析的流程:
非对称要安全发布公钥需要解决的问题是 1.【拦截客户端报文,伪造公钥】 2.【拦截服务端报文,伪造公钥】
这时候,解决办法就是委托第三方 CA 证书机构,帮助我们完成这个公钥的安全发布过程。
CA
这个过程一般可以这样描述。
1.服务器提供服务器的公钥给 CA机构,生成证书,证书一般包含以下内容:
Issuer (证书的发布机构)
Valid from , Valid to (证书的有效期)
Public key (公钥)
Subject (主题)
Signature algorithm (签名所使用的算法)
Thumbprint, Thumbprint algorithm (指纹以及指纹算法)
生成证书的过程一般是:把 Issuer, Public key, Subject, Valid from, Valid to 等信息以明文的形式写到证书里面作为内容,然后用一个指纹算法计算出这些数字证书内容的一个指纹(也就是签名),并把指纹和指纹算法用自己的私钥进行加密,然后生成证书
Issuer
Public key
Subject
Valid from
Valid to
2.服务器获得 CA 机构发放的数字证书
3.一般 CA 机构都是得到认证的权威机构,这些机构的根证书都是被我们的操作系统所认可的。在客户端也是已经提前安装权威机构的根证书。
4.客户端建立连接后,向服务器发起请求
5.服务器返回 CA 机构为我们生成的数字证书
6.客户端根据根证书验证服务器返回的数字证书的可靠性。根据根证书中的写明的签名算法,对内容做签名,然后利用根证书解密签名内容,对比两个签名内容判断证书内容是否被篡改,最后获取到服务器的公钥。
以上就是对上图的步骤的一些解析,接下来客户端和服务器就要进行协商对称密钥操作了。但是这里需要对第5步做解析,为什么这里的 rsa 能够保证服务器公钥安全发布?
rsa
【拦截客户端报文,伪造公钥】这种情况在单一非对称加密中,是黑客冒充服务器返回公钥。那么在这里能不能冒充服务器返回数字证书呢?答案是不能。假设当黑客返回冒充数字证书,那么客户端用sa机构的根证书解密被加密的签名内容时,是取不到正确是值的,这一点保证的【拦截客户端报文,伪造公钥】不会出现。
【拦截服务端报文,伪造公钥】这种情况是属于黑客篡改服务器返回的公钥,那么在这里会不会出现黑客篡改服务器返回的证书呢?答案是不能。假设黑客篡改了,证书内容,那么客户端验签时就会不通过;假设黑客修改了签名,那么就会在客户端用根证书解密签名时失败。因此保证【拦截服务端报文,伪造公钥】不会出现。
好了,接下来是我们根据得到的正确的服务器公钥,进行安全的客户端 -> 服务器通信过程,并且协商对称密钥。
1.客户端拿到公钥之后先发送一个随机串到服务器,然服务器进行加密,并且返回
2.客户端用公钥解密收到的报文,发现果然能解开,于是确认这就是正确的公钥。
3.客户端生成一个对称加密密钥,公钥加密,并且发送给服务器。这个过程是安全的。
4.服务器收到对称密钥加密报文。用私钥进行解密,拿到到客户端发来的密钥,于是愉快的开始了通信~
浏览器发起http请求时候,如何知道服务器支持什么http 版本?
HTTPS加密过程和TLS证书验证
Charles的HTTPS抓包方法及原理分析
签名、加密、证书的基本原理和理解
浏览器如何验证HTTPS证书的合法性?
SSL/TLS协议运行机制的概述
HTTPs入门,图解SSL从回车到握手
https加密流程
https
是一种加密传输协议,基于非对称加密算法和对称加密算法的协作使用。https
主要作用:1.对数据加密 2.验证网站服务器身份为什么不使用单一的加密算法?
单一使用对称加密
单一使用非对称加密 (RSA)
拦截客户端报文,伪造公钥 当客户端初次向服务器请求公钥时,报文可能被黑客截获,黑客伪装服务器向客户端返回一个黑客生成的公钥,并且自己保留私钥。当客户端使用该黑客虚假公钥加密发送报文时,黑客就可以用私钥解密客户端发送的报文信息。
拦截服务端报文,伪造公钥 当客户端初次向服务器请求秘钥时,服务器返回公钥报文,中途被黑客截获,并且黑客修改报文中的公钥信息为黑客生成的公钥。当客户端发送使用黑客虚假公钥加密的报文给服务器时,可能被黑客截获报文信息并且用黑客私钥解密。
拦截服务端报文,解密返回给客户的报文信息 当客户端安全获得服务器发放公钥并且请求服务器时,服务器返回加密后报文信息。黑客可以截获服务器返回的报文信息,并且用公钥解密(因为公钥是大家都知道的),从而盗取服务器响应报文。
从上面几种情况,可以看出
因此,最终我们的实际通信过程只能通过对称加密来实现,这样才能实现双向的安全通信,并且要解决的问题是安全地协商出一个对称秘钥。这个过程就是
https
加密的总体思路。要安全地协商出一个对称加密密钥
DK
,只能通过一个安全的通道来进行,也就是需要对协商DK
的报文进行再次加密,显然不能再使用对称加密方式来进行加密协商报文。自然而然就想到使用非对称加密的方式。我们假设非对称公钥
FK.pub
能够安全的发布到客户端,那么我们客户端只要把DK
用FK.pub
进行加密发送给服务端,服务器端用非对称私钥FK.pri
解密,这样服务器和客户端都能获取到了DK
。基于只有客户端和服务器端的知道的DK
进行加密通信的过程是安全的。那么问题就流转到
FK.pub
如何安全地发布到客户端?这就是我们需要解决的根源问题。下面是我们整体分析的流程:
非对称要安全发布公钥需要解决的问题是 1.【拦截客户端报文,伪造公钥】 2.【拦截服务端报文,伪造公钥】
这时候,解决办法就是委托第三方
CA
证书机构,帮助我们完成这个公钥的安全发布过程。CA 证书
这个过程一般可以这样描述。
1.服务器提供服务器的公钥给
CA
机构,生成证书,证书一般包含以下内容:Issuer (证书的发布机构)
Valid from , Valid to (证书的有效期)
Public key (公钥)
Subject (主题)
Signature algorithm (签名所使用的算法)
Thumbprint, Thumbprint algorithm (指纹以及指纹算法)
生成证书的过程一般是:把
Issuer
,Public key
,Subject
,Valid from
,Valid to
等信息以明文的形式写到证书里面作为内容,然后用一个指纹算法计算出这些数字证书内容的一个指纹(也就是签名),并把指纹和指纹算法用自己的私钥进行加密,然后生成证书2.服务器获得
CA
机构发放的数字证书3.一般
CA
机构都是得到认证的权威机构,这些机构的根证书都是被我们的操作系统所认可的。在客户端也是已经提前安装权威机构的根证书。4.客户端建立连接后,向服务器发起请求
5.服务器返回
CA
机构为我们生成的数字证书6.客户端根据根证书验证服务器返回的数字证书的可靠性。根据根证书中的写明的签名算法,对内容做签名,然后利用根证书解密签名内容,对比两个签名内容判断证书内容是否被篡改,最后获取到服务器的公钥。
以上就是对上图的步骤的一些解析,接下来客户端和服务器就要进行协商对称密钥操作了。但是这里需要对第5步做解析,为什么这里的
rsa
能够保证服务器公钥安全发布?【拦截客户端报文,伪造公钥】这种情况在单一非对称加密中,是黑客冒充服务器返回公钥。那么在这里能不能冒充服务器返回数字证书呢?答案是不能。假设当黑客返回冒充数字证书,那么客户端用sa机构的根证书解密被加密的签名内容时,是取不到正确是值的,这一点保证的【拦截客户端报文,伪造公钥】不会出现。
【拦截服务端报文,伪造公钥】这种情况是属于黑客篡改服务器返回的公钥,那么在这里会不会出现黑客篡改服务器返回的证书呢?答案是不能。假设黑客篡改了,证书内容,那么客户端验签时就会不通过;假设黑客修改了签名,那么就会在客户端用根证书解密签名时失败。因此保证【拦截服务端报文,伪造公钥】不会出现。
好了,接下来是我们根据得到的正确的服务器公钥,进行安全的客户端 -> 服务器通信过程,并且协商对称密钥。
1.客户端拿到公钥之后先发送一个随机串到服务器,然服务器进行加密,并且返回
2.客户端用公钥解密收到的报文,发现果然能解开,于是确认这就是正确的公钥。
3.客户端生成一个对称加密密钥,公钥加密,并且发送给服务器。这个过程是安全的。
4.服务器收到对称密钥加密报文。用私钥进行解密,拿到到客户端发来的密钥,于是愉快的开始了通信~
Other Resources
浏览器发起http请求时候,如何知道服务器支持什么http 版本?
HTTPS加密过程和TLS证书验证
Charles的HTTPS抓包方法及原理分析
签名、加密、证书的基本原理和理解
浏览器如何验证HTTPS证书的合法性?
SSL/TLS协议运行机制的概述
HTTPs入门,图解SSL从回车到握手