colab 的官方 tutorio 都很详细了：

https://colab.research.google.com/

colab 就是个在线 host 的 jupyter

补充，被依赖的服务可能需要恰当的 heath check 方法

https://i.imgur.com/ZfynF92.png

贴错图链接了

https://imgur.com/a/uhEzyr3

B 视角： 第 9 年放钢板第 10 年撞
A 视角： 第 13/3 年放钢板第 6 年撞

有没有想过 svn

@z1645444 都是用你出生时的公民 ID 做随机种子算好的，你只管赚够信用分就能换到。

三层网只防误触不防作死，他要伸指头进去玩照样被电

所以教育>保护

你让他看着蚊子怎么被电成烟的，拿个螺丝刀什么的放一放电噼里啪啦吓唬一下，教育他这东西很危险不能碰他自己是不会敢去玩的。

如果是还不懂事的很小的小孩，那最好的办法是收起来别让他看见。

放弃微不足道的手感问题

买那种办公用的超薄笔记本式键盘，那种玩意怎么敲都没声音

其实对请求签名防范的最核心问题是，你有些时候并不能保证请求内容和 token 来自同一可信源。举个底层逻辑相同但作用和机制完全不同的例子：CSRF token. 为什么明明用户都已经登录了，请求者拥有该用户的一切身份证明，为什么服务器还是不能完全信任这个请求？就因为服务器不能确定用户提供的身份证明能否证明他发起过请求内容。而通过下发 csrf token ，可以保证持有 session 凭证的所有者才能发起合法请求，这就能确认身份证明与请求内容是同一人发出的。


签名同理。

@musi 我通过一个*SRF 漏洞修改你的账号发言权重

@julyclyde 证书就是签名，双向证书==双向签名，机制稍有差异而已


----

我问个问题。

你是腾讯的服务器，现在有人请求修改 onwer A 的资源，你需不需要确认请求者就是 A ，如何保证？

玩过，一句话，除了不好玩其它都挺好的

我最近买的新手机号能收到银行发来的欠款通知短信，银行还打过来问我是不是 XXX （实名）


但我登录不了这个人的微信，就因为有这个好友验证。

@studyrun 链路上的同网段机器不需要经过路由器转发。所以桥接和 NAT 不应该会有区别。

我的 wsl 和宿主机就是桥接的：

https://i.imgur.com/4oIsQJq.png

@bk201
> 人家就是混口饭吃，也是朝不保夕，被开了还没赔偿，你还能对对方有什么要求。

你知道 wuli 外包哥哥有多努力吗，你们非得看到他进监狱才开心吗

> 曾经纠结了一两周的问题，科班程序员因为知识面的原因，一天就搞定了

想多了。

但是， 你纠结一辈子也想不出任何入门方向的问题，科班的确实能受益于知识储备结构起码找到研究方向。

之前有过这样一个帖子：
https://www.v2ex.com/t/845892#r_11550945

我描述了一点科班出身的工程师解决问题的小优势。

最近几天我又见识了几个新问题，你可以尝试思考一下这个问题你有没有思路：





我要开发一款能分析二进制程序漏洞的自动化扫描器，我需要先搜索哪些论文？

@thisismr2 这样的描述还是有点模糊，由于细节你是没法全部表述清楚的，我也不可能很快地完整理解整个系统的结构，所以没法下确定性的判断。

但总之
1. 预设服务器不可能攻破并不十分可靠，无论是逻辑缺陷还是旁站业务还是侧信道都有可能从中提取信息，相比之下终端反而安全很多，甚至在考虑存在 0day 的情况下通常也需要 1-click 才会发生入侵
2. C 和 S 不需要共享任何信息，作为攻击者，他的做法可以分别获取想要的信息再重建关联。再说了，「 C 泄露的 K 是 S 上的某个通信密钥」这个关联已经很强了
3. TLS 只能保证链路安全，无法保证端点上的安全，除非 S 是一个单纯的流量转发器，不解析 TLS 中的内容，那么信道没有在 S 上落地，可以认为在 S 点上安全，但描述并非这么回事。
4. A 和 B 的认证 cookie 没有没有包含在信道建立的步骤中，因此没有作用，除非你的设计是登录后创建的信息与 AEAD 加密的 key 强关联，那么登录状态能同时保证消息完整且可认证，这样是可以确认消息只能由持有登录状态的人发出/解出的。


我就假设一个攻击手段好了
1. 想办法批量获取全网的 C ，记录在线时间和 K ，记录为 R
2. 在 S 上取得一组 AB 通信记录，查询对应时间区间的 R ，用 R 对应的 K 解密

如果你真的非要假设 S 绝对安全 —— 安全是基于可信的。S 安全意味着 S 可信，那么你其实不用避免 S 得知 K ，因为 S 理应拿着 K 也不会做任何事。

如果你不担保这点，就是在假设 S 存在「主动向 C 获取 K 来解密他自己正在中转的消息的行为」的可能性，这是你系统设计外的非预期行为，如果系统设计要考虑容许这个非预期也就意味着还要容许诸如「 S 中转的消息被泄露」之类的其它非预期。所以我对你「假定 S 安全」的前提持怀疑态度。