|
自己实现个类似SSL/TLS玩意儿就行了。很简单的。 这东西js完全可以写，但因为js的数据类型不够严格、瞎自动转换，所以写起来很累、很容易出错；开发、执行效率都太差，比不上传统的c/c++ 另一个，js跑在浏览器里面、临时从网站下载，这就使得它无法完成“网站身份验证”任务——你验证你自己是脱裤子放屁，钓鱼网站只要做个假界面就行了…… https真正提供的东西是： 1、自动的网站身份验证功能，确保用户不被钓鱼网站欺骗 2、基于公钥体系（PKI）实现的会话密钥交换协议，可以抵抗中间人攻击等威胁 3、利用临时协商出来的会话密钥，通过AES等加密算法完成加密通信 这一套基本是标准化流程了，懂密码学的手搓一个不难——更懒惰的，直接下载个openssl库然后用它建立基于SSL的安全信道即可。 说白了，ActiveX控件就相当于一个桌面应用，“寄生”在浏览器执行而已；当然，浏览器默认要求它有个签名，浏览器会使用信任的CA证书对其认证，这就可以避免假冒的ActiveX控件加载。 不过，如果你不懂，照某些三脚猫教程关闭了ActiveX控件签名认证功能，那就完蛋了——幸好这种人太少，攻击者搞这种假冒ActiveX控件得不到收益…… 如果连ActiveX都没得用、也没有SSL，那就得从头手撸了。这也很简单： 1、应用要从真实的银行网站下载；如果担心客户受骗，可以强制要求开启U盾。 2、应用和U盾通讯，把银行签名的交易请求提交给U盾（如登录、转账等）。 3、U盾验证通过、并经用户同意后，使用内置的用户私钥签名（银行发来的挑战码）。 4、银行发现U盾应答通过，挑战-应答流程正确执行完毕，则交易成立（交易泛指登录、查账、转账等）。 要害业务逻辑都在U盾执行，而且自始至终并不需要输入密码（此时不需要输密码的设计反而是更安全的）；应用就是假冒的也没用。 较新的U盾甚至自带屏幕和按钮，可以让用户直接看到每笔交易概要、并在U盾上通过按钮完成交易确认动作，这就彻底杜绝了“OS本身不可靠（比如在病毒泛滥的网吧付款）”可能带来的任何威胁。 总之，安全通信是一个相对专业的领域，很多问题需要针对具体应用场景/需求定制方案。 对普通人来说，这可能很难理解；但对密码学专家来说是小菜一碟。日常工作而已。 https其实是http over ssl而ssl又基于tls协议——这是一整套的、从os开始建立的安全系统。 所以，千万别用盗版/来路不明的os啦。不然只要人家往你的“信任证书列表”里面加点料，一整套体系就完蛋了——https也保护不了你！ |
|
|
