@wsy2220 双向 SSL 会导致第三方手机 APP 访问 第三方 HTTPS 业务。比如我举例的 Seafile 云盘。

@talarax7 挂静态页面？挂载 NAS 上么，这不还是还是要开放一个端口提供 WEB 服务，直接就犯规了。

@lookas2001 对维基百科并不了解。

@hlz0812 非 443 的 https 是否会触发 block 目前没有准确的说法，保险起见都默认 ISP 现在或者将来会这样做，所以我这个帖子主要讨论假定 ISP 会检测任意端口的 HTTPS 协议包。


@KyonLi 你这个方法的话对我没啥用，我如果在户外忽然想用手机 4G 网络打开 Seafile APP 看一下某个 PDF 的话就会很麻烦，而且家人用起来也不方便。

@ddsfeng 同上，这个方案也需要客户端额外做动作才可以，无法让客户端随时随地便捷访问。

@chairuosen 同上……

！！！注意：本帖讨论的目标是：客户端（即访问方，可能是手机 APP 等不受控的 Client ）无需额外操作（譬如按需访问端口，譬如修改 HOST，譬如修改 DNS 等）就可以访问家里 NAS 上的 HTTPS 服务 。

方法名最好全小写，单词之间用下划线，比如你例子中的 hello_world，大小写混用的经常会被新手坑。

参数名最好不用简写，一来后期增加参数的时候可能会意外冲突，二来调试代码的时候也方便。

比你这垃圾的正式服务器我这里一堆，比如 2620 v3 。

不请自来。

刚好这些天在弄相关的东西，说一下我目前了解到的东西。

首先，client hello 是否包含 server_name 完全取决于客户端（譬如你的浏览器），以目前唯一支持 ESNI 的浏览器 Firefox 来说，在高级设置中可以手动启用 ESNI （ network.security.esni.enabled ），访问 V2EX 时会自动切换到 ESNI 方式，而访问不支持 ESNI 的站点时还是会发送明文的 server_name 。目前 ESNI 仍然是草案，即便以后真的启用，为了兼容不支持 ESNI 的站点，估计也仍然会保持这种方式，毕竟不是所有站点都会支持 ESNI 。

然后，我部署了 https://github.com/dlundquist/sniproxy 这个 SNI 代理，在源码 https://github.com/dlundquist/sniproxy/blob/master/src/tls.c 第 220 行左右可以看到，SNI 代理的工作方式是需要从 tls 握手的 client hello 中提取 server_name 来作为目标判定。

如果以后 ESNI 正式启用，那么类似的 SNI 代理需要稍作修改，从 client hello 中拿到客户端发送来的公钥，然后配合自己保存的私钥解出真正的 host 来作为目标判定，这样的话就要求除了 web server 外，sniproxy 也需要访问同样的私钥。

@brMu 握手，我目前也是隧道回家：）

@youngs 你前端用 CryptoJS 加密的时候，自己额外存一下本次加密时产生的 iv，回头用 java 解密的时候传进去就行了，这样最简单。

如果，你现在想解密之前已经加密出来的密文，那么就稍微麻烦一些：

首先，加密出来的密文是 base64 的，你 base64_decode 之后会发现开头是 “Salted__”这样的，然后紧跟着的 8 个字节就是 salt 了，然后根据我 4 楼的伪代码，Passphrase （即 key ） 和 Salt 你都有了，可以自己算出 iv 。

这个部分你自己实现即可，18 点过了，我下班回家了…… 2333

websocket 的 group 广播消息一般都是这种 foreach 方式。

实际场景里面一般有这几类情况：
1 、显示分拆成聊天组，也就是多个 group，这样每个 group 里面的人不会太多，常见于各类聊天工具的“群”模式。

2 、隐藏式拆分组，比如各种直播平台的弹幕，假定 1w 人同时看一个直播，当有一个人发弹幕的时候，你以为是其他 9999 个人都能收到？不是的…… 实际上这 1w 人会被拆分成 N 个 group，只有那种 vip 用户的加粗弹幕，以及系统广播才是所有人能收到的，这种是先 foreach group，然后继续 foreach clientid 。

你很难看到哪个聊天软件支持万人级别同时聊天，一来负载太大，二来也没有意义（试想一个上万人的群，那个刷屏速度谁看的过来？）

完整的加密、解密，以及显示本次加密的 iv，在我这里测试是通过的。祝你好运：）

// Encrypt
var ct = CryptoJS.AES.encrypt('my message', 'secret key 123');

var saltHex = ct.salt.toString(); // random salt
var ctHex = ct.ciphertext.toString(); // actual ciphertext
var ivHex = ct.iv.toString(); // generated IV

console.log(saltHex);
console.log(ctHex);
console.log(ivHex);

