🤹🏼 🐬 🦖 Patrik Patrick的TLS简介（第1部分） 🧑🏾‍🤝‍🧑🏼 💝 🍈

您可能已经知道，这是帕特里克。他是一个海星，这意味着可以在不侮辱他的情况下说他的手从一个地方伸出来。帕特里克（Patrick）也非常实用，会立即忘记所有他不需要的东西-但是如果他需要某些东西，他想知道（因为他需要它！）。剧透：这里Patrick正在尝试进行TLS握手。

本文是为Patrick和像他这样的人写的。她出生于我们在内部教育Plesk TechTalk上首次展示的演示文稿，在该演示文稿中，员工以易于访问的形式相互共享有关有趣的技术，流程和解决方案的信息。因此，本文中的图片将看起来像幻灯片：)报告原始文本的作者是程序经理Plesk Ruslan Kosolapov。

通常，所有TLS材料都涵盖了一些小方面，但没有涵盖大局。这不是很实际，帕特里克对此感到头痛。这里的一切都会有所不同：简短，适用于“日常生活”并尽可能详尽。

TLS是什么，对Patrick来说为什么？

TLS（传输层安全性）是传输层保护协议。需要这样做，以便没有人能“听”您并找出一些重要信息（如果我们谈论在网络上工作，则通常是密码）。并且为了保护自己免受传输过程中的篡改和流量篡改。 TLS的目的在于这两方面。

为了清楚起见，让我们将TLS握手视为对Patrick SpongeBob的呼叫。在通话过程中，有人可以窃听对话（站在Patrick旁边或在线路中间打开），通常SpongeBob可能不在另一端-所有这些问题都是相关的。为了解决这些问题，Patrick想使用TLS。

简而言之，最高级别的握手如下所示：

Patrick：我想使用TLS，密码版本是如此。
Spongebob：好的，让我们使用诸如此类的密码版本。

之后，海绵宝宝发送了证书，帕特里克检查了证书，说一切都很好，会话密钥已经完成（实际上有两个，但是没关系）。为什么使用会话密钥而不是非对称加密-因为它更快。在那之后，他们开始说一种不可理解的语言。因此，一切都受到保护。

一切似乎都很简单。它在硬件上的工作方式对我们而言并不重要。但是，如果您开始思考-帕特里克开始思考！ -提出了一个问题，即如何普遍同意我们将使用TLS？毕竟，曾经没有TLS，但只有普通协议-SMTP，HTTP。怎么说TLS需要什么？在我们行业中，一切都照常进行-有很多方法！

首先，他们想使用特定的端口，这意味着在其上使用TLS。这有什么缺点？为什么会出现用于启动TLS会话的显式（显式）方法呢？有以下几个原因：

您需要大量的端口-端口是您不想花费的东西。因为数量越多，配置防火墙就越困难。
服务器可以忽略它-它已连接到端口443，并且那里没有TLS，只有HTTP而没有任何HTTPS。
建立连接之前，您无法确定是否支持TLS服务器。

所有这些导致了显式方法的出现-当我们连接到常规端口，然后将会话升级到TLS时。对于不同的服务，协议具有不同的命令，例如，对于SMTP，在SMTP协议级别有一个单独的命令-STARTTLS。HTTP也有这样一个笑话，它被称为Upgrade：TLS / 1.0。在协议级别，更容易了解是否支持TLS服务器。

让我们再详细介绍一下不同类型的连接以及使用TLS的情况。

连接：HTTP

如果像往常一样没有细微差别，一切都会变得容易。对于HTTP，不断增长的安全要求提供了使用TLS的过程的不断发展。最初，存在到HTTPS的重定向，这很简单地在标头中完成。这给漏洞留下了漏洞，因此谷歌同行提出了HSTS（HTTP Strict Transport Security）。 HTTP响应中的标题就是这样，它告诉浏览器：“请记住，即使此人告诉您使用HTTP，即使您来到此域，也请直接使用HTTPS”。因此，没有重定向，并且一切都更加安全。此外，Google还有另一个计划-您可以提出请求，以便将您的网站添加到Google Chrome浏览器“始终使用HTTPS”列表中，而不管标题如何。

简要地： HSTS解决了从HTTP到HTTPS的重定向漏洞，因此几乎所有浏览器都支持HSTS，这很好。

