两个办法
1. Cloudflare Zerotrust ，虽然是第三方但是不需要 AppCode
2. 环境变量设置密码哈希，用 argon2

我用 karabiner 把 macOS 的键位改成 windows 习惯了
https://www.v2ex.com/i/uWA4PjS2.png

Bird Internet routing daemon
应该是管路由的

恰恰相反，Google Sheet 编辑大文件经常爆内存然后卡死
Office 的功能比 Google Sheet 也多很多

话说这个算是 IaC 了吧

这个和 DNS 无关，就是因为你用境内 DNS 去访问境外网站
阿里又不是没有污染，只要你用境内的 DNS ，不管你有没有加密，都访问不了 Google
想要解决这个问题，去做 DNS 分流。

@chanChristin 写 TLS 是 DoT ，而且老系统似乎不支持。比较传统且通用的办法一直是安装描述文件，想要 DoH 也只能用描述文件。

LAX/SJC ，因为免费用户基本上是 LAX/SJC 节点

「大公司居然造假」
因为整个世界都是草台班子啊

打个 zip qq 发过去就能解决的事情，为什么搞这么复杂
不放心输入安全就加个密码
数据太大就分卷压缩

你可以自己用直连域名，告诉别人用 cf 的域名啊

1. 是每个月只有 30G
2. 他这个是按你创建 EC2 的时候输入的磁盘大小算的，不是按实际大小
3. 这个邮件他每个月都会提醒，不用管他
4. 下次记得发帖子发 markdown 格式的，你这 df 的结果根本没法看

不知道楼主有没有学过量纲分析，AWS EBS 的计费单位不是 $/GB ，而是 $ * (GB * s)^-1 。也就是
Charge on EBS = Unit price * Data size in GB * Seconds
你的存储大小没有达到 85%，但是因为这个月过了 85%，所以他每个月都会发

@raw0xff 我记得 WSS 就是 WebSocket over TLS 啊，还是我记错了……
AD 是输入法打字被吃了，指的是 AEAD

其实我们讲这么多，都是密码学方案和算法的问题。大家都离题万里，其实楼主要的也是一个可以实行的方案，这里楼主出一个吧：
X.509 ECC (secp256r1) 证书 + TLS 1.3 双向认证，密钥直接保存在文件里

下面是对方案的解释：
1. 楼主想要用 ECC Keypair ，那么就选 secp256r1 吧。从代码可维护和减少编码工作量的角度考虑，建议复用现有格式，也就是 X.509 证书。自己用 openssl （或者其他你喜欢的加密库）自建一个离线 CA ，然后给客户端/节点发证书就行。
2. 通信协议方面，个人建议 TLS 1.3 。楼主喜欢 WSS 的话也可以用 WSS ，和 TLS 安全性差不多。TLS 1.3 目前所有的 cipher 都是安全的，只要禁用 TLS 1.1-1.2 即可。如果有必要可以开双向认证。用现有协议而不是。WSS 相比 TLS 1.3 的好处是可以走 CDN 。此外，如果楼主还没有决定序列化方案的话，gRPC 也是很不错的选择。
3. 鉴于你的成本，KMS 就别想啦。用云服务器的话是不可能「安全存储密钥」的——只要云服务商想看就能看。阿里云有卖带 TPM 的云服务器，但是也是贵的离谱。真要做什么的话，你可以在创建服务器的时候勾选「加密磁盘」，至少如果放你云服务器的物理机磁盘被偷了不会导致你的私钥泄露。不过轻量云好像不支持加密磁盘的功能。私钥安全性也不会有什么磨损，不泄漏就行。

@GeekGao 其实楼主的问题只是问个可以实操到加密通信方案，结果被我们话题歪到密码学原理去了。或许这就是论坛有意思的地方吧，让我看到思维碰撞的火花（
此外某小飞机的算法算不上高明，比起 Reality 来说设计的失误还是挺多的，Reality 可以说是「源于 TLS 1.3 ，高于 TLS 1.3 」了

@raw0xff #33 TLS 主要是实现 Forward Security ，也就是假如有一个中间人捕获了你的通信，虽然无法解密但是依然保存通信的内容。万一有一天你的私钥泄漏了，如果没有 FS ，那么中间人就能解密你的所有通信；如果用了 FS ，那么就只能解密未来的通信（如果你没有更换私钥），无法解密过去的通信。

TLS 实现 FS 的方式就是 ECDH ，如果你能使用「正确的方式」进行 ECDH 的话，那么自然不需要使用 TLS——但是鉴于大多数人实现密码学的方式都容易犯错，因此「建议」使用 TLS 。

@GeekGao @hxndg 看来我们遇到了一点自然语言表述不清的缺陷。我说的「随机数」是 TLS 1.3 ClientHello 中的随机数，它是用来参与后期 KDF 的，会明文发送，自然不可能用来恢复私钥。你说的「随机数」是用来生成 ECDHE Key Pair 的随机数，这个自然是需要保密、并且保证抗时序攻击的。
此外，我看了 BLE 的标准，其实和 TLS 是一样的——先用 ECDH 交换密钥，然后用 KDF 生成对称加密密钥，最后用对称加密算法 (RC4/AES) 进行加密通信。所以不可能只依赖 DH/ECDH ，也不可能只依赖对称加密，必需两者结合使用。

@gjquoiai 不一定要用 ECIES 吧，其实说到底还是一套 DH + Symmetric Crypto + AD 的 Hybrid Encryption 方案，TLS 、BLE 、ECH 都是自己实现组合而不是依赖 ECIES ，ECIES 只是一个通用的、被证明没有太大安全漏洞方案吧。

@raw0xff
不是叫你换 x25519 ，只是叫你换一个 ECDH 算法——x25519 只是目前最火的。ECDH 和 TLS 没有关系，ECDH 是算法，TLS 是实现。但是建议你使用 TLS ，因为自己去实现密码学相关的东西很容易出错。现阶段没有必要考虑 PQC 。

@GeekGao
1. 性能问题：说到底还是 trade-off 。ECDHE 主要还是为了 PFS ，个人认为物联网设备建立连接并不是一个非常频繁、需要并发的场景，即使建立连接慢一点其实也无所谓，同时由于 ECDHE 参数在 TCP 连接建立前就算好了所以也不会给服务器造成负担。个人觉得用这个换 PFS 是值得的。
2. TLS 中随机数本来就是明文传输的，至于为什么去看 ECDHE 的原理。「同一个用户对两个不同的消息签名时，采用了相同的随机数」，不可能，至于为什么去看 AEAD 的原理。
3. 「使用 X25519 算法的设备可能与使用其他加密算法的设备不兼容」——首先，如果你的设备和软件都是新的，那么完全可以直接上 X25519 。其次，X25519 只是 TLS 选用 ECDHE/DHE 算法之一，你也可以选择其他的 ECDHE/DHE 算法。遵循标准 TLS 1.3 协议的客户端和服务器，应该支持 TLS 1.3 所规定的大部分算法。最后，我也没有说「一定要用 X25519 」，如果 OP 选择了一个成熟的 TLS 库方案，那么自然说是库支持什么就用什么，只需要排除不安全的 chiper 即可。
4. ECDH 是密钥交换算法，AES 是块加密算法，是不同的领域：ECDH 只能用来协商密钥，而 AES 只能用来对称加密，必需两个结合在一起才能组成完整的加密通信协议。感觉你 #18 写的东西没有逻辑。

我不喜欢大公司的浏览器
ungoogled-chromium 或者 Firefox 更合我胃口