We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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从回车到握手
The text was updated successfully, but these errors were encountered:
No branches or pull requests
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从回车到握手
The text was updated successfully, but these errors were encountered: