0%

【翻译】https如何工作

HTTPS 就是标准 HTTP 协议 + SSL/TLS 加密技术。除非出现严重问题,否则它可以防止 Eve 这种臭名昭著的人查看或修改你的的请求;它可以保证你的密码、信息和信用卡数据在你的电脑和正确的服务器之间传递时的安全。虽然绿色的小挂锁和地址栏中的字母”https”并不意味着你和你正在浏览的网站不会被 hack,但它们至少可以帮助你安全地进行通信。

1. 什么是 HTTPS,它有什么作用?

HTTPS 基于 HTTP 协议,并在其之上增加了一个 SSL/TLS(以下简称为 “SSL”)加密层。服务器和客户端之间仍然使用 HTTP 协议规范进行通信,但通过安全的 SSL 连接,对其请求和响应进行加密和解密。SSL 层有 2 个主要目的:

  • 验证您是否与直接正确的服务器通话。
  • 确保只有服务器能读取你发送的内容,也只有你能读取它响应的内容。

真正巧妙的部分是 – 任何人都可以拦截你与服务器交换的信息,包括你们正在商定使用的密钥和加密策略,但仍然无法读取你发送的任何实际数据。

2. 如何建立 SSL 连接

客户端和服务器之间的 SSL 连接是通过握手建立起来的,其目标是:

  • 确保客户端与正确的服务器通话(或者反过来)。
  • 商定一个 “密码套件”,其中包括他们将使用哪种加密算法来保护数据。
  • 商定该算法所需的密钥

一旦建立了连接,双方就可以使用约定的算法和密钥安全地发送消息。我们将把握手分为 3 个主要阶段–’你好’、’证书交换’和’密钥交换’:

  1. Hello - 握手开始于客户端发送的客户端请求。客户端请求里包含了服务器通过 SSL 连接到客户端所需要的所有信息,包括各种密码套件和它支持的最大 SSL 版本。服务器以服务器响应作出回应,其中包含了客户端所需的类似信息,包括根据客户端的偏好决定将使用哪种密码套件和 SSL 版本。
  2. 证书交换–既然已经建立了联系,服务器必须向客户证明其身份。这是通过 SSL 证书来实现的,SSL 证书就像它的护照一样。一个 SSL 证书包含各种数据,包括所有者的名字,它所连接的财产(如域名),证书的公钥,数字签名和证书的有效期信息。客户端会检查是否隐含地信任该证书,或该证书已被多个证书签发机构(CA)中的其中一个核实及信任,并隐含地信任该证书。稍后会有更多关于这方面的内容。请注意,服务器也可以要求证书来证明客户端的身份,但这通常只发生在非常敏感的应用中。
  3. 密钥交换–客户端和服务器实际交换的消息数据的加解密将使用对称算法来完成,其确切的性质已经在 Hello 阶段达成一致。对称算法在加密和解密时都使用一个单一的密钥,而非对称算法则需要一个公钥/私钥对。双方需要就这个单一的对称密钥达成一致,这个过程是使用非对称加密和服务器的公钥/私钥安全完成的。

客户端生成一个随机密钥,用于主要的对称算法,并使用同样在 Hello 阶段商定的算法和服务器的公钥(在 SSL 证书上找到)对其进行加密。客户端将这个加密后的密钥发送给服务器,服务器使用私钥进行解密,握手的有趣部分就完成了。双方都很高兴,因为他们正在和正确的人交谈,并且已经秘密地商定了一个密钥来对称地加密他们将要发送给对方的数据。现在,HTTP 请求和响应可以形成一个明文信息,然后加密后发送。对方是唯一一个知道如何解密这个消息的人,所以中间人(攻击者)无法读取或修改他们可能截获的任何请求。

3. 证书

3.1 信任

基本上,SSL 证书就是一个文本文件,任何有文本编辑器的人都可以创建一个。你可以轻而易举地创建一个证书,声称你是谷歌公司,你控制着域名 gmail.com。如果这就是整个流程,那么 SSL 就会成为一个笑话 – 身份验证实质上就会变成:客户端问服务器 “你是 Google 吗?”,服务器回答 “呃,是的,这里有一张纸,上面写着’我是 Google’”,客户端说 “好的,太好了,这是我所要的数据”。防止这场闹剧的关键之处在于数字签名,它可以让一方验证另一方的纸片是否真的合法。

