网络 | https协议讲解 | 一些可能性的探究

前言

提到不论是cookie还是cookie+session都有信息安全的问题，但究其本质，安全问题其实是由http协议导致的，为了传输私密数据，我们就要对这些数据进行加密再进行传输。由此便诞生了https协议

总所周知，http是基于tcp协议的，tcp是位于传输层的协议。http在tcp之上，是一个应用层的协议，在http和tcp协议之间引入一层加密层（又是经典加一层），就诞生了https协议。这个加密层的代表为SSL，TLS，在讲解https协议之前，需要一些前置知识

常见加密方式

对称加密

常见的对称加密算法有：DES，3DES，AES，TDEA，Blowfish，RC2。感兴趣可以深入学习，不感兴趣了解即可。对称加密方式采用同一密钥对信息进行加密和解密，就像现实生活中的锁，不论是开锁还是上锁，用的都是同一把锁。再比如说一个简单的对称加密：异或，将数据用指定的数进行异或，异或一次就是上锁，异或两次就能得到原始数据，即解锁。由此可见，对称加密的方式加密效率高，计算量小。总之对称加密的特点就是快，但是其存在一个严重的安全问题，就是开锁与解锁的钥匙相同，在网络传输中，钥匙保护了数据，谁保护钥匙？也就是让数据穿上了衣服，钥匙却在网络中裸奔？一旦窃取了钥匙，数据就不再安全

非对称加密

另一种加密方式就是非对称加密，常见算法有：RSA，DSA，ECDSA。非对称加密有两把密匙，在网络中以明文传输的钥匙被叫做公钥，只有自己知道的钥匙叫做私钥，私钥不会在网络中以明文传输。该加密方式的特点是，一把钥匙加密后，必须用对应的钥匙进行解密。比如说用公钥加密，就只能用私钥解密。用私钥加密，只能用公钥解密。就像保险箱和锁，保险箱就是公钥，把重要的东西放在保险箱中，无论怎样，只要你没有对应的钥匙（私钥）就无法打开保险箱。所以这就是公钥敢用明文传输的原理。相比于对称加密，非对称加密的实现很复杂，因此加密与解密的速度很慢

数据摘要，数据指纹

数据摘要也叫数据指纹，其原理是对数据用单向散列函数（哈希）进行运算，生成一串固定长度的数字序列。由于哈希将无限的数据转换成有限的数据，可能导致哈希冲突，但是概率极低，常见算法有：MD5，SHA1，SHA256，SHA512，要注意的是数据指纹不是一种加密算法，它只是加密机制中的一小部分，并且转换后的数字序列难以反推回原信息，数据指纹通常用来做数据一致性的对比

将数据指纹加密，得到的数据就是数字签名

https可能性探究

我们知道https是在http与tcp之间加入了一层加密层，有了前置知识的铺垫，现在我们可以推究一下加密层的大概实现，以加深对加密层的理解

1.采用对称加密

服务端和客户端采用统一密匙对数据进行加密和解密。有两种实现方式，一种是服务端记录所有客户端的密匙，这种方法不太现实，额外的存储太多了，并且首次密匙的确定也难以实现。另一种是客户端与服务端进行通信时，再确定彼此的密匙，并只用于本地通信。两种方法的缺陷都是一样的，就是数据被密匙保护了，但是密钥却在裸奔，别人可以轻而易举的拿到密钥。要是用密钥保护密钥，那么密钥的密钥谁来保护？这就成了一个无解的问题

2.服务端采用非对称加密

在服务端生成公钥S和私钥S’，然后将公钥发送给客户端，客户端拿着公钥S对数据进行加密，如果数据被窃取，由于窃取者不知道私钥S’，所以无法解密用公钥S加密的数据。而服务端拿到该数据后，用私钥S’解密即可。这种做法看似安全，但是上述过程只能保证客户端到服务端的通信安全，如果服务端要向客户端通信呢？

