@gamexg NB 啊，果然支持了。真是把收费 SSL 往死里赶。

@shiny let's encrypt 也不是万能的。通配符就没办法做到。

如果开发一个 windows 应用程序，需要企业证书签名，let's 是没这个权限。只要离开 web，还是有不少限制。

@manfred4527 "如果我需要发数字签名给网站服务器 那是不是意味着我需要发一个公钥给网站服务器,然后用我自己的私钥加密摘要"

完全正确，这在 SSL 里有专门的协定，叫做客户端证书验证。当服务器需要认证客户端的时候，会告诉客户端，让其发一个证书。比如 FIREFOX，会跳出对话框，让你手动选择一个证书。当你选择完成后，FIREFOX 就会用私钥来对证书签名，发到服务器。服务器通过这个证书，就知道你是谁谁谁了。

当然，一般这种情况是对安全要求比较高的情况。比如 V2EX 录入用户名和密码，就没实现这种功能。通常来说，就是服务器给客户端数字签名，双方协定一个 KEY，建立加密通道后，再开始传输实际网页内容。

让我想起国外网站对于网站 cookie 使用，还要征得用户同意。换成国内，管你三七二十一，用了再说。
隐私这块实在是太弱了。
话说，就算普通的用户数据，我也是加密后存进 kv 数据库，毕竟硬盘在机房，什么都不好说。

GCM 的后缀 SHA384 只负责握手协议的摘要算法，只要握手成功后，所有的实际内容数据传输验证，SHA 都不会参与进去的。

还有你说的 ECDSA，是需要网站签发 ECC 曲线证书的，有多少网站会折腾这个嘛，大部分还不是 RSA。

诚然，TLS1.3 规定了不让用 RSA，是需要淘汰，但这不是没有普及的嘛。TLS1.3 改了太多协议上的东西，自己都咽到了，推广不开。虽然 RSA 慢，可现在有硬件加速卡，而且 TLS1.2 是有办法利用各种 resume ticket 黑科技，能把 RSA 的计算量大大减少。相比之下，TLS1.3 优势就没那么大了，也是很尴尬。

@msg7086 你似乎对 AES_GCM 加密算法有什么误解。本身 GCM 和 CHACHA20_POLY1305 一样，都是属于 AEAD 同时处理数据验证和加密的算法。摘要算法默认都是为空的，和 SHA384 没一点关系。

@manfred4527

是的，终于理解了，理解万岁。

PS：进度条快结束了，攒满后就没办法回贴了。哎，要是 V2EX 的进度条能升级就好了-_-

如果 HTTPS 的文本内容是 RSA 直接加密 /解密的，那么你说公钥一致私钥一致，解密的数据就是一致的。但可惜 HTTPS 不是这样运作的，加密都是对称式加密，RSA 只对 KEY 负责。

举个例子，你客户端生成了一个随机数 250，用 RSA 公钥加密了，发给服务器。然后服务器用 RSA 私钥还原，计算得出 master key，用于数据加密。

你作为第三方偷窥者，是无法用 RSA 公钥，来还原出客户端随机数 250。得不到 250，你就没办法填充 permasterkey，没办法填充 permasterkey，就没办法导出最终的 master key。都是一个萝卜一个坑，中间少了任何一个环节，加密结果就差很多。

@manfred4527 其实你还是没有仔细看回复，随机数这个概念很重要。

虽然公钥密钥大家都一样，但机器不一样，时间不一样，生成的随机数不一样。所以每一次最终参与时间加密的 KEY，是截然不一样的。

如果你没有办法获取别人的 KEY，那你就没办法解密和监视别人传输的数据内容。这样 HTTPS 的数据流就是安全的。

@blackjar HTTPS 里面握手关键的一步叫 CLIENT_KEY_EXCHANGE，就是把双方约定的 preMasterSecret，变成真正加密的 MasterSecret，这步就是需要 RSA 参与计算的。

而 MasterSecret 就是用于加密数据的 key，这段数据非常关键，所以并不能直接在网络上传输，需要服务器和客户端做约定，先用客户端 /服务器随机数，填充 preMasterSecret，然后用 RSA 来加密 /解密，相当于生成最终 KEY 了。

而由于 MasterSecret 非常重要，有些移动客户端为了服务器性能考虑(ssl resume ticket)，把 MasterSecret 缓存在本地磁盘，最终导致了把 HTTPS 安全直接降级到了 HTTP，是需要鄙视的。

你和别人拿到的公钥都是一样的，数字证书的目的，是保护里面关键信息不被第三方篡改，公钥就包含其中。

@GuuJiang "Public-key algorithms such as RSA or ECDSA have exactly one private key for each public key and vice versa."

“一个私钥可以导出多个公钥的", 有具体出处吗？我网上查到的都是一对一关系啊。

私钥顾名思义，就是不能公开，服务器上一般只能存私钥，而且必须加密保存，不能外泄。

至于公钥，都是嵌入到数字证书里的，让 CA 做认证，打个包，起名叫.cer 扩展，放到服务器上，任何客户端用 HTTPS 访问的时候，都可以获取证书和公钥。

所以，数字证书和公钥和签名信息，都是公开给大众访问的。但仅仅靠这点数据，也是没办法黑到别人客户端上的数据的。因为真的数据加密不是用 RSA，而是用 AES 对称式加密。RSA 只是药引，负责生成加密 KEY 而已。

最新报价是有人报价格，才有数据，才能抓到，没人报就自然没数据抓不到了。

人家原理就是这样设计的，不要强求。干脆频繁抓取，自己做缓存算了。

"如果 A B C 三人的公钥相同 是不是可以直接得到互相的摘要值?"
就 HTTPS 而言，数据加密不仅仅公钥密钥，那只是握手验证而已。每次一加密都包含了关键的服务器随机数和客户端随机数，所以 C 要冒充 AB，由于客户端随机数无法伪造，每一次服务器随机数也无法伪造，几乎是不可能的。

所以你最后那句“如果这样不是大家都能解密”，肯定是无法实现的。

公钥密钥是一对一的关系。只要服务器的密钥不泄漏，客户端用公钥加密的数据，天下就只有一台服务器可以解密，这样就起到了避免第三方伪造服务器的功效。

然后数字签名保证了公钥是无法被修改的（ CA 根证书的签发），所以客户端能识别到正确的服务器，同理，如果服务器需要验证客户端，也可以让客户端给服务器发数字签名证书，确保客户端不会被伪造。

@Akiyu 以前会，大家对服务器都不太熟悉，代码肯定会出问题，而服务器又是需要 24 小时运行的，会遇到连环夺命 CALL。

现在大家经验丰富了，框架完备了，这种情况就大大减少了。就如上面说的，如果 leader 不放心下面的人用 C++写逻辑，就直接换 lua，就算出严重问题，也是个别用户掉线，不会影响到整体。

服务器团队挫折多了，总会找到合理的应对方法。所以不用太过担心的。

怎么游戏那么难啊，喵的。

@Akiyu 用什么语言看什么需求了。只有部分游戏需要 C++高性能计算，如果普通的 REST 服务器，比如现在的手机游戏，查一下数据库，返回一个结构体，用什么语言都可以。

就我身边人来说，JAVA 应该是主流吧。用 C++怎么说呢，只要楼主能保证代码 24x7 不挂，也没啥。