连接：外来的（不仅限于新版本的HTTP）

在HTTP / 2中，使用TLS的好处是：始终使用TLS（因为现在已经制作了浏览器）。此外，HTTP / 2中的TLS必须是最新的-即版本为1.2+。

最有可能的是，Google很快就会出售HTTP / 3的广泛使用，现在它已被IANA标准所采用。它的出现和发展的故事令人困惑。要记住的主要事情帕特里克：

HTTP / 3始终是TLS 1.3+。
HTTP / 3基于QUIC-它是基于UDP的协议，据Google称，它比TCP更好。实际上，在最终批准名称HTTP / 3之前，该协议称为HTTP-over-QUIC。

仍然有一个有趣的SCTP协议，主要在电信中使用。在其上方，同时使用TLS和DTLS（这是UDP的TLS）。

简要地说：在2年内，QUIC（即HTTP / 3）将在所有地方使用，但是现在应该已经在所有地方都使用HTTP / 2了，但实际上并没有在所有地方使用。

连接：邮件

许多客户端认为第587端口上应该有TLS，但这里也有细微差别：有人默认情况下期望TLS，有人期望客户端发出明确的STARTTLS请求。因此，邮件服务器和邮件客户端的各种组合有时会导致不良影响。例如，客户端进入端口587，期望会有TLS，而服务器等待客户端明确请求STARTTLS。客户端什么都没收到，则回滚到端口25。结果是无提示切换到不安全的SMTP连接。在测试和开发时，值得记住客户端-服务器组合的这种影响。 Autodiscaver具有多种用于指定TLS的选项：应如何设置，期望什么以及应该做什么。许多邮件客户端了解这些内容。

简要地： 使用邮件服务器和邮件客户端中的TLS支持，通常情况下一切都很好，但是在特殊情况下，可能会出现问题，并且对TLS扩展的支持不是很好。

连接：FTP

这里无话可说。主要问题是SNI（这是当不同IP地址位于不同域时）。在FTP级别上，不会传输域名。在显式版本中，它无法工作，因为没有地方可以编写它。解决方案有几种-有些提供了这样的选择，有些提供了这样的选择，尚未采用通用解决方案，没有标准。

简要地说：对FTP有某种TLS支持（FTPS，SFTP-通过SSH实现的FTP的类似物），但是由于FTP本身的技术限制，因此未涵盖某些方面。

TLS握手

因此，现在我们知道了如何在不同的连接中使用TLS发起通信，并且Patrick能够将自己的愿望传达给SpongeBob。一旦他们同意使用TLS，就会生成TLS握手。其结果应该是客户端和服务器之间就如何对其全部加密的协议。另外，客户端必须确保服务器是所需的服务器。有时服务器还会检查客户端（但频率要低得多）。

密码和版本

如前所述，第一步是选择将使用哪个版本的TLS和哪些密码进行加密。通常，密码如下所示：

密码套件在IANA注册中心中，而在TLS协议中，二进制格式只是其ID。从图中可以看出，这里不仅（而且不仅是）密码，而且还包括其工作模式以及TLS握手所需的其他详细信息。帕特里克无需赘述。在此阶段重要的是记住这些字母是好的（其余字母是不好的）：

DHE
心电图
AES128
AES256
RSA
Ecdsa
炭黑
厘米
SHA256
SHA383
CHACHA20
保利1308

记住好的密码的图片：

如果很难记住，有很好的服务可以告诉您有关密码的信息，例如Mozilla ssl-config.mozilla.org的服务。

您可以立即看到在何处以及如何获得支持-这是Mozilla家伙试图遵循的目标。

一个有趣的细节：客户端根据其偏好按优先级顺序传输密码，但是服务器留有决策权-它从受支持的客户端列表中选择看起来最好的密码。

双方还指出了协议的最大支持版本-在这种情况下，Patrick比SpongeBob更高级。

实际上是证书

连同答案“让我们这样做”，服务器发送其一个或多个证书-可以有很多证书。

什么是证书？这是信息（主题）之间的关系-通常是域或组织的名称-与公钥（公钥）之间的关系。也就是说，证书上写着：“伙计，我的公钥就是这样。现在，在他的帮助下，我们将就会话密钥达成一致。”另外，在其帮助下，您可以检查证书或其他内容的签名。即，原则上可以使用不是证书，而是使用表明此关系的注册表。实际上，朝着这个方向前进的步骤仍在继续，因为证书颁发机构机制被认为不是很好，因此别无其他。

