哪些攻击可能与我的安全层概念有关？

Question

尽管有使用SSL/https /等的所有建议.我决定在我的应用程序的http顶部实现我自己的安全层...这个概念的工作原理如下:

User registers -> a new RSA Keypair is generated
the Private Key gets encrypted with AES using the users login Password
(which the server doesnt know - it has only the sha256 for authentication...)

Server stores the hash of the users password
 and the Encrypted Private Key and Public Key

User logs in -> authenticates with nickname+password hash
(normal nick/password -> IP-bound sessionid authentication)
Server replies: sessionid, the Encrypted RSA Private Key
    and an Encrypted randomly generated Session Communication Password

Client decrypts the RSA Private Key with the users Password
Client decrypts the Session Communication Password with the RSA Private Key

---> From this point on the whole traffic gets AES-encrypted
     using that Session Password

我发现该链中没有漏洞 - 私钥和登录密码都没有以明文形式发送到服务器(我不使用cookie,排除HTTP Cookie标头包含敏感信息的可能性)......但是我有偏见,所以我问 - 我的安全实施是否提供了足够的......安全性？

Answer 1

为什么每个人都必须提出他们的安全传输层？是什么让你认为你有比SSL或TLS更好的东西？我根本不理解重新发明轮子的动机,这在加密方面是一件特别危险的事情.HTTPS是一个复杂的野兽,它实际上做了很多工作.

请记住,HTTPS还涉及身份验证(例如:能够知道您实际上正在与您认为正在与之交谈的人进行交谈),这就是为什么存在PKI并且浏览器随Root CA一起提供的原因.这很难(如果不是不可能的话)重新发明并且容易出现安全漏洞.为了回答你的问题,你是如何防御MITM攻击的？

TLDR:不要这样做.SSL/TLS工作正常.

/endrant.

Answer 2

无论如何我不是加密或安全专家,但我确实看到了一个严重的缺陷:

客户端无法知道它正在运行正确的加密代码.使用SSL/TLS,您的浏览器供应商和服务器软件供应商都已达成一致的标准.您不需要告诉浏览器SSL是如何工作的,它是内置的,您可以相信它可以正常且安全地工作.但是,在您的情况下,浏览器只通过从您的服务器接收纯文本JavaScript来了解正确的协议.

这意味着您永远不能相信客户端实际上正在运行正确的加密代码.任何中间人都可以提供与您通常服务的脚本相同的JavaScript,除了它将所有解密的消息发送到攻击者的服务器.并且客户无法防范这种情况.

这是最大的缺陷,我怀疑这对你的解决方案来说是一个致命的缺陷.我没有看到解决这个问题的方法.只要您的系统依赖于向客户端提供加密代码,您将始终容易受到中间人攻击.当然,除非您通过SSL提供该代码:)