假设 JayP 希望通过公共互联网连接到 youtube.com。在进行任何沟通之前,会出现一些问题:
他如何验证他确实正在与 youtube 进行通信? (验证)
JayP怎么知道没有人拦截他的消息呢? (保密)
另外,他如何确定没有人更改消息? (正直)
好吧,让我们分别解决每个问题。首先,JayP应该验证Youtube的身份。为此,他需要 YouTube 的公钥。公钥代表 youtube 的身份。
问题是,攻击者想出了一些方法来拦截互联网上从一台计算机到另一台计算机的请求并发起中间人攻击。通过这种攻击,我们的攻击者 Chady 会注入自己的公钥,让 JayP 认为他正在与 Youtube 通信,而实际上,他正在与 Chady 通信。
Chady 潜入并发送了他的公钥。
现在你可能会想,可怕,不是吗?想象一下这种攻击可能会发生什么,从窃取登录凭据或信用卡详细信息等个人信息到恶意软件分发或其他恶意目标。那么,JayP 如何确定他收到的公钥确实来自 Youtube?这就是数字证书的用武之地。(TADAAA)
他们确保公钥确实来自 Youtube,而不是来自恶意的 Chady。其实数字证书不仅可以用于HTTPS,还可以用于邮件、IOT、VPN……
数字证书将包含相当多的信息,让我们探讨最重要的信息:
颁发者是签署此证书的第三方,我们稍后会详细介绍。一些基本信息包括通用名称、组织和国家/地区。
当然,数字证书也会包含它的Validity ,有两个关键字段,not before 和 not after
主题是证书的所有者,在我们的例子中是 Youtube。主题将包含公用名称、地址等信息,最重要的是公钥。
最后,数字证书包括其签名。这是由颁发者签署的签名,证明该证书是真实的。
数字证书由称为证书颁发机构的实体(例如 DigiCert、Comodo、Symantec、Google Trust Services)进行签名。
但是等等,什么是证书颁发机构?
简而言之,证书颁发机构是负责颁发数字证书的受信任的第三方组织。
证书颁发机构有自己的公钥和私钥。接下来,我们来解释一下签名是如何制作的。
例如,前面提到的数字证书中包含的信息将使用SHA-256 算法进行哈希处理。生成哈希值后,证书颁发机构使用 RSA 非对称密钥加密技术使用其私钥对哈希值进行加密。该加密的哈希值是证书的签名,只能使用证书颁发机构的公钥进行解密。任何拥有签署此证书的证书颁发机构的公钥的人都可以解密并验证该证书是真实的且未被篡改。
当浏览器收到证书时,它将使用相同的哈希算法(在本例中为 SHA-256)对其端的所有信息进行哈希处理。然后,它使用证书颁发机构的公钥对签名进行解密,以获得从证书颁发机构收到的哈希值。如果两个哈希值匹配,则浏览器可以确认该证书确实来自所声明的证书颁发机构。
证书颁发机构存在层次结构 - 根证书颁发机构和中间证书颁发机构。
这些根CA实际上并不直接为服务器颁发任何数字证书。它只为代表其行事的中间 CA 颁发数字证书。中间CA可以为另一个中间CA颁发数字证书,也可以直接为服务器颁发数字证书。
因此,存在从根 CA 到服务器的信任链。
操作系统与信任存储捆绑在一起,这是受信任的根证书颁发机构的列表。该列表由苹果和微软等操作系统制造公司维护。它们都需要根证书颁发机构进行一项或多项审核,以证明其可信度和有效性。
首先,我们假设 youtube.com 是一家全新的初创公司。 YouTube 了解公共互联网上安全的必要性,因此必须拥有可信的数字证书并将其呈现给访问者。
首先,Youtube 寻找中间证书颁发机构。请记住,中间证书颁发机构是服务器和根证书颁发机构之间的中间人。就 Youtube 而言,Google 有自己的证书颁发机构,称为 Google Trust Services。
选择中间 CA 后,Youtube 会发出证书签名请求。证书签名请求将包含 Youtube 数字证书中包含的信息,例如通用名称、组织,以及最重要的 Youtube 的公钥。 YouTube 会将证书签名请求发送给中间 CA。
中间证书颁发机构将验证包含有关所有者(也称为主题)的信息的 CSR。然后,它添加颁发者信息(有关中间证书的信息)和有效性等字段,然后按照前面在签名过程中说明的方式对所有这些信息进行签名。签名后,中间证书颁发机构将向youtube发回数字证书。
YouTube 现在可以将其新购买的数字证书附加到其网络服务器上。
当他连接到Youtube时,Youtube会发送自己的证书和中间证书颁发机构的证书。不会发送根证书颁发机构,因为它在 JayP 的操作系统上可用。 Youtube的证书会包含颁发者信息,即中间证书颁发机构。因此,浏览器将知道该证书是由 Google Trust Services 中间证书颁发机构签署的,并且将拥有其证书。如前所述,任何数字证书都将包含信息和签名。浏览器会对所有信息进行哈希处理以获得其哈希值。然后,它将使用颁发者的公钥(即中间证书颁发机构的公钥)解密签名。再次请记住,签名只能使用发行者的公钥来解密。之后浏览器将比较两个哈希值,如果它们相同,则验证链的这一部分,并且浏览器将继续验证中间证书颁发机构,因为如上所述,中间证书颁发机构不直接受信任操作系统。
好的,现在浏览器将验证 Google Trust Intermediate Certification Authority 的证书。该中间证书由 Google Trust Services 根证书颁发机构签名。请注意,在此步骤之前,我们可以在最终证书和根证书之间拥有许多中间证书颁发机构,并且对于链的每个部分都会发生相同的验证过程。
在我们的示例中,我们将只坚持其中一个。如前所述,中间证书颁发机构的证书签名将使用根证书颁发机构的公钥进行验证。当到达根证书颁发机构时,链就结束了。自签名的根证书颁发机构将在 JayPee 操作系统的信任存储中提供。
就是这样!经过此验证后,浏览器将显示一个漂亮的锁定图标,就像您浏览器中的图标一样。现在可以保证确实与 Youtube 进行通信并且是安全的(万岁)
在结束之前,我们将简短地解释三种主要类型的 TLS 证书。
单个域证书旨在保护单个完全限定的域名。这意味着该证书仅对一个特定域有效,不涵盖任何子域或其他域。例如,对于域“www.youtube.com”,单个域证书将仅保护该域,而不保护任何其他变体,例如“academy.youtube.com”或“blog.youtube.com”
使用案例:当您有一个不需要额外子域的网站或 Web 应用程序时,单域证书是理想的选择。它们是保护特定域的最直接且最具成本效益的选择。
接下来,我们有一个通配符证书,它是一种使用单个证书为主域及其所有子域颁发的 TLS 证书。通配符星号用在通用名称 (CN) 字段或主题备用名称 (SAN) 字段中,表示涵盖指定域下的任何子域。例如,如果您有“ .youtube.com”的通配符证书,它将保护“youtube.com”、“academy.youtube.com” 、“blog.youtube.com”等。
使用案例:通配符证书使您无需管理和续订每个子域的单独证书。但是,需要注意的是,通配符证书仅覆盖一级子域。例如,“*.youtube.com”的通配符证书不会涵盖“academy.blog.youtube.com”。
多域证书(也称为主题备用名称证书)允许您在单个证书中保护多个不相关的域。每个要保护的域或子域都列在证书的使用者备用名称 (SAN) 扩展中。
例如,谷歌和其他大公司会使用这些多域证书。主要好处之一是简化证书管理:Google 运营大量网络服务和应用程序,每个服务和应用程序都有自己的域或子域。使用多域证书允许他们将多个域或子域的证书管理整合到单个证书中。这简化了证书颁发、更新和监控的过程。
而且,就是这样。请花一些时间观看动画课程。
在我的下一篇文章中,我将讨论 TLS 加密。
也发布在这里。