有两个合理的理由可以让你信任证书:

  • 它在你隐性信任的证书列表中
  • 它能够证明它被上述列表中的一个证书的控制者所信任。

第一个标准很容易检查。你的浏览器预装了获取自证书颁发机构(CA)的可信任 SSL 证书列表,你可以查看,添加和删除。这些证书由一组集中的(理论上,通常在实践中)极其安全、可靠和值得信赖的组织所控制,如赛门铁克、Comodo 和 GoDaddy。如果一个服务器出示的证书来自该列表,那么你知道你可以信任他们。

第二个标准要难得多。服务器很容易说 “是的,我是微软,你信任赛门铁克,赛门铁克信任我,所以都很酷”。有点聪明的客户可能就会去问赛门铁克 “我这里有一个微软,他们说你信任他们,这是真的吗?” 但即使赛门铁克说 “是的,我们认识他们,微软是合法的”,你还是不知道这个自称是微软的服务器到底是微软还是其他糟糕的东西。这就是数字签名的作用。

3.2 数字签名

如前所述,SSL 证书有一个相关的公钥/私钥对。公钥作为证书的一部分进行分发,而私钥则受到非常安全的保护。这对非对称密钥在 SSL 握手中用于交换双方进一步的密钥,以对称地加密和解密数据。客户端使用服务器的公钥对对称密钥进行加密,并安全地发送给服务器,服务器则使用其私钥进行解密。任何人都可以使用公钥加密,但只有服务器可以使用私钥解密。

数字签名的情况正好相反。证书可以由另一个当局 “签署”,这样,该当局就可以有效地记录在案,说 “我们已经核实,该证书的控制人也控制着证书上所列的财产(域)”。在这种情况下,权威机构使用他们的私钥(广义上)对证书的内容进行加密,而这个加密文本作为数字签名附在证书上。任何人都可以用权威机构的公钥对这个签名进行解密,并验证其结果是否达到预期的解密值。但只有权威机构才能使用私钥对内容进行加密,所以只有权威机构才能真正在第一时间创建一个有效的签名。

所以,如果有一个服务器来宣称自己有一个由赛门铁克(或其他 CA)签署的 Microsoft.com 的证书,你的浏览器不必相信它。如果它是合法的,赛门铁克会用他们的(超机密)私钥来生成服务器 SSL 证书的数字签名,你的浏览器可以使用他们的(超公开)公钥来检查这个签名是否有效。赛门铁克会採取步骤,确保他们所签署的机构真的是 Microsoft.com 的拥有者,因此,鉴于你的客户信任赛门铁克,它可以肯定它真的是 Microsoft Inc.

3.3 自签名

请注意,所有的根 CA 证书都是 “自签名 “的,这意味着数字签名是用证书自己的私钥生成的。根 CA 的证书并没有什么本质上的特别之处–如果你想的话,你可以生成自己的自签证书,并使用这个证书来签署其他证书。但由于你的随机证书并没有作为 CA 预装到任何地方的浏览器中,因此没有一个浏览器会信任你签署自己的或其他证书。你实际上是在说:”呃,是的,我是微软,这里有我自己签发和签名的官方身份证书。”所有正常运行的浏览器都会针对你的可疑证书抛出一个非常可怕的错误信息。

这给所有的浏览器和操作系统发布商带来了巨大的负担,他们只信任干净的根 CA,因为他们的用户最终会信任这些组织来审核网站并保证证书的安全。这不是一件容易的事

3.4 你在相信什么?

有趣的是,你的客户端在技术上并不是要验证是否应该相信发送证书的一方,而是要验证是否应该相信证书中包含的公钥。SSL 证书是完全开放和公开的,所以任何攻击者都可以抢夺微软的证书,拦截客户端对 Microsoft.com 的请求,并向其出示合法证书。客户端会接受这一点,并愉快地开始握手。然而,当客户端加密将用于实际数据加密的密钥时,它将使用这个真实证书中的微软的真实公钥来加密。由于攻击者没有微软的私钥来解密,所以他们现在被卡住了。即使完成了握手,他们仍然无法解密密钥,因此也无法解密客户端发送给他们的任何数据。只要攻击者不控制可信证书的私钥,秩序就会得到维护。如果客户机以某种方式被欺骗,相信一个私钥被攻击者控制的证书和公钥,麻烦就开始了。

