加密、数字摘要、数字证书、SSL、HTTPS及SSH免密登录

在看一些资料中经常会遇到加密、数字摘要、数字证书、SSL、HTTPS及SSH免密登录这写概念。下面将对加密、数字摘要、数字证书、SSL、HTTPS及SSH免密登录这些领域技术做一个简单介绍。

1. 常用技术间的关系

在我们正式开始对每一项技术进行介绍之前，让我们先有一个宏观的认识，下图罗列我们将要涉及的安全技术以及它们之间的关联。
安全领域的技术众多，但是归根结底，他们都是为了保障如下三个方面：
1. 认证用户和服务器，确保数据发送到正确的客户机和服务器
2. 加密数据以防止数据中途被窃取
3. 维护数据的完整性，确保数据在传输过程中不被改变。

2. “对称加密”与“非对称加密”

对于一份数据，通过一种算法，基于传入的密钥(一串由数字或字符组成的字符串，也称“key”），将明文数据转换成了不可阅读的密文，这是众所周知的“加密”，同样的，密文到达目的地后，需要再以相应的算法，配合一个密钥，将密文再解密成明文，这就是“解密”。
如果加密和解密使用的是同一个密钥，那么这就是“对称密钥加解密”（最常见的对称加密算法是DES）。如果加密和解密使用的是两个不同的密钥，那么这就是“非对称密钥加解密”（最常用的非对称加密算法是RSA）。
这两个不同的密钥一个叫作公开密钥（publickey）另一个叫私有密钥（privatekey），公开密钥对外公开，任何人均可获取，而私有密钥则由自己保存，其实公钥和私钥并没有什么不同之处，公钥之所以成为公钥是因为它会被公开出来，产生任意份拷贝，供任何人获取，而只有服务主机持有唯一的一份私钥，这实际上也是后面要提到的之所以能通过数据证书确定信任主机的重要原因之一。

3. “数字摘要”

数字摘要就是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。因此，“数字摘要“叫”数字指纹“可能会更贴切一些。“数字摘要“是https能确保数据完整性和防篡改的根本原因。
我们在下载文件的时候经常会看到有的下载站点也提供下载文件的“数字摘要“，供下载者验证下载后的文件是否完整，或者说是否和服务器上的文件”一模一样“。其实，
常见的Hash算法有md5，sha1，sha224，sha256，sha384，sha512。

4. “数字签名”

让我们来看看有了“非对称密钥加解密”和“数字摘要“两项技术之后，我们能做些什么呢？假如发送方想把一份报文发送给接收方，在发送报文前，发送方用一个哈希函数从报文文本中生成报文摘要,然后用自己的私人密钥对这个摘要进行加密，这个加密后的摘要将作为报文的”签名“和报文一起发送给接收方，接收方首先用与发送方一样的哈希函数从接收到的原始报文中计算出报文摘要，接着再用发送方的公用密钥来对报文附加的数字签名进行解密，如果这两个摘要相同、那么接收方就能确认报文是从发送方发送且没有被遗漏和修改过！(注意，数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围)
这就是结合“非对称密钥加解密”和“数字摘要“技术所能做的事情，这也就是人们所说的“数字签名”技术。在这个过程中，对传送数据生成摘要并使用私钥进行加密地过程就是生成”数字签名“的过程，经过加密的数字摘要，就是人们所说的“数字签名”！

扫描二维码关注公众号，回复： 3811034 查看本文章
综上所述，数字签名有两种功效：
1. 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
2. 数字签名能确定消息的完整性。

5. “数字证书”

只从“准确认证发送方身份”和“确保数据完整性”两个安全方面来看，数字签名似乎已经完全做到了，还有漏洞存在的可能么？有，漏洞不在数字签名技术本身，而在它所依赖的密钥，只有密钥是真实可靠的前提下，使用数字签名才是安全有效的。
考虑这种可能的情况：在上述发送方向接收方传送报文的例子中，如果发送方所持有的公钥来路有问题或是被替换了，那么，持有对应私钥的冒充接受方就有可能接收到发送方发送的报文。这里的问题就是：对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机那里发布的，而且没有被篡改过呢？亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢？这时候，我们需要有一个权威的值得信赖的第三方机构(一般是由政府审核并授权的机构)来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生。这种机构被称为证书权威机构（Certificate Authority, CA），它们所发放的包含主机机构名称、公钥在内的文件就是人们所说的“数字证书”。
数字证书的颁发过程一般为：用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布。数字证书各不相同，每种证书可提供不同级别的可信度。可以从证书发行机构获得您自己的数字证书。

6. `SSL`（Secure Sockets Layer)

