kejialiu 最近的时间轴更新
kejialiu

kejialiu

V2EX 第 444432 号会员,加入于 2019-10-02 20:08:25 +08:00
kejialiu 最近回复了
@Newyorkcity 尽量减少不必要的暴露。客户端不能完全信任,浏览器也有正经的和不正经的,正经浏览器也可能装了恶意插件。当然,真出问题的可能性不大,但你要做的事情足够敏感时就不得不防
服务器之间的通信,不会经过浏览器,https 保证了没有中间人(除非 Google 脑抽泄露了私钥或者把私钥共享给了不靠谱的第三方 cdn 之类)
code 是经过客户端转发给 Foobar ,而不是 Google 直接发给 Foobar 的,Foobar 无法直接验证真伪,得自己去找 Google 问一下(通过 https ,可以验明 Google 正身)。

但如果用 SAML 这样的协议,可以不用回 Google 二次验证,因为认证结果(Assertion)是带签名的,签名用的公钥在前期配置过程中就已经同步给 Foobar 了
2021-11-19 08:16:05 +08:00
回复了 shadowfish0 创建的主题 分享发现 Huawei Card 大家觉得怎么样
办了中信联名的,实体卡黑色网纹挺好看的。现在返现比较少了,一笔也就几分钱。满 19 可以去中信那个 app 里抽额外的返现红包,这样每笔还能多返两三毛,刷小额还算实惠。但这卡没有中信积分,刷多少都是 0 积分。银联自己的权益都有,机场停车什么的,无界卡现在有境外消费(包括线上)立返 1%,但你得找到能刷银联的地方
2021-04-14 10:00:09 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@ZeroClover 各种什么私钥泄露问题只要一个 HSM 就可以解决问题,私钥只进不出,所有调用只在 HSM 能完成签名,然后将签名结果给服务器。除非你买的是带后门的 HSM,或者刚好撞上有设计缺陷的 HSM 。

是的,HSM 确实是为了防止私钥泄露而设计的,这是很重要的安全设备。但也不是厂商声称使用 HSM 就万事大吉了。就楼主说的 https 请求里直接传密钥这种情况:
正常 CDN 厂商: https 密文 -> HSM -> http 明文 -> 应用各种 CDN 规则 -> HSM -> https 密文 -> 真正的 https 服务器
二逼 CDN 厂商: https 密文 -> HSM -> http 明文 -> 应用各种 CDN 规则,同时记一条日志 -> HSM -> https 密文 -> 真正的 https 服务器
恶意 CDN 厂商: https 密文 -> HSM -> http 明文 -> 应用各种 CDN 规则,全流量备份下来以后留着用 -> HSM -> https 密文 -> 真正的 https 服务器

先不说厂商是否真有恶意,就是记个日志都有可能不小心把请求里的密钥存下来,然后这个日志谁能看到咱就更不知道了。
2021-04-14 09:44:53 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh Paypal 、Stripe 没有客户端证书。因何安全?

PayPal 等不使用客户端证书(或者准确的说,mutual TLS),也不使用签名(这里明确以下,我说的签名都是指请求端使用非对称密钥里面的私钥做的签名,服务端可以使用对应的公钥验证,只是把请求参数 hash 一下那个不叫数字签名),直接在 https 请求中传递原始密钥,可能有几种原因:
1. 设计 API 的人心比较大
2. 当初设计的时候没想清楚,已经有不少客户在用了,也很难改了
3. 为了降低使用门槛,做出了牺牲

Google 的 Cloud API 提供了多种验证机制,其中的 API key 就是直接通过请求参数传递,但是现在内部已经在绝大多数场景禁止使用了,替代方案是使用服务帐号的私钥进行类似 mutual TLS 的认证。对于外部用户,仍然允许使用 API key (也只是建议在访问公共数据的时候使用),主要也是出于上述 2 和 3 的考虑。

还是那句话,安全是相对的,
绝对安全 > https with mutual TLS >= https without mutual TLS + 请求端私钥签名 > https + 明文密钥 > 绝对不安全
看你自己的应用场景选择合适的。
2021-04-13 22:28:11 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh 纯『技术上』说,『仅仅 HTTPS 不使用签名』其实并无问题?

这样的说法有一定误导性,当今 https 最广泛的应用场景都是不使用客户端证书的,还是需要强调一下
2021-04-13 22:20:47 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh 链路问题可以设置成全链路 tls 吧?如 cloudflare ?阿里云、腾讯云等众多 CDN 厂商的 cdn 也是支持 https 回源的

其实这里还有一个问题是你要把 https 私钥分享给 CDN 厂商,这些大厂就这么可信吗?反正我胆子很小。。
2021-04-13 22:16:06 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh 看了一下你的其它回复,在*有客户端证书*的情况下确实没必要对请求额外签名,这两个原理上是等效的,或者说签名只是客户端证书的屌丝版。
2021-04-13 22:07:28 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh - https 服务端的密钥是怎么管理的,都有谁经手了,不小心泄露了呢?
回:签名模式的密钥怎么管理的?都谁经手了,不小心泄露了呢?

不是这个意思。我作为参与通信的其中一方,无法保证对方的安全管理足够好,我最多只能控制自己这一边。对于使用了 https+签名的情况,从服务端的角度看,某个客户的签名密钥泄露只会影响这个特定的客户;从客户端的角度看,服务端的 https 密钥泄露等同于通信变明文,但别人还是伪造不了我的签名。两种情况都比最好情况好很多。

- 签发 https 证书的 CA 是不是足够可信任呢?
回:本地指定 CA 文件验证

这个指的是 CA 本身被攻击,导致客户密钥泄露,甚至主动参与犯罪 /配合有关部门。当然这种可能性很小,但小不等于没有。

以上讨论的出发点都是 “https 防中间人是有条件的”,与题主的问题没有直接关系。

再多嘴一句,其实 https 网站很多很多时候都不是全链路加密,tls termination 发生在负载均衡,甚至更前面的某个第三方(比如 CDN 或云厂商)的反向代理或者所谓应用防火墙上上,后面都是明文,就算是在内网,走明文也是非常不安全的。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2775 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 59ms · UTC 08:01 · PVG 16:01 · LAX 00:01 · JFK 03:01
Developed with CodeLauncher
♥ Do have faith in what you're doing.