我正在尝试集成其服务的公司使用此协议：
他们不使用 HTTPS 的借口是，他们认为他们必须为他们支持的每台移动设备上的签名证书付费，而不仅仅是在他们的服务器上。他们还认为 HTTPS 增加了太多的网络开销，无法在移动设备上使用。哦，他们的系统“比 HTTPS 更安全”，因为他们使用更长的 AES 密钥。我有没有提到这是用于信用卡处理的？
我试图让他们相信这完全是疯了。谁能给我指出一个清晰、简明的解释，PHB 可以理解吗？（或者如果我因为摇摆不定而被解雇，我可以带到失业听证会上？）
是的，如果你准确地描述它，这完全被破坏了，到了无用的地步。
最初的 AES 密钥因在应用程序中而受到损害，任何拥有该应用程序的人都可以访问 AES 密钥。如果这是全球性的，那么它就完全搞砸了，如果它对每个应用程序都是独一无二的，那么可能会有一线希望。
SHA-1 是完全可重放的。您提到没有盐，但即使有盐，攻击者也可以将其作为中间人对合法客户端重放，然后有效响应以显示为服务器的客户端。
然后，服务器将以加密形式向攻击者提供公钥，这对攻击者来说并不是特别有用，但它也是公钥......它应该是公开的。将其私有化一无所获。如果客户端曾经被入侵（或者任何客户端，如果 AES 密钥是全局的），那么 AES 密钥会被应用程序泄露，并且攻击者也可以使用公钥。
此外，如果 AES 密钥被泄露，攻击者可以发送他们选择的公钥，因为客户端无法验证 RSA 公钥。
在客户端生成 AES 密钥是一个不错的想法，但到目前为止，没有什么可以阻止攻击者生成自己的 AES 密钥。此外，他们可能会向客户提供他们自己的公钥，这样他们也可以欺骗客户。
为什么要使用 RSA 密钥加密数据？那么临时 AES 密钥有什么意义呢？真的完全没用吗？使用 RSA 加密长数据通常被认为不如使用对称加密安全，因为它需要更多的工作来处理并且可能具有其他安全隐患，规范只是交换对称密钥并将其用于数据交换。
简而言之，这个系统完全没用。
如果他们只是将服务器的公钥嵌入到应用程序中并使用它让客户端生成一个 AES 密钥并交换它以进行会话通信，那么实际上会更有用。它不会验证客户端本身的任何内容，但这可以在会话初始化后通过密码或其他令牌来完成。那时您非常接近于仅使用自签名 HTTPS，但如果由于某种原因（例如无法在客户端上添加受信任的根证书）无法选择 HTTPS，它可以用作自定义实现设备。）
好吧，库中嵌入的AES密钥完全没用，而且似乎没有服务器端的验证。我看到这个方案有很多问题。
你没有提到 AES 是如何实现的（什么模式，如何生成 IV 等），在什么模式/填充 RSA 密钥（如果使用未填充，又名“教科书 RSA”，它更坏）。
你说这用于信用卡处理，虽然我不是 PCI 专家，但我很确定这不会通过 PCI 合规性。