首先，我们不能谈论HTTP或HTTPS。让我们从聊天软件开始吧。我们要实现一个发送问候信息给B：如果我们实现这个聊天软件，本文只考虑安全问题，我们需要实现A到B的消息包的问候，哪怕是通过中介拦截，您无法知道邮件的内容。
如何真正安全？
这个问题，很多人立刻想到了几种加密算法，其中对称加密，非对称加密，DES，RSA，XX，?
我想说加密算法只是一个解决方案。我们必须做的第一件事是理解我们的问题领域——什么是安全性？个人理解是：A和B传达内容，只有A和B能够看到通信的实际内容。那么，问题的领域已被定义（实际上，当然，不仅仅是这个定义）。对于该解决方案，很容易考虑加密消息。对于像A和B这样的简单通信模型，我们可以轻松做出选择：
这是对称加密算法，其中图的密钥S同时执行加密和解密的功能。具体细节不是本文的范围。每当这个键S不会公开给第三方和关键S是足够安全的，我们解决了你在一开始指定的问题域。因为世界上只有A和B知道如何加密和解密它们之间的消息。
但是，在WWW环境中，我们的Web服务器的通信模型并不那么简单：
如果服务器对所有客户端通信使用相同的对称加密算法，则它等效于非加密。我该怎么办？也就是说，您可以使用没有公钥的对称加密算法。答案是：Web服务器对每个客户端使用不同的对称加密算法：
如何确定对称加密算法
慢慢地，另一个问题出现了：我们的服务器如何告诉客户端使用什么对称加密算法？当然是通过谈判。
但是，其谈判过程未加密，或者将被中间人拦截。然后，我们将对这个协商过程进行对称加密，然后你仍然没有加密协商过程的加密。我该怎么办？相互作用并不好......嗯，这对鸡来说是个问题。 。
如何加密协商过程。
新问题是，如何加密谈判过程？密码学领域，有一个叫加密算法“非对称加密”的特点是加密私钥的密文，只要公共密钥才能解密，而公钥后的密文只有加密，私钥可以被破译。私钥仅供一个人使用，公钥可以发送给所有人。
虽然A，B，...的服务器地址仍然不安全，但至少A，B对服务器是安全的。那么，如何协商加密算法，解决了我们：非对称加密算法，用于协商的对称加密算法。现在，您了解为什么HTTPS需要对称和非对称加密算法吗？谈判加密算法
为了使Web服务器为每个客户端使用不同的对称加密算法，我们不能让第三方知道这种对称加密算法是什么，我该怎么办？使用随机数使用随机数生成对称加密算法。这样，服务器和客户端之间的每次交互都是新的加密算法，只有在进行交互时才确定加密算法。
现在，您了解为什么HTTPS协议的协议阶段有这么多随机数。
如何获取公钥？
细心的人可能已经注意到，如果使用非对称加密算法，我们的客户端A，B必须从一开始就维护公钥，否则他们无法进行加密。现在，我们发现了新问题，如何让客户A和B安全地获取公钥？我能想到的唯一解决方案是：
解决方案1.服务器将公钥发送给每个客户端。
解决方案2.服务器将公钥放在远程服务器上，客户端可以请求它。
我们选择了选项1，因为方案2有另一个请求，我们必须处理公钥的位置。
如果公钥被转移会怎么样？是鸡蛋还是鸡肉？
但是，选项1存在问题：如果服务器将公钥发送给客户端并由代理转移，我该怎么办？绘制图像很容易理解：
显然，默认情况下，每个客户端的每个浏览器都保存所有网站的公钥是不现实的。
使用第三方机构的公钥来解决鸡蛋和鸡的问题
调用公钥的问题是因为我们的客户端无法知道返回公钥的人是中介还是真实服务器。这实际上是加密认证的问题。如果你让我解决它，你如何解决它？如果您了解HTTPS，您将知道如何使用数字证书来解决它。但您如何看待证书的性质？放弃您的HTTPS知识，并尝试自己找到解决方案。
我解决了这个问题由于服务器需要将公钥传递给客户端，因此进程本身并不安全，为什么我们不再对该进程进行加密？但是，您使用对称加密还是非对称加密？这很好，我觉得我已经进入了鸡蛋和鸡肉的问题。
这个问题的难点在于，如果我们选择直接花费的公钥给客户，我们不可能解决由中介提供的公共密钥的问题。因此，我们不能直接从服务器到客户端的公钥，但第三加密使用其私钥我们的公钥，然后传递给客户端。然后，客户端使用第三方的公钥对其进行解密。
下图是我们数字证书的第一个版本。证书仅包含服务器提供给第三方组织的公钥，公钥由第三方组织的私钥加密：
如果可以解密，则意味着代理尚未传输公钥。因为如果中间设备使用私钥对客户端进行加密，则客户端无法使用第三方公钥对其进行解密。此时，我以为我已经解决了这个问题。但实际上HTTPS，还有一个数字签名概念，我无法理解你的设计理由。我错过了一个场景：一个第三方机构，不仅可以产生一个证书的公司，也可能会发出一个中等规模的公司，这样的邪念证书。通过这种方式，中间人有机会转移他的证书。在这种情况下，客户端无法判断它是否是他的证书或中间人。因为无论中介还是其证书，您都可以使用第三方代理机构的公钥进行解密。像这样
当第三方向多家公司颁发证书时：
客户可以解密由同一第三机构颁发的所有证书：
最终，具有相同第三方机构证书的其他中介可以进行转移：
数字签名解决了处理同一机构颁发的不同证书的问题。
要解决这个问题，我们必须先考虑一个问题，并确定同一机构下不同证书的责任。我们应该把它放在哪里？它只能放在客户端上。这意味着在获得证书后，客户端能够区分证书是否已被篡改。我怎么能拥有这种能力？
我们从现实中寻找灵感。例如，如果您是人力资源部，您可以获得候选人的学历证书。证书表明证书持有者，签发机构，签发时间等。同时，证书还有一个最重要的证书号码！我们如何识别此证书的真实性？每当在证书编号中验证相关权限时，如果证书中的证书持有者与实际候选人一致并且证书编号也可以对应，则证书为真。
我们的客户可以使用此机制吗？因此：
但是，这个“第三方组织”在哪里？这是远程服务吗？不可能？如果是远程服务，则所有交互都会很慢。因此，此第三方组织的身份验证功能只能本地放在客户端上。
客户端如何在本地验证证书？
客户端如何在本地验证证书？答案是证书本身告诉客户如何验证证书的真实性。也就是说，证书告诉您如何根据证书的内容生成证书编号。客户端获取证书后，将根据证书方法生成证书编号。如果生成的证书编号与证书中的证书编号相同，则证书为true。同时，为了防止证书号码的转移，第三方的私钥用于加密。
这个地方有点抽象，让我们拍照以帮助理解：证书是如图所示生成的。证书中的“MD5号码生成方法”告诉客户端他可以通过使用MD5评估证书的内容来获得证书号。
客户端获得证书后，他开始验证证书的内容。如果客户端计算的证书编号与证书的证书编号相同，则验证通过：
但是第三方组织的公钥如何在客户端的机器上运行？世界上有这么多机器。实际上，实际上，浏览器和操作系统都维护着第三方组织的授权列表（包括其公钥）。由于客户端收到的证书将由权限机构写入，客户端将根据权限值在本地找到相应的公钥。
说到这一点，大概每个人都知道证书是HTTPS中的数字证书，证书号是数字签名，第三方组织是指数字证书颁发机构（CA）。
CA如何向服务器颁发数字证书？
当我听到这个问题时，我错误地认为我们的SERVER需要向CA部门服务器发送网络请求以获取此证书。事实上，问题应该是如何向我们的网站管理员发放CA以及我们的管理员如何将此数字证书放在我们的服务器上。
我们如何申请CA？每个CA组织都是类似的：
获得证书后，我们可以为自己的服务器配置证书。那么，如何配置？这些是具体的细节，让每个人都去探索。
也许我们必须对想法进行分类
我们尝试通过计算恢复HTTPS设计过程。通过这种方式，我们了解为什么HTTPS比HTTP更多地交互，为什么HTTPS性能低，并找到HTTPS的性能优化点。许多以前的工作是允许客户端和服务器协商安全的对称加密算法。这是HTTPS中SSL/TLS协议的主要工作。其余的是双方在通信期间使用这种对称加密算法进行加密和解密。
以下是HTTPS协议的真实交互图：
你能用句子总结一下HTTPS吗？
答案是否定的，因为HTTPS本身太复杂了。但我仍然试图使用段落来总结HTTPS:
HTTPS是一种对称加密算法，必须用于确保客户端和服务器之间的通信。但是，协商对称加密算法的过程需要使用非对称加密算法来保证安全性。但是，直接使用非对称加密的过程不是。安全性，中介将有可能操纵公钥，因此客户端和服务器不会直接使用公钥，而是使用数字证书颁发机构颁发的证书来保证进程的安全性。非对称加密。通过这种方式，通过这些机制协商对称加密算法，并且双方都使用该算法进行加密和解密。因此解决了客户端和服务器之间通信的安全性问题。
上海IT外包服务网 链接：http://www.linemore.com
中文
在线咨询
电话咨询
微信咨询
公众号
