@3dwelcome #171

> linux 系统 root 提权很难很难； windows 系统上，你 chrome 保存的...

像你说的，木马对吧？你总要把 Key 读出来吧？我读内存行吗？进程 HOOK 可以吗？

@chinvo #170

是的。我纠正一下我的说法：服务层只需要拿到解析后的验证参数，如 nginx 的话： http_s|c_xx 等 Header 头。至于客户端证书的验证交由 Nginx 来处理至于路径我毫不关心，我只要知道我必须得要。

补充：像这种场景个人人为通常都是独立 API 域名吧？或者是 OpenAPI 网关，由网关（即是 WS 又是鉴权应用）来决定这个路径给不给验证信息。内网，到此步骤已经『完成并结束了对『安全』』的『需求』，再往后已经是各种服务协作，已经『没必要』再顾及 HTTPS 自身安全了。

@no1xsyzy #161

@chinvo #162

已经脱离『纯技术』了。真的要考虑客户端的话，我个人人为没有『任何』方案可以保证安全，我甚至认为无论你有什么方案客户端环境都是『绝对不安全』的

@3dwelcome #165

> 木马一般都是定向功能，比如能盗取 HTTPS 数据流并解密，又不一定能成功偷到商户 KEY 。

木马一般都是定向功能，比如能成功偷到商户 KEY，又不一定能盗取 HTTPS 数据流并解密

> 前几天有个类似安全贴子，讨论数据库被.......

对啊？别说加密了，还搞开发干啥。管你什么 KEY 你数据库里总有吧？

@jim9606 #163

明白

@chinvo #160

是的。但是『客户端证书』非必要场景，非极端条件其实不用考虑。
而且『应用』只需要拿到客户端 PEM 后自行处理不同路径验证，不必在 webserver 层处理。

@chinvo #157

正解

@3dwelcome #156

> 你可以确保自己的服务器万无一失，可客户服务器凭什么去保证不会被挂什么木马？
客户端环境都木马了，你的签名 KEY 还有何安全可谈？

@3dwelcome #152

补充，请从『纯技术角度』来『『证明』』 HTTPS 不安全

@3dwelcome #152

上面无数次提到密钥本身安全和泄露规避风险和方法。

结论并不能成立。

@3dwelcome #150

论点到底是什么。

加速卡是吧？好，我当他 100%绝对的『不』安全我不用行不行。

请从『纯技术』角度证明：HTTPS 不行，必须要有签名模式辅助。

@chizuo #147

你说的签名是额外使用非对称加密算法生成的『签名』

我指的签名，就是我给出的代码的『所谓的签名』，早期的支付宝、微信 v2 版本支付接口、SNS 社交平台等等等的早期签名都是这种。

然而，即便是你说的非对称加密算法的签名，在 HTTPS 模式下为什么有存在的必要？

@3dwelcome #144

你对 HTTPS 所有可能或不可能碰到的问题，在『签名模式』下都有对应的风险。TLS 私钥泄露？那签名 KEY 也能泄露。算法破解？那 KEY 也能被破解。管理不善？那 KEY 也能管理不善。


chrome 漏洞？ 签名模式的客户端就没漏洞？
tls 算法漏洞？签名模式的 hash 算法没漏洞？
服务器环境不安全？签名模式服务器环境就安全？

难道就不做开发了吗？

@3dwelcome #144

？？？ 加速只是『计算』 TLS 通道仍然是『绝对安全』的。到终端业务机器保证全链路 TLS 就依然安全。

不要说如何保证链路，就像不能保证用户不会泄露 KEY 一样。这不是技术方案问题了。

@no1xsyzy #142

仍然不明。

可以关闭验证，他就可以公开泄露签名密钥。

这就已经不再是技术方案的问题了吧？

安排好家用就行

@kejialiu #138

Paypal 、Stripe 没有客户端证书。因何安全？

**纯技术角度**

@BinaryLeeward #139

同理，假设客户直接在 app 端不做任何反编译防护措施，直接把密钥明文贴在配置文件中，签名机制就没有一丝一毫的作用？

@FutureApple

https://www.cnblogs.com/zhangmingda/p/12672588.html