https技术如何保护你的安全

summary

type

status

date

slug

📝 本系列旨在介绍一系列网络安全相关的知识

https是什么？

HTTP（超文本传输协议）是一种用于传输网页（HTML文档）的协议。它定义了客户端（通常是网页浏览器）和服务器之间的通信规则。 HTTPS（全称是“超文本传输协议安全版”），是HTTP的安全版本。在HTTP和HTTPS中，“HTTP”代表“超文本传输协议”，它是互联网上用于传输网页的一种协议。而在HTTPS中，末尾的“S”代表“安全”。

早期互联网的HTTP

在早期的互联网上，网站主要通过HTTP（超文本传输协议）进行访问。HTTP是一种基本的网络协议，用于在网页服务器和客户端（通常是浏览器）之间传输网页代码。当你在浏览器中访问一个网站时，浏览器通过HTTP请求服务器发送网页代码，这些代码随后在浏览器中渲染成可视的网页。你可以通过在浏览器中按F12查看这些源代码。

HTTP并不安全

然而，HTTP的主要问题在于其安全性。HTTP在传输过程中使用的是明文连接，这意味着传输的数据（包括敏感信息，如登录凭据、个人信息、银行交易等）都没有加密，容易被截获和篡改。例如，如果有人在你的路由器后部署了一个设备，就可能截取你通过HTTP发送的所有数据。这种情况下，你的隐私和安全都处于风险之中。所以说，你如果访问http的网站，一般的浏览器都会有提示（如图）

HTTPS的“S”加密

正是由于HTTP的这些安全隐患，HTTPS（安全的超文本传输协议）应运而生。HTTPS在HTTP的基础上增加了SSL/TLS（安全套接字层/传输层安全）加密，这种加密机制使用非对称加密技术来确保数据传输的安全。非对称加密涉及两个密钥：一个公开密钥和一个私有密钥。这种方式确保了即使数据在传输过程中被截获，没有相应的私钥也无法解读数据内容。因此，HTTPS显著提高了数据传输的安全性，特别是对于敏感操作（如在线购物、银行业务等）来说至关重要。

一句话总结，就是：“HTTPS是一种通过加密通信来提高数据传输安全性的网络协议。”

重点在于安全！！下图是访问https的网站：

HTTPS的历史

为什么谷歌把http标记为不安全

1994年：网景通信公司（Netscape Communications）是最早推动加密网络传输技术的公司之一。他们开发了安全套接字层（SSL）协议，这是一种保护网络通信安全的标准技术。

1995年：网景发布了SSL版本1.0，但它从未公开发布，因为存在安全漏洞。随后，他们很快推出了SSL 2.0，这个版本在当时已经开始提供基本的加密保护。

1996年：SSL 3.0版本发布，这个版本比之前的版本有了显著改进，解决了许多安全问题。SSL 3.0被广泛认为是第一个真正安全的版本，为现代HTTPS加密奠定了基础。

1999年：传输层安全（TLS）协议1.0发布，作为SSL 3.0的后继者。TLS由互联网工程任务组（IETF）标准化，随着时间的推移，TLS逐渐取代了SSL。

2000年代初：随着电子商务和在线银行的兴起，对网络安全的需求显著增加，HTTPS开始广泛用于保护在线交易。

2010年代：随着互联网安全意识的提高，HTTPS从主要用于保护敏感交易，转变为一种网站的标准安全实践。搜索引擎和浏览器开始优先推荐使用HTTPS的网站，甚至对未采用HTTPS的网站给予负面标记。

2018年：谷歌Chrome浏览器开始将所有未使用HTTPS的网站标记为“不安全”，这促使更多网站转向HTTPS。

HTTPS的加密方式

非对称加密！

先看一个小故事

想象一下，你住在一个小镇上，需要给一个住在远方的朋友（我们称他为“服务器”）寄一封非常重要的信。但是，这个小镇的邮递系统并不安全，信件在途中很容易被别人（“黑客”）拦截和阅读。

为了保护你的信件，你和你的朋友决定使用一个特殊的锁和钥匙系统，这就是非对称加密。你的朋友给了你一个特殊的锁（公钥），这个锁可以被任何人锁上，但只能用一把特殊的钥匙（私钥）打开，而这把钥匙只有你的朋友持有。

！！！虽然都有“钥”这个字在这里，但是切记，公钥在这里的比喻是锁，不是钥匙。公钥只能锁上，锁上了自己都打不开。锁上了只有私钥可以打开。

现在，你写好了信，把它放进一个箱子里，然后用你朋友给你的那把特殊的锁锁上。你把这个箱子交给了邮递员。假设途中真的有个好奇的邮递员或者别的不怀好意的人（“黑客”）拦截了这个箱子。他们看到上面有锁，但他们没有钥匙，所以无法打开箱子来看看里面有什么。他们也不能替换里面的内容，因为一旦打开锁，就无法再用同一把锁锁上。