当所有上面提及的技术介绍完之后，我们需要把它们统一起来应用于实际的网络安全传输了，因此，人们制定了一套协议，来定义有关的方方面面，这个协议就是SSL。
SSL建立通信的过程分为两个阶段：握手阶段和传输阶段。SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！这并不奇怪，因为非对称加密的速度缓慢，耗费资源。其实当客户端和主机使用非对称加密方式建立连接后，客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的，因为除了客户端和主机之外，不可能有第三方窃取并解密出对称加密密钥！(关于SSL在传输过程中是否使用了数字签名，目前还没有找到确切的答案。)

7. `HTTPS`

如果我们是在一开始来讲述HTTPS协议，那将会是一个很大的话题，但是讲到这里的时候，实现上所有关于HTTPS的内容，我们基本上已经讲完了，它所有依赖的所有安全技术就是上面我们所提及的，就像大家所知道的那样，HTTPS是由SSL+HTTP协议构建的可进行加密传输、身份认证（确认客户端连接的目标主机是否是真实正确的主机）的网络协议。
HTTPS的主要缺点就是性能问题。造成HTTPS性能低于HTTP的原因有两个：
1. 对数据进行加解密决定了它比HTTP慢。
2. 另外一个重要原因的是HTTPS禁用了缓存。
相关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。因此对于一个网站来说，只有那对那些安全要求极高的的数据才会选择使用HTTPS进行传输。

8. `SSH`免密登录过程

从客户端来看，SSH提供两种级别的安全验证：

8.1 第一种级别是基于口令的安全验证

（1）远程主机收到用户的登录请求，把自己的公钥发给用户。
（2）用户使用这个公钥，将登录密码加密后，发送回来。
（3）远程主机用自己的私钥，解密登录密码，如果密码正确，就同意用户登录。

缺点：如果有人冒充服务器，就会给你假服务器公钥，最后就能获得你回应的密码，这就是中间人攻击。

8.2 第二种级别是基于密匙的安全验证

（1）客户端创建一对公钥+秘钥，私钥放在客户端，将公钥放在服务器上。
（2）如果你要连接到SSH服务器上，客户件就会向服务器发出请求，请求用你的密匙进行安全验证。
（3）服务器收到请求之后，先在该服务器上寻找你的公钥，然后把它和你发送过来的公用密匙进行比较。如果两个密匙一致，服务器就用这个公钥加密一个【随机字符串】（“质询”）并把它发送给客户端；
（4）客户端收到【加密后的-随机字符串】（“质询”）之后，就可以用你的私人密匙解密，再把【随机字符串】（“质询”）发送给服务器。对比结果是否正确，如果正确就对客户端进行授权。

对这种模式下面举两个通俗易懂的例子：

假设一下，我找了两个数字，一个是1，一个是2。我喜欢2这个数字，就保留起来，不告诉你们(私钥），然后我告诉大家，1是我的公钥。我有一个文件，不能让别人看，我就用1加密了。别人找到了这个文件，但是他不知道2就是解密的私钥啊，所以他解不开，只有我可以用数字2，就是我的私钥，来解密。这样我就可以保护数据了。
我的好朋友x用我的公钥1加密了字符a，加密后成了b，放在网上。别人偷到了这个文件，但是别人解不开，因为别人不知道2就是我的私钥，只有我才能解密，解密后就得到a。这样，我们就可以传送加密的数据了。

与第一种级别相比，第二种级别不需要在网络上传送口令。第二种级别不仅加密所有传送的数据，而且“中间人”这种攻击方式也是不可能的（因为他没有你的私人密匙）。但是整个登录的过程可能需要10秒，但是相比输入密码的方式来说10秒也不长。

【完】