3.双端都采用非对称加密

服务端拥有公钥S和私钥S’，客户端拥有公钥C和私钥C’，在通信开始之前，双方交换各自的公钥，服务端拿到C，客户端拿到S。发送方要向接收方通信时，就将数据用拿到的公钥进行加密，接收方拿到数据后用自己的私钥解密。比如服务端的数据用C加密后发送给客户端，客户端拥有C’，所以客户端可以解密用C加密的数据，并且数据被窃取，由于窃取人不知道C’，所以无法得到有效数据，通信过程是绝对安全的。但是这样的做法有一个致命的缺陷：慢，非对称加密与解密的时间远远大于对称加密，每份数据都要加密与解密，通信的效率会降低。

4.对称+非对称加密

服务端拥有公钥S和私钥S’，先将公钥S发送给客户端，然后客户端将对称密钥C用公约S加密，发送给服务端，服务端接收后用S’对其解密，就能得到对称密钥C。接着双方之间的通信都使用对称密钥C进行，第一种方法中，虽然对称密钥的通信效率高，但是却有一个无解的问题：密钥的密钥无法保护。但是使用密钥通信之前必需交换密钥，现在只要找出一个方法保证交换密钥的过程绝对安全就可以了。所以在这种方法下，交换密钥之前，密钥用公钥进行保护，中间人无法窃取密钥，服务端得到密钥后，双方就能通过密钥进行通信，此时的中间人虽然可以窃取数据，但是对加密后的数据也是无能为力了

以上方法看似安全，但却有一个致命的漏洞

如果中间人在通信开始前就进行攻击了呢？服务端将S发送给客户端，由于是明文发送，中间人拦截数据后可以得知这是服务端发送给客户端的公钥S，中间人可以自己生成公钥M和私钥M’，将S替换成M，然后再将数据转发给客户端。此时客户端拿到服务端发送的"公钥S"，将密钥C用"公钥S"加密后发送给服务端，此时中间人再次拦截这份数据，由于这份数据使用公钥M加密的，中间人拥有其私钥，所以中间人可以对其解密，就能得到双方用来通信的密钥C。此时中间人再将密钥C用真正的公钥S加密，转发给服务端。之后的双方将使用密钥C进行通信，由于中间人得到了密钥C，窃取通信数据之后是可以对其解密的，所以服务端和客户端之间的通信又不安全了。

证书

上述四种对https协议的探讨中，只有第四种是可行的，但是要使用该方法就要保证服务端传递的公钥不被替换。实际上的https协议采用的就是第四种方法，只不过为了保证通信的安全，真正的https引入了证书

在解释证书之前，先总结一下第四种通信方法：服务端生成非对称密钥对，这对密钥对用来保证客户端对称密钥传递的安全性，服务端会向客户端发送公钥，客户端将对称密钥用公钥加密后发回给服务端。在服务端得到对称密钥后，双方将使用对称密钥进行通信。现在的唯一问题是：由于中间人的存在，客户端无法确保服务端发送的公钥是服务端发送的。由此便引入了证书，证书可以理解为一个结构体，里面存储了

服务端公钥
证书颁发机构
证书有效期（证书过期就不安全了）
证书所有者（服务端的信息）
数字签名

证书采用了一套机制，保证了中间人无法篡改证书中的信息，如果客户端得知证书被篡改，那么客户端将要求服务端重新发送证书。所以证书的机制是什么样的呢？首先，服务端要在本地创建一对非对称密钥对，将公钥以及其他信息发送给CA机构（证书颁发机构）进行认证，私钥自己保留。CA机构得到这些正文信息后，会生成一个数字签名，具体过程是：

CA机构先用单向散列函数将得到的正文信息转换成固定长度的数字序列，也就是数据指纹。而CA机构拥有一对非对称密钥，公钥A和私钥A’，CA将数据指纹用私钥进行加密，生成数字签名，将数字签名整合到服务端发来的正文中，就形成了证书，可以将证书理解为：正文+CA颁发的数字签名