在我们的故事中，你通过一个不太安全的邮递系统发送了一封重要的信。为了保护这封信，你使用了一个特殊的锁（公钥）来加密信件，确保只有持有对应钥匙（私钥）的收件人（服务器）能够打开并阅读它。这个过程类似于在互联网上发送加密信息。

现在，让我们把这个故事与互联网的世界联系起来。在互联网的早期，大多数网站使用HTTP协议来传输数据。HTTP是简单、无加密的，就像是我们故事中的普通邮递系统。通过HTTP发送的数据，比如文本、图片、登录信息等，都是未加密的，就像是未加锁的信件，很容易在途中被拦截和阅读。

这就是为什么“S”出现了。“S”代表“Secure”，即“安全”。当网站使用HTTPS而不是HTTP时，它们就像是在我们的故事中给信件加上了一个特殊的锁。通过使用SSL（安全套接字层）或TLS（传输层安全）技术，HTTPS在数据传输过程中加密信息，确保即使数据在途中被拦截，没有对应的密钥也无法解读数据内容。

CA机构——钥匙从哪来，如何判断是不是假钥匙？

钥匙从何而来？有钥匙就安全吗？

证书颁发机构（CA，Certificate Authority）是负责颁发、管理和撤销数字证书的机构。这些数字证书用于加密通信中的身份验证和数据加密。

早期的CA：随着互联网的发展，需要一个可信的第三方来验证公钥的真实性，这就是CA的角色。最初的CA是随着互联网的商业化和电子商务的崛起在1990年代形成的。

CA的角色：CA的主要职责是验证申请数字证书的实体（个人、组织、服务器等）的身份，并颁发证书。这个证书将实体的身份与其公钥相关联，证明该公钥确实属于该实体。

CA和公钥的关系：CA通过颁发包含公钥的数字证书来确保公钥的真实性。这些证书是由CA的私钥签名的，因此任何人都可以使用CA的公钥来验证证书的真实性。

信任链：在这个体系中，用户必须信任CA，因为CA的角色是建立和保持整个公钥验证体系的信任。操作系统和浏览器通常预装了受信任的CA列表，用于验证证书的真实性。

慢着慢着，HTTPS的公私钥我还没搞懂捏！CA又是个啥？其实你点开网页连接的信息就能看到。（等会再介绍CA证书的组成结构）

再次回到那个小镇的例子。现在，除了你和你的朋友（服务器）之外，还有一个重要的角色加入：CA（证书颁发机构）。这个机构在小镇上是众所周知且值得信赖的，它的主要职责是验证人们的身份，并且为他们提供一种证明身份的方法。

验证和证书颁发：

在你的朋友想要开始接收加密邮件之前，他首先去找CA来验证自己的身份，并要求获得一个证书。CA检查他的身份证明，确认无误后，给了他一个官方的证书。这个证书就像是一个含有他的公钥和CA签名的印章。这样，任何收到这个证书的人都可以确定这个公钥确实属于你的朋友，并且得到CA的认证。

使用CA证书：

现在，当你想给你的朋友寄一封加密的信时，你首先要从CA那里获取你朋友的证书。看到证书上有CA的签名，你就知道这个公钥确实是你朋友的，并且没有被篡改。然后，你就像之前一样，使用这个公钥来加密你的信件，并将其安全地发送出去。

增加的安全性：

在这个过程中，即使有人试图假冒你的朋友并给你一个假的公钥，由于他们没有CA的认证，你会很快识破这个骗局。这就像是CA提供了一个额外的安全层，确保每个人都使用正确的公钥进行通信。

CA证书的组成

一个机构颁发的一堆证书如何写作的捏？

这是一个简单的证书结构（有一些不理解也正常，而且证书一般比这个还要复杂一点，这里就是给大家简单展示一下）

主题：证书的主题部分，包含证书持有者的相关信息。

颁发者：证书的颁发机构信息。

序列号：证书的唯一标识符。

有效起始 和 有效终止：证书的有效期限。

公钥：证书持有者的公开密钥。（就用这个上锁）

签名算法：用于签名证书的算法。

签名值：证书的数字签名。

啥是“根证书”

证书的层级结构

根证书是数字证书体系中的最高级证书，它由证书颁发机构（CA）发行并管理。根证书作为信任链的起点，是用来验证其他证书，例如中间证书和终端用户证书的真实性和可信度。这些根证书通常预先安装在操作系统或浏览器中，作为信任存储的一部分。由于根证书的重要性和敏感性，它们通常不直接用于签发普通的SSL/TLS证书，而是通过中间证书来间接发行，以增加安全性。这部分就不详细介绍了，想了解的可以参考wiki百科

Root certificate

In cryptography and computer security, a root certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed and form the basis of an X.509-based public key infrastructure (PKI). Either it has matched Authority Key Identifier with Subject Key Identifier, in some cases there is no Authority Key identifier, then Issuer string should match with Subject string. For instance, the PKIs supporting HTTPS for secure web browsing and electronic signature schemes depend on a set of root certificates.