V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  dzdh  ›  全部回复第 60 页 / 共 78 页
回复总数  1549
1 ... 56  57  58  59  60  61  62  63  64  65 ... 78  
2021-04-14 14:29:47 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@EminemW #207

不不不,两回事。

无论是否使用签名机制( mdX/shX(sortedString+key)),恶意请求都可以发起,只是拦截的成本。
2021-04-14 14:27:51 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@3dwelcome #198

依然没有在点子上。不是『要不要』的问题。而是:

回归本质,在 HTTPS 下是不是必须一定绝对只能真的一定要『 mdX/shaX(sortedString+key )』不可?不这么干的话这个设计方案就一无是处、垃圾、没用、渣渣、愚蠢至极?
2021-04-14 14:25:18 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@wy315700 #200

是的,这是客观存在的问题,且不可避免。

但是回归本质,在 HTTPS 下是不是必须一定绝对只能真的一定要『 md5(sortedString )』不可?
2021-04-14 14:20:19 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@dzdh @kejialiu #197
补充,我指的签名是:md5(sortedString)
2021-04-14 14:19:12 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@kejialiu #197

针对可能原因,Paypal 从 2004 年开始提供对外接口开始到现在,经历过 N 次的整体架构升级迭代都没有出一套新的(出新的并不意味废除旧的)接口规范?事实是出了,而且依然是 Http Authentication+OAuth 形式。如果硬要说 Paypal 的设计有问题,那后起新秀 Stripe 呢? facebook 、twitter 、instagram 等等等等呢?显然这种说法站不住脚。

我并不是要竭力的证明『 HTTPS 就绝对的安全了』而是『在 HTTPS 模式下,没有必要在额外做 hash 摘要签名』的逻辑。

真要说安全大可以硬件加密狗+DNA 验证+虹膜+人脸+物理快递安全设备+面对面认证+指纹授权。一次 HTTP 请求等 10 年,但是这不是『根本没必要』吗?
2021-04-14 14:08:11 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@3dwelcome #203

不同意,你的意思是说:用了签名,客户损失了我就不用赔钱对么?
2021-04-14 03:19:26 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@chinvo #195

好吧,那是我误解了,比如什么样的『安全』是服务商要保证的。
2021-04-14 02:48:07 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
抱歉,单次回复次数太多,被限制 1800 秒回复

@3dwelcome #184 #189

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

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


@chinvo #188
持反对意见
> 但是服务本身的安全(包括从客户端到服务端的链路上的安全)是服务提供者的义务. (法律上一般也是这样认为的)
假设从客户端到服务端经过了 C -> C1 中继城市核心交换机 -> S1 中继城市核心交换机 -> S 。在 C/C1/S1 任何一端由于网络提供商(和服务提供商没有任何关系)维护问题导致网络终端继而导致某个 C 或者某些某部分 C 无法访问我的服务,需要服务提供商负责吗?是应该责怪我没有备用线路?那极端情况所有备用线路都坏了(网络提供商问题)导致客户产生了巨额损失是需要我来赔偿吗?
@3dwelcome 好吧
2021-04-14 00:54:21 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@chinvo #185

如果是客户端的话,个人人为不用管了,因为管不到,参看 169 楼。考虑客户端的话任何方案都是不安全的。
2021-04-14 00:48:12 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@chinvo #180

HTTPS CDN 的话才有必要二次封包。
内网网关已经完全没必要了。
2021-04-14 00:43:56 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@chinvo #180

是的,就是这个意思。想看 173 楼。
2021-04-14 00:43:12 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@0o0O0o0O0o #178

正解
2021-04-14 00:41:55 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@3dwelcome #177

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

HTTP 的签名机制完全没有存在的必要
2021-04-14 00:38:49 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@nikan999 #175

HTTPS 数据包可以被改了?
2021-04-14 00:36:13 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@3dwelcome #171

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

像你说的,木马对吧?你总要把 Key 读出来吧?我读内存行吗?进程 HOOK 可以吗?
2021-04-14 00:34:18 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@chinvo #170

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

补充:像这种场景个人人为通常都是独立 API 域名吧?或者是 OpenAPI 网关,由网关(即是 WS 又是鉴权应用)来决定这个路径给不给验证信息。内网,到此步骤已经『完成并结束了对『安全』』的『需求』,再往后已经是各种服务协作,已经『没必要』再顾及 HTTPS 自身安全了。
2021-04-14 00:27:50 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@no1xsyzy #161

@chinvo #162

已经脱离『纯技术』了。真的要考虑客户端的话,我个人人为没有『任何』方案可以保证安全,我甚至认为无论你有什么方案客户端环境都是『绝对不安全』的
2021-04-14 00:23:45 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@3dwelcome #165

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

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

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

对啊?别说加密了,还搞开发干啥。管你什么 KEY 你数据库里总有吧?
2021-04-14 00:21:19 +08:00
回复了 dzdh 创建的主题 SSL API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?
@jim9606 #163

明白
1 ... 56  57  58  59  60  61  62  63  64  65 ... 78  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2919 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 25ms · UTC 13:42 · PVG 21:42 · LAX 06:42 · JFK 09:42
Developed with CodeLauncher
♥ Do have faith in what you're doing.