SSL 的全部意义在于它可以抵抗中间人攻击的窃听，就像您提出的那样。如果您无法让客户端设备信任您的自签名证书，那么您唯一的选择是：

• 拦截初始 HTTP 请求，并且永远不要让通信升级到 HTTPS（但如果客户端显式访问https://...URL，这将不起作用）
• 假装自己是拥有自签名证书的服务器，并希望发出请求的系统天真地接受自签名证书（这相当于一个用户无视浏览器关于可能发生 MITM 攻击的严厉警告的决策进行中）
• 检查对过去已知的 SSL 攻击（Heartbleed、BEAST 等）的敏感性。请注意，此选项很可能是非法的，因为它可能需要对服务器（您不拥有）进行攻击，而不是对客户端（您可能拥有）进行攻击

如果您有数万亿美元可用，您可能还有其他一些选择：

• 成功入侵全球受信任的证书颁发机构，并使用他们的秘密签名密钥为您自己的密钥对生成伪造的证书
• 购买或发现客户端或服务器使用的 Web 客户端、Web 服务器或（最好）SSL/TLS 库中的零日安全漏洞
• 发现 SSL 使用的一些底层加密原语的严重弱点（例如，完全破坏 AES 可能会很好）
• 在计算机硬件上花费数万亿美元对截获的加密通信进行暴力攻击

如果您对设备有无限的物理访问权限，几乎可以肯定，对设备自己的受信任证书存储的攻击会比对 SSL 的攻击更容易（尽管它也可能远非易事）。

有什么建议？是可行的吗？

您需要拥有设备信任的证书才能拦截流量。如何实现这一点取决于设备上证书验证的正确性和开放性。

• 该设备可能有错误或不存在的证书验证。这通常是
  • 根本没有验证，在这种情况下您可以使用任何证书。
  • 仅验证信任链，但不验证证书内的名称。在这种情况下，您可以使用设备信任的 CA 签署的任何证书。
• 该设备具有适当的证书检查，但允许安装自定义信任锚。在这种情况下，您可以创建自己的证书并将其导入为受信任的。
• 该设备具有适当的证书检查，但已关闭以防止添加新的信任锚。这对您不利，除非您让受信任的 CA 之一为您签署设备可接受的新证书。可能没有 CA 会这样做。

如果这没有帮助，可能还有其他一些错误。查看过去几年的 SSL 问题，看看您是否可以利用这些错误中的任何一个。此外，您可能会尝试使用非 SSL 错误来破解设备并更改软件的行为。

不，HTTPS 的本质是需要证书来解密它。您可以嗅探流量，但它会被加密并且对您无用。

不，这是 SSL 的重点，以防止这种未经授权的窥探。要授权您的代理，您需要告诉设备信任代理证书，并告诉设备客户端信任您的证书或使用设备私钥，听起来您无权访问。想要查询更多的信息：

https://en.wikipedia.org/wiki/Transport_Layer_Security