https原理-明文、对称加密、非对称加密、CA

为了保证数据传输过程中的数据安全,目前都使用https协议。https全称:HyperText Transfer Protocol over Secure Socket Layer。其实https不是一个新的东西,我们可以理解为https=http+SSL/TLS。

SSL(Secure Socket Layer):安全套接字层协议

TLS(Transport Layer Security):传输层安全协议,其前身是SSL

上述SSL/TLS协议只是定义了一种协议,如果需要支持SSL协议,首先操作系统需要安装这个协议的某个具体实现。比较出名的SSL/TLS开源实现是openssl

这个协议会占用443端口。

下面探究一下https的实现过程,会从明文传输到使用ca机构颁发证书等由浅入深的进行讲解。

1 明文

在刚开始,人们还未意识到网络环境的复杂性的时候往往使用明文传输,请求和响应过程都会遭到黑客攻击(因为网络传输会经过各种各样的防火墙、路由器、网络运营商,这里的黑客就是伪装成其中一个节点,对请求进行拦截和转发、同时进行篡改)。

这种情况下,数据基本上是处于裸奔状态,如果某一跳节点想看你的数据,他就可以看的到

2 对称加密

为了解决明文传输的问题,很简单的想法是对数据进行加密。比如客户端和服务端约定一个秘钥,使用这个秘钥进行加密就是对称加密。

使用对称加密,黑客同样可以伪装成良民请求密钥,使用该密钥在请求和响应的过程中对数据进行窃听和篡改。

由此可见,对称加密不能解决我们的数据传输安全问题。

3 非对称加密

既然对称加密不安全,那我们使用非对称加密,即加密秘钥和解密秘钥不同。服务端有一对公钥和私钥,

公钥加密,私钥解密;私钥加密,公钥解密。

请求的过程:

  • 首先,客户端请求公钥。
  • 然后使用公钥加密,传输数据,
  • 服务端使用私钥解密,获取到原文。

响应的过程:

  • 首先,服务端使用私钥加密,返回数据。
  • 客户端使用公钥解密,获取响应报文。

存在的问题:

  • 黑客同样可以获取到公钥,在响应阶段,黑客介入,使用公钥对密文解密;
  • 但是请求阶段,因为是公钥加密,公钥不能解密,所以请求是安全的。响应是不安全的。

对称加密+非对称加密混合使用

看来非对称加密也不够安全,继续探究另外一种场景

过程:

  • 首先,使用非对称加密的方式获取到公钥pk
  • 其次,客户端生成随机串num1,使用公钥加密后生成X传给服务器,
  • 然后,服务器使用私钥解密X得到num1
  • 然后,服务器返回客户端OK
  • 然后后续的通信都使用num1对数据进行对称加密。

解决了什么问题?

这种方式解决了3中使用非对称加密,响应报文,黑客可以使用公钥解密的问题。

存在的问题:

中间人攻击问题。

  • (1)在客户端请求服务端获取公钥时,黑客就介入。伪装成服务器和客户端通信。客户端得到的公钥是黑客的公钥pk1。而同时,黑客伪装成客户端和服务器通信,获取公钥pk。
  • (2)客户端发送num1到黑客,黑客发送num1到服务端。后续通信使用num1对数据进行对称加密通信。
  • (3)整个过程中,客户端觉察不到黑客的存在,客户端以为和它通信的是真正的服务端。为了解决这个问题引入可信认证机构(CA)见下面分析。

5 对称加密+非对称加密+CA公钥

既然会有中间人攻击问题,我们得出结论:只要传递公钥,就不安全,因此公钥不传才安全。那怎么不传公钥呢?我们引入第三者,这个第三者是一个公信力比较强的机构,即CA机构。此处需要操作系统的支持,操作系统需要内嵌这个CA机构的公钥cpk。

这个CA机构有一对公私钥cpk/csk。服务端也有一对公私钥pk/sk。服务端(需要花钱)把自己的公钥传递给CA机构,CA机构使用csk对pk进行加密得到ca.密文,CA把这个ca.密文返回给服务端。后续客户端请求服务端时,不传这个pk了,改传ca.密文,客户端得到这个ca.密文后,因为操作系统会内嵌这些大牌CA机构的公钥cpk,因此,客户端拿到服务端证书之后,根据自己操作系统中内嵌的CA机构的公钥cpk就能解开这个ca.密文,解开这个密文得到的就是服务器公钥pk,因此达到了不传pk服务端和客户端都知道这个pk的目的。