// Decrypt
var bytes = CryptoJS.AES.decrypt(ct.toString(), 'secret key 123', { iv: ct.iv, mode: CryptoJS.mode.CBC });
var originalText = bytes.toString(CryptoJS.enc.Utf8);

console.log(originalText);

@youngs

好了，话题终结了。

看了下 CryptoJs 源码，和我在本帖 4 楼回复的猜想一样，如果你的 key 是个字符串，那么 CryptoJs 底层会用和 Openssl 兼容的函数来生成 iv：根据你的 key 和一个随机的 salt 经过若干次 md5 后生成的，每次 encrypt 的 iv 都不一样，具体方式见我 4 楼的伪代码。

那么，怎么取到 CryptoJS 每次调用 AES.encrypt 时的 iv 呢？很简单……

// Encrypt
var ct = CryptoJS.AES.encrypt('my message', 'secret key 123');

var saltHex = ct.salt.toString(); // random salt
var ctHex = ct.ciphertext.toString(); // actual ciphertext
var ivHex = ct.iv.toString(); // generated IV

console.log(saltHex);
console.log(ctHex);
console.log(ivHex);


你可以试试用打印出来的 iv 到 PHP 或者 Java 里面去解解看。

@youngs

有个关键问题是：你的密文是用 PHP 加密的吗？

我刚才测试了 PHP 下加密的时候 iv 参数不能为空，即 mcrypt_generic_init() 函数第 3 个参数不能为空，一定要设置的，而根据官网文档的说法是建议设置为全 0 值（长度根据 mcrypt_enc_get_iv_size 来设置）。

所以现在问题的关键是你的密文是怎么加密的，openssl ？还是其他语言？

@brMu 昨天部署好 sniproxy 之后仔细想了想，其实现阶段来说这样做意义并不大。

首先，假设按照预期在 NAS 上部署好 sniproxy+esni，并且实现我说的丢弃包含 server_name 的 tls 包，那么我想从外部访问这个 https，仍然需要浏览器支持，目前来说只有 Firefox 经过配置之后可以实现。

也就是说需要请求方支持（修改一些高级设置）才可以正常浏览，如果是这样的话还不如用传统的 VPN 回家或者 FRP 方案，毕竟我们选择 https 协议的意义就在于：“随时随地方便且安全的访问位于家里 NAS 上的 https 服务”，但是现在并不方便，门槛略高。

所以，只能等到主流浏览器在无需用户干预的情况下默认支持 tlsv1.3 & esni 时，这个方式才有意义。

@GTim

似乎不是的，参见： https://blog.lancitou.net/how-to-generate-key-and-iv-in-openssl-aes/

OPENSSL AES 算法中的 IV 是这样来的：

```
hash1_128 = MD5(Passphrase + Salt)
hash2_128 = MD5(hash1_128 + Passphrase + Salt)
hash3_128 = MD5(hash2_128 + Passphrase + Salt)
Key = hash1_128 + hash2_128
IV = hash3_128
```

另外，@youngs 不知道你用的是 PHP 什么版本，用的哪个函数在解 AES，最好有代码或者伪代码……

@brMu ESNI 了解一下，抓包实测 V2EX 已经启用 ESNI 了，无法在 Client Hello 里面看到 server_name 。

当然了，现在的关键问题是服务器虽然支持 ESNI，但是客户端浏览器默认仍然采用 SNI 直接发送明文 server_name 的话，还是会悲剧，譬如用 Chrome 访问 V2EX，或者 Firefox 不强制开启 ESNI 的情况下。

不过，这个解决起来并不难了，题主提到的 sniproxy 可以自己修改一下，强制检测 tls 版本必须要求 v1.3，并且 Client Hello 不能包含 server_name 即可。

过些天我有空的时候搞一下，有结果后我回再来回这个帖子并且 Share 解决方案。

重在参与……

已使用半年左右，体验很好：

1 、公司和家里，PC 、移动设备等同步，目前用官方服务器，今天正在 NAS 上编译 nodejs，准备自建了。
2 、移动设备（仅说 iOS，没有安卓设备）输入体验不错。
3 、Chrome 浏览器插件自动填写体验不错，虽然插件上说该功能是 Beta 阶段，但是目前没有发现 Bug 。

可以改进的地方：（也许哪天我闲的蛋疼就自己来，毕竟开源）
1 、不同域名下相同密码的冲突检测。
2 、可定制的密码更换提醒功能，针对特别重要的站点，可以自己设定间隔多少天提醒更换一次密码。
3 、同一个站点存在多个帐号时，可以手动设定某个帐号为常用帐号自动填写。

总的来说挺满意，就是当初从 Chrome 导出并且整理我那几千个密码进来的时候太累了……

@sternelee 不用研究，我这个站就是一个反向代理，真要研究你可以参考我的另外一个站 https://www.sssis.org