@chinvo #195

好吧，那是我误解了，比如什么样的『安全』是服务商要保证的。

抱歉，单次回复次数太多，被限制 1800 秒回复

@3dwelcome #184 #189

所谓的『签名』是 HTTPS 自有特性，已经完全可以满足安全需要。因此，在 HTTPS 本身的数据签名之外的人工二次『签名』是完全没必要的。所谓『网关问题』请参看 173 楼。

新闻就不评论了，不能绝对排除银行犯二 F12 就给改了的可能


@chinvo #188
持反对意见
> 但是服务本身的安全(包括从客户端到服务端的链路上的安全)是服务提供者的义务. (法律上一般也是这样认为的)
假设从客户端到服务端经过了 C -> C1 中继城市核心交换机 -> S1 中继城市核心交换机 -> S 。在 C/C1/S1 任何一端由于网络提供商（和服务提供商没有任何关系）维护问题导致网络终端继而导致某个 C 或者某些某部分 C 无法访问我的服务，需要服务提供商负责吗？是应该责怪我没有备用线路？那极端情况所有备用线路都坏了(网络提供商问题)导致客户产生了巨额损失是需要我来赔偿吗？

@3dwelcome 好吧

@chinvo #185

如果是客户端的话，个人人为不用管了，因为管不到，参看 169 楼。考虑客户端的话任何方案都是不安全的。

@chinvo #180

HTTPS CDN 的话才有必要二次封包。
内网网关已经完全没必要了。

@chinvo #180

是的，就是这个意思。想看 173 楼。

@0o0O0o0O0o #178

正解

@3dwelcome #177

好的，我承认解密网关存在。我不用。然后呢？参看 173 楼。

HTTP 的签名机制完全没有存在的必要

@nikan999 #175

HTTPS 数据包可以被改了？

@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

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

结论并不能成立。