但是,如下图所示,如果黑客作为中间人,它也生成一对公私钥,因为ca得公钥cpk是公开的,黑客也知道,很容易的就能对ca.密文进行截胡,也就能够知道服务端公钥pk,也就能够使用公钥解密数据,因此,在这里,黑客能够看到服务端发过来的所有明文数据。接着黑客也可以去ca申请自己的ca.黑客.密文,重新对数据进行加密后传给客户端,客户端使用ca.公钥解开的数据此时是黑客的公钥。效果上看,就是服务端看黑客是客户端,客户端看黑客是服务端,同样是中间人攻击。

 

 

 

 看来CA机构只对服务端公钥进行加密得到ca.密文还不够,CA机构还需要承担更大的责任。

对称加密+非对称加密+CA证书

如上所述,既然ca把自己的公钥能够放到操作系统里,那么ca应该有这个能力对合法的服务端做认证(也就是能够保证服务端是真正的服务端,不是伪造的)。当服务端把公钥给了ca机构,ca机构会对这个服务端做背景调查(域名、公司名、法人...),然后ca机构会向服务端下发证书。最重要的一点是服务端公钥和域名绑定。客户端浏览器访问服务器时,首先通过ssl协议443端口获取服务端证书,浏览器会对证书做校验(最重要的一点是校验服务端域名和服务端公钥绑定关系)。

下面我们看一个网站证书的示例,比如博客园的证书示例如下,一二级证书在每台电脑的操作系统中都有的,而三级证书是没有的,但是其父证书操作系统中是有的。

 

下面我们来看看这种情况下请求和响应的详细过程。

过程:

  • (1)服务端生成一对公私钥sk和pk。服务端把pk传给CA机构CA机构使用cpk对pk加密,并加以一些其他东西(域名、公司名、颁发者、有效期、指纹等)生成证书,颁发给服务端。
  • (2)TLS第一次握手,客户端发送支持的加密算法列表给服务端
  • (3)TLS第二次握手,服务端返回客户端证书
  • (4)客户端浏览器在客户端的操作系统中查找该证书对应的CA机构根证书,找不到则弹出浏览器提示“不安全的访问连接是否继续”。找到CA根证书(根证书和服务端证书不一样)。在根证书中得到cpk,然后用cpk对服务端证书携带的加密的pk进行解密,解密得到pk
  • (5)TLS第三次握手,客户端使用pk对随机串num1进行加密得到密文X
  • (6)服务端使用sk对X解密得到随机串num1
  • (7)TLS第四次握手,服务端发送确认ok
  • (8)后续的通信,使用num1对数据进行对称加密,进行通信。

下图是操作系统自带的CA机构的根证书

 

 

注意,上面所有协商过程都是通过443端口进行的,这个端口是不能改的(有的人说能改啊,修改openssl代码,但是目前主流浏览器https请求都是发往443端口,除非浏览器也同步改)。

 

6 http和https关系

比较难于理解的一点是,http和https一点关系都没有,他们是两种不同的协议,http走80端口,https走443端口

比如我们访问 http://baidu.com 

 

 我们可以看到其访问的是80端口,接着有一次跳转,跳转到如下地址:https://www.baidu.com,如下

 

这个https请求走的443端口,不会走80端口。接下来的所有请求都是https请求,都走443端口

 

 

我们再看一下另外一种场景

我们访问http://baidu.com:443,看看能不能访问?我们先分析一下,这里我们使用http协议访问443端口,因为443端口只会处理https请求,理论上访问不通,我们看一下是否如此

 

 

 

我们再看另外一种场景

我们访问https://baidu.com:80,我们先分析一下,这里我们使用https协议访问80端口,因为https只能访问443端口,这是操作系统ssl协议写死的,也是主流浏览器写死的,理论上访问不了,我们看一下是否如此

 

 

从上面的分析示例我们可以看出,https走的是443端口,即使是请求完证书开始传递数据的情况下也是如此,和80端口没有1毛钱关系。

 

posted @ 2023-03-25 17:05  zhenjingcool  阅读(554)  评论(0编辑  收藏  举报