4. 有趣的事实

4.1 咖啡店可以通过他们的网络监控我的 HTTPS 流量吗?

不行。

公钥加密的魔力意味着,攻击者可以观察你的客户端和服务器之间交换的每一个字节的数据,并且仍然不知道你们之间在说什么,除了大概有多少数据在交换。然而,在不安全的 wifi 网络上,你的正常 HTTP 流量仍然是非常脆弱的,一个脆弱的网站可以成为任何数量的变通方法的受害者,这些变通方法以某种方式欺骗你发送 HTTPS 流量,要么通过普通 HTTP,要么就是完全发送到错误的地方。例如,即使一个登录表单通过 HTTPS 提交用户名/密码组合,如果表单本身是通过 HTTP 不安全地加载,那么攻击者可以在表单到达你的机器的途中拦截表单的 HTML,并修改它来发送登录细节到他们自己的端点。

4.2 我的公司可以通过他们的网络监控我的 HTTPS 流量吗?

如果你使用的也是你公司控制的机器,那么是的。请记住,在每一个信任链的根部都有一个隐含的受信任的 CA,而这些权威机构的列表就存储在你的浏览器中。你的公司可以利用他们对你的机器的访问权限,将他们自己的自签证书添加到这个 CA 列表中。然后他们就可以拦截你所有的 HTTPS 请求,出示声称代表相应网站的证书,这些证书由他们的假 CA 签署,因此毫无疑问地被你的浏览器信任。由于你会使用他们的假证书的公钥对你所有的 HTTPS 请求进行加密,他们可以使用相应的私钥对你的请求进行解密和检查(甚至修改),然后将其发送到预定的位置。他们可能不会。但他们可以。

顺便说一句,这也是你使用代理检查和修改 iPhone 应用发出的本来无法访问的 HTTPS 请求的方法。

4.3 那么 Lavabit 和 FBI 之间发生了什么?

Lavabit 是爱德华-斯诺登在 2013 年 NSA 泄密疯狂期间的超级安全电子邮件提供商。正如我们所看到的,任何数量的标准黑客技术都无法让 FBI 看到 Lavabit 和其客户之间的任何数据。没有 Lavabit SSL 证书的私钥,该机构就完蛋了。然而,一位乐于助人的美国法官告诉 Lavabit 的创始人 Ladar Levison,他必须交出这个密钥,实际上给了 FBI 自由窥探流量的权力。莱维森勇敢地试图拖延时间,交出了 11 页 4 号字体的 2,560 个字符的密钥,但却遭到了命令,要求他以有用的格式交出密钥,否则将面临每天 5,000 美元的罚款,直到他交出为止。

一旦他遵守规定,Lavabit 的 CA GoDaddy 就撤销了证书,(正确地)认为它已被破坏。这将 Lavabit 证书添加到证书撤销列表(CRL)中,这是一个客户不应再信任的证书列表,以提供安全的连接。篡改、自签或其他不可信的证书会导致浏览器显示一个大的红色错误信息,并阻止或直接禁止用户的进一步行动。不幸的是,浏览器将继续信任一个被破坏的证书,直到他们拉出最新的 CRL 更新,这个过程显然在实践中是不完美的

5. 结论

HTTPS 并不是牢不可破的,SSL 协议也必须不断发展,因为针对它的新的攻击被发现并被压制。但它仍然是一种令人印象深刻的强大的传输秘密数据的方式,而不会在乎谁看到你的信息。当然,这里还有许多实施细节没有提到,比如握手信息的确切格式和顺序,简略的握手以获取最近的会话,而不必重新协商密钥和密码套件,以及在每个阶段有许多不同的加密选项。要记住的关键是,虽然 HTTPS 能保证数据在传输过程中的安全,但它绝对不能保护你(作为用户或开发者)免受 XSS 或数据库泄漏或任何其他事情的影响。庆幸有它在背后支持你,但要保持警惕。用威尔-史密斯的不朽名言:”在阴影中行走,在沉默中移动,防范地外暴力。”

如果你喜欢这个,你可能会喜欢我解释 2015 年 SSL 中 FREAK 漏洞细节的文章

原文:How does HTTPS actually work?

译者:evan

众筹开高达