此时，服务端拿到了证书，将证书发送给客户端，客户端会对证书进行认证，是否在有效期中，颁发证书的机构是否被信任，如果以上两项满足，再进行最后也是最重要的判断：将证书的正文用和CA相同的单向散列函数，生成数据指纹，然后将数字签名用CA机构的公钥A进行解密，得到数据指纹，将两者进行比较，如果相同，说明数据没有被篡改。客户端可以信任该证书

为什么证书可以保证不被篡改呢？如果中间人篡改了证书的正文（篡改服务端的公钥），那么正文生成了数据指纹肯定与数字签名解密后的数据指纹不同（不同的原始数据生成的数据指纹肯定不同，虽然可能会冲突，但概率极低极低）。如果中间人篡改数字签名，客户端那CA的公钥A解密后的数据指纹肯定与正文生成的数据指纹不同，甚至被篡改的数字签名无法解密。所以中间人要篡改只能将正文和数字签名都篡改，但是仔细一想这样肯定不行，中间人篡改正文后生成数据指纹，然后呢？中间人又没有CA机构的私钥，只能拿自己的私钥或者公钥生成数字签名，那么这个数字签名用CA机构的公钥解密后肯定是错误的，或者无法解密的。如果中间人将证书整个掉包，自己申请一个证书，那么证书的认证是可以通过，但是这样做有什么意义，使客户端与自己进行通信？总结一下，https的加密是建立在对CA机构的绝对信任之上的，如果CA机构的私钥泄漏，那么https的加密就形同虚设

对证书的再次理解

常见的生成数据指纹的算法有MD5，SHA系列，不论原始字符串有多长，这些哈希函数都会将它们转换成16字节或者32字节的序列。并且这些序列不可逆，从理论上讲，还原序列是不可能实现的。假设服务端要发送一串字符串，hello world给客户端，服务端用MD5得到数据指纹，将hello world和其数据指纹一起发送，如果中间人篡改hello world为hello c++，那么客户端就会发现，服务端发来的数据生成的数据指纹与服务端直接发来的数据指纹不同，此时就可以判断出数据被篡改过。

那么中间人不仅篡改原始字符串，还用篡改后的字符串生成新的数据指纹呢？客户端就无法判断数据是否被篡改过，因为服务端发来的数据生成的数据指纹和其直接发来的数据指纹相同，但是它们都是被客户端篡改过的。所以要使用这样的验证数据是否被篡改的方式，就要保证数据指纹无法被篡改，我们的做法是对数据指纹进行加密，得到数字签名，数字签名的解密是公开的（CA的公钥是公开的），但是数据指纹到数字签名的加密却是不公开的，并且由于非对称加密的特性：加密和解密是一对一的，就算中间人修改了数据指纹，它也无法生成正确的数字签名，因为CA的公钥无法解密不使用CA的私钥加密的数据，或者说解密不正确。这就是CA机构的存在理由，成为一个被大家信任的机构，使用不会被泄漏的私钥对数据进行加密。

总结

https协议用到了三种密钥

第一种密钥（对称密钥）：客户端和服务端在确认密钥安全的情况下使用的密钥，两者之间的通信数据基本上使用该密钥加密
第二种密钥（非对称密钥）：服务端的非对称密钥，用来保护第一种密钥（对称密钥），客户端用公钥加密第一种密钥，服务端用私钥解密
第三种密钥（非对面密钥）：CA机构的非对称密钥，用来保护服务端非对称密钥中的公钥，CA用私钥对数据指纹进行加密生成数组签名，服务端将证书发送给客户端，客户端用CA的公钥进行解密，得到服务端的公钥（第二种密钥中的公钥）

总之，客户端和服务端之间的通信为了达到效率最高且保证数据安全，只能使用对称加密，https所作的工作只是为了保护用来对称加密的密钥，这些机制围绕该密钥展开