ssl - HTTPS 欺骗以支持遗留应用程序

Question

我有一个旧版应用程序，它有一个硬编码的 url(我无权访问源代码)，它试图在其中下载文件。网址采用以下形式:

https://pre.hostname.org/index.json

但是托管该站点的组织已删除该主机名并使用新的主机名，因此 url 应采用以下形式:

https://hostname2.org/pre/index.json

我不拥有应用程序源代码或任何一个网站，但我突然想到，如果我在本地网络服务器上设置重定向并使用C:\windows\system32\drivers\etc\hosts 文件。

在我的网络服务器上的 lighttpd conf 文件中:

$HTTP["scheme"] == "https" {
     $HTTP["host"] =~ ".*" {
       url.redirect = ( "^/(.*)$" => "https://hostname2.org/pre$0" )
    }
}

在主机文件中有遗留应用程序的客户端机器上:

0.0.0.0 hostname.org

(0.0.0.0 代表带有重定向指令的我的网络服务器的主机名)

通过此设置，我可以在客户端计算机上访问 Web 浏览器中的旧 url，然后进行重定向。但是，它在遗留应用程序中不起作用，我认为这是由于 SSL 认证主机名不匹配。

例如，如果我使用 Edge 浏览器，我必须解决警告:

The hostname in the website's security certificate differs from the website you are trying to visit.

Error Code:
DLG_FLAGS_SEC_CERT_CN_INVALID

我在客户端计算机、网络服务器等上具有管理员访问权限。我显然信任我的网络服务器，即使它与证书不匹配......

我完全接受这是应该的——这是 https 和 SSL 证书提供的保护的一部分——我想问的是，有没有办法让我的遗留应用程序忽略这种情况？一种在系统范围内绕过此特定主机名/证书的 https 保护的方法，以便它对遗留应用程序用于通过 https 下载文件的任何 API 生效？

Answer 1

is there a way to cause my legacy application to ignore this situation?

由于您只有应用程序的二进制文件，您可能会尝试用您控制的域替换应用程序中的硬编码域名，即二进制补丁。请注意，如果应用程序已签名，那将不起作用，因为它会破坏签名。

您也可以尝试创建自己的 CA，将其作为受信任的文件导入您的系统，然后使用此 CA 为相关域创建您自己的证书。如果应用程序只是执行简单的证书验证而没有任何证书或 CA 的固定并使用系统信任库，那么它应该接受你自己创建的证书，因为它信任你的 CA，因此应该接受重定向。