手动将 's' 添加到 'http'

信息安全 tls http
2021-08-30 03:59:31

我做了一个 Wireshark 捕获我登录到一个基于 drupal 的网站。该网站不使用https。http.request.method==POST因此,很明显,只需使用Wireshark中的过滤器,我就能够以纯文本形式捕获我的用户名和密码。

然后,我尝试通过在 url 中手动添加sto来访问相同的网页。http很自然,我的浏览器显示了这一点:

在此处输入图像描述

然后我继续登录,再次进行 Wireshark 捕获。

令我惊讶的是,我没有与http.request.method==POST过滤器相对应的任何捕获。

所以,我的问题:

  1. 当我没有真正使用 https 时,为什么我无法以纯文本形式捕获登录 ID 和密码?

  2. 手动添加有什么s效果http

4个回答

不管你怎么想,你实际上是在使用 HTTPS。这可能是一种过度简化,但这里或多或少是发生了什么:

当您使用http://地址栏中的协议访问该网站时,您实际上是在告诉您的计算机“从该服务器发出对该网页的请求,并将该请求发送到服务器上的 80 端口”。如果服务器配置为允许通过普通 HTTP 访问(显然是这样),服务器将响应并且您的会话(除非重定向)将通过 HTTP 继续。

通过将协议更改为https://,您改为指示您的计算机通过服务器上的端口 443 尝试 SSL/TLS 握手,然后通过该隧道发送 HTTP 请求。显然,这行得通,否则您将无法访问该页面。由于 SSL/TLS 连接成功,这意味着通过该隧道发送的所有后续 HTTP 请求都将受到保护,不会被随意窃听(例如:通过 Wireshark)。

但是现在,你会问,那个讨厌的红色斜线https和锁上的“x”呢?这些指标并不意味着 SSL/TLS 连接不成功,或者您与网站的通信未加密。所有这些负面指标都意味着该网站未由您的浏览器识别的授权机构签署。对于 SOHO 联网设备、业务应用程序或网站上的 Web 界面,管理员选择使用自签名证书而不是从公认的权威机构(例如:VeriSign)购买证书,通常就是这种情况。

这在某些方面类似于在有年龄限制的司法管辖区销售酒类。由于我不了解现实世界法律的所有复杂性,因此为了争论,法律规定向低于特定年龄的人出售酒精是非法的。在这个假设的案例中,法律没有具体说明您是否需要在销售前检查身份证件,或者哪些形式的身份证件在销售时被视为有效的年龄证明。只有当销售的合法性受到质疑时,最终才需要在法庭上提供买方年龄的权威证明。但是,为了安全起见,在每次销售时检查 ID 当然仍然是一个好主意。

在这里,您是伟大的科莫多州一家便利店的店员。您的大多数客户将是 Comodoans 同胞,因此您自然能够轻松识别和验证他们由 Comodo 政府颁发的 ID。

不过,有一天,您从遥远的 VeriSign 州获得了一位客户。你现在做什么?幸运的是,您的商店有一本名为 Trusted Root Certificates 的书,其中包含有关如何验证您所在国家/地区各个州颁发的 ID 的图片和提示。您检查您的书籍,将客户的 ID 与相关照片和笔记进行比较,并判断该 ID 确实是由您的商店信任的权威机构签发的。鉴于此,您现在可以相信 ID 上的信息(特别是说明客户身份和年龄)是准确的,因此可以放心地知道您正在进行合法销售。

另一天,一位顾客从海外进来。他的名字叫 Drupal,来自 DigiNotar 的土地。他说他已经大到可以买酒了,他的 DigiNotarian Government ID 与他的说法一致。但是,您的受信任的根证书书没有任何信息可以帮助您验证他所在国家/地区的 ID。你在这里做什么?

严格来说,根据这个假设国家的法律条文,如果您的客户实际上和他所说的年龄一样大,那么您的销售仍然是合法的。您可以选择假设他说的是真话,如果他确实是,请继续您的生活,而不会因与该行为有关的任何罪行而被定罪。

但是,如果没有您认可的权威的任何文件,您仍然冒着他没有说实话的风险。尽管他和他的身份证可能声称,他很可能不是合适的年龄。在这种情况下,销售仍将完成。该产品仍将仅在您和您的客户之间转移(不会立即提供给任何其他人,除非您的客户选择分发它),但现在的问题是酒精已被提供给法律上不应该拥有它的人 - 并且你可能会为此遇到麻烦。


TL;DR: 只要您的浏览器显示https://为协议,您就可以放心,您的通信中的数据在您的计算机和某些端点之间是安全的。但是,如果该区域周围有任何警告标志https://,则意味着浏览器不相信该端点是它声称的那样。然后由您决定是否信任端点的身份声明,足以通过连接传输敏感数据。从某种意义上说,连接仍然是安全的,因为您和 HTTPS 连接的另一端之间的任何人都无法嗅探数据,但您正在冒险另一端不是它声称的那样。


更新:一些浏览器现在开始对密码套件和 HTTPS 连接的其他属性进行检查,并相应地提供警告。在这些情况下,上述内容仍然适用,但您应该知道,窃听者或中间人破坏该安全性比网站使用更强大的加密协议更容易。

您正在协商 ssl/tls,否则您将收到连接被拒绝(“糟糕!Google Chrome 无法连接到...”)或连接超时错误(“此网页不可用 Google Chrome 无法加载该网页,因为.. . 响应时间过长。”)或最终出现 SSL 协议错误(“SSL 连接错误”)。

您正在协商 ssl/tls 并加密连接,但是服务器证书不受信任(因为它不知道密钥属于服务器),因此无法信任连接,因此 google chrome 将其标记为这样在锁上有一个叉号,在 https:// 上有一个斜线,它会出现一个“此证书不受信任”页面,然后您单击“仍然继续”按钮。

您的浏览器将 https 划掉并将其变为红色,是因为无法验证服务器。您可能正在与攻击者的服务器以及您自己的服务器交谈,因为您没有受信任的证书。

但是,服务器未经过验证并不意味着它不加密连接。所有流量仍然是加密的,只有浏览器不能确定服务器发送给他的“密码”(也就是“公钥”)真的来自你的服务器。当您尝试使用 https 并且浏览器无法设置加密通道时,它只会拒绝连接,从而为您提供 @ewanm89 提到的错误之一。

所以 Wireshark 不知道这个 https 连接上发生了什么。因为它是 443 端口,Wireshark 可以猜测它是加密的 HTTP 流量,但实际上无法判断。

要了解有关 SSL(https 背后的技术)的更多信息,请参阅以下问题:SSL/TLS 如何工作?

正如其他人所说,最可能的解释是服务器的证书没有由 CA 签名(“不可信”)。

但是,还有另一种可能的解释:这可能是由于“混合内容”造成的。如果您的 HTTPS 页面包含来自 HTTP 源的 Javascript(或可能的图像),则浏览器仍会显示该页面,但浏览器将拒绝相信该页面是安全的,并会以某种方式指出问题,例如通过删除地址栏中的 https。这是因为当你使用“混合内容”时会有很多攻击,所以这样的页面真的不应该被视为只使用 HTTPS 的页面(使用 HTTP 资源有效地破坏了 HTTPS 提供的保护)。