因此，该证书的结构是颁发该证书的“主题：公钥”加上ishyuer的签名（译为俄语的发布者看上去很糟糕，但在此与“发布者”非常接近）。 Ishüyer还拥有证书和某人与某物的联系。您可以通过获取ishyuere的公钥并检查签名来检查证书的正确性。结果，在这里不能伪造任何东西。

让我们看一下证书，看看它可能有什么问题。

首先，尽管某些软件认为序列号在整个宇宙中都是唯一的，但序列号仅在ishyuere的范围内暗示唯一性。幸运的是，它经常是完全独特的。

该证书还指出了用于加密和签名的算法：RSA或ECDSA-也就是说，用于与该公钥一起使用的加密技术。 RSA与ECDSA之间的主要区别在于ECDSA的数学原理基于椭圆曲线，而RSA仅基于自然数，因此它速度较慢，并且使用了较大的密钥位（3-4千个）来防止破解。对于ECDSA，一个300位的密钥就足够了，并且运行速度更快。因此，许多人都在转向ECDSA-握手本身很沉重，我想减少这种握手。签发证书时可能会要求ECDSA，如果探矿者支持该证书，他会为您完成。但是证书的签名取决于ishuiur当前拥有的私钥，而不取决于您是否要求ECDSA或RSA。因此，浏览器可以显示一个在签名中，另一个在公钥中，如果签名不是ECDSA，就不必担心。

如何获得证书？

简而言之-这样：

Patrick告诉证书颁发机构：我需要证书。此人（或组织）检查是否为Patrick。支票可以有很大的不同。当然，作为客户端的Patrick可能没有证书，但是如果服务器没有证书，那么将没有TLS。检查证书申请中是否正确指示了所有内容，帕特里克是否真的拥有他正在请求证书的主题。这是由更高级别的证书颁发机构中心（每个人都相信的有条件人员）完成的。要发布证书，您需要草拟CSR（证书签名请求，证书请求）。

这也是一个结构，很难使用，因为很少有服务可以让您设置，指定，验证和查看所有内容。

总计，我们生成了一对公钥：私钥，但是我们只提供公钥，而隐藏私钥。然后，我们生成一个证书签名请求，并使用我们的私钥对其进行签名。我们将所有这些都发送给证书颁发机构，然后它开始验证。可能会有所不同，对于特别酷的证书，有一些特殊的棘手程序，但我们将继续介绍一般情况。

民航局

这个问题使每个人都认为有时不是很好的人。 Symantec成为DigiCert一部分的原因之一是因为它（Symantec）在不询问域所有者的情况下颁发了证书。您无法做到这一点，这侮辱了所有人，但最主要的是侮辱了赛门铁克本身，因为您必须出售自己的业务。为了减少服务器对这种无良同志的依赖，需要使用诸如CAA RR之类的东西-DNS中的记录，该记录表明所有者允许谁为其域颁发证书。 Plesk中也有此功能，到目前为止，它很少使用，大致类似于DNSSec，但仍然可以使用。所有证书颁发机构都同意检查该条目，如果表明无法颁发此证书颁发机构，则会显示：“您没有通过验证，它是用CAA RR编写的，我无法为您写出证书”，也不会写出。如果没有条目，则可以。现在，Google正在推动这一举措，以便客户检查所收到的证书是否符合CAA RR记录。辩论仍在进行中。

同样，从我们在Plesk中提供支持的那一刻起，CAA RR就会通过指明验证方法（也就是说，您还可以在此处指明您使用哪种方法来验证此域是您的域）和帐户URI（统一资源标识符）来进行扩展。在用户中很受欢迎Plesk Let's Encrypt已经支持所有这些功能（做得好！）。

所有这些都适用于任何类型的证书，并且由于我们稍后将讨论差异，因此是时候更详细地讨论类型了。

证书类型

其中有三个：

域验证

该主题是一个域，也就是说，在这里我们仅对其进行检查。以前，在没有自动验证器的情况下，验证主要通过Whois服务通过电子邮件进行。这被认为足以证明您是此域的所有者。然后他们考虑通过DNS进行检查-他们通过电子邮件给您写信：“并将这样的记录添加到DNS中”。后来出现了自动方法（我们将进一步讨论ACME）。

