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 非对称加密

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

公钥加密，私钥解密；私钥加密，公钥解密。

请求的过程：

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

响应的过程：

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

存在的问题：

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

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

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

过程：

• 首先，使用非对称加密的方式获取到公钥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机构还需要承担更大的责任。

6 对称加密+非对称加密+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毛钱关系。