组织验证

在“主题”字段中，除域名外，还指示组织的名称。检查包括验证域是否属于该组织，以及来此证书的人员是否在该组织工作。怎么做：他们在登记册上寻找组织，打电话，要求做点什么（电话是正确的，正确的人回答了，这意味着一切都很好）。

扩展验证

与OV相同，只是较冷。这里的所有内容都受到严格的管制-本着“在5.6.8中应该是……的精神”的精神，长达40页的文档，等等。检查了很多事情-国家，部门（如果在应用程序中指明），有时甚至还有一个特殊的人用眼睛去看。实际区别是什么？几乎所有浏览器都不再区分OV和DV，这很不好，因为在这种情况下，不会显示组织名称。结果，没人愿意创建一个域名aliepxress.ru，绘制同一页面并窃取信用卡。创建任何此类域并在其上获得DV证书都是绝对合法的。

EV的示例-在这里可以看到组织的名称，因此，如果有人偷了东西，用户将知道它是Valve Corp公司，注册该公司要比域名困难（更多检查）。

但是，一切都到了EV不再不同的地步，在移动设备上它不再可见，您需要按一个单独的按钮，在Safari中也是如此。谷歌浏览器仍然保持（UPD-不再！我必须从IE制作一个屏幕）。那些不露面的人的论点是：“如果您担心，请单击并看”，但没人会自然地按下。

获得证书：自动化

现在让我们谈谈自动接收DV证书的问题。为了清楚起见，让我们看看我们最喜欢的“让我们加密”是如何做到的。如果有人感兴趣的话，他一般都有很好的文档，甚至还有俄语。

ACME

ACME（自动证书管理环境）是一种协议，旨在自动化和标准化获取证书的过程。

ACME如何证明您是域名所有者？您说：我想要一个证书并指出自动验证的类型-例如ACME HTTP-01。让我们加密要求您将数据放入文件中，如果可以将文件放在您的域中（让我们加密可以通过HTTP从那里提取文件），则可能是它的所有者。现在，这种方法（包括来自Google的方法）遭到了批评，因为它无法防止网络钓鱼。也就是说，通过手动验证，aliepxress.ru域可能会引起怀疑，但是到目前为止，“让我们加密”本身还是不知道（或者可以，但是很糟糕）。

DNS挑战

除了ACME，还有DNS挑战。例如，他们告诉您：在DNS区域中输入txt记录，然后将数据放入其中。还有其他方法，但并不常见，一种方法被完全取消了，因为它证明是脆弱的。Plesk中的功能：通配符证书（只能使用DNS挑战将其写出）不适用于许多人，因为Plesk通常不管理域的DNS区域和扩展名Let's Encrypt不能自动在DNS区域中创建记录。

关于加密的另外两个词

使用“让我们加密”证书的一个重要方面是限制。如有疑问（或怀疑已实现），最好遵循以下链接：letsencrypt.org/docs/rate-limits

有时它们会被更新。人们忽略了一个显而易见的限制：大多数情况下，根据支持请求，他们在证书中面临100个域名的限制。让我们加密还拥有一个登台服务器，还有更多限制，但是这种证书被认为是不可信的，对于浏览器，它们类似于自签名。在实践中，最多只能有100个名称（尽管Plesk上的站点总共有1,300,000个“让我们加密”证书）。根据我们的统计数据，每个证书的中位数为20个名称。因此，如果某事无效，请看-也许已达到极限。让我们加密具有良好的错误报告，通常您可以了解发生了什么。

下一步是什么？

因此，在收到证书后，服务器将传输会话密钥数据-这将用于加密。如果服务器认为有必要对客户端进行身份验证（例如，访问权限仅对特定人群开放），他可能会问：客户端，您是谁？然后客户将需要发送他的证书。客户端收到ServerHelloDone消息后，意识到是时候验证证书并使用密钥了。

在TLS 1.3通过开放通道之前，我们讨论的所有内容，任何人都可以看到。您可以了解一些有趣的攻击信息。
在本文的第二系列中，我们将学习客户端如何验证证书。

Patrik Patrick的TLS简介（第1部分）