- 饭团 置顶2019-09-13回答老师问题
1)不能 因为虽然https是安全的，但前提是你的访问对象是安全的，归根到底你要保证真实是真实的，安全的！是你想访问对象！因为证书也是可以自己生成的！
2)为了性能，非对称加密算法性能不好！对称算法性能高！作者回复: 1）结论正确，但是解释不太妥当。HTTPS 可以达到数据在网络传输过程中的可靠性，但是支付过程是一个复杂和综合性的行为，涉及到的过程和角色远不只有 HTTPS 连接和它的客户端、服务端，因此 HTTPS 的安全性结论无法推广到整个支付过程和支付行为的安全性结论。
2）性能是一个非常重要的因素，说得很好，因为非对称性加密的性能要比对称性加密的性能差很多，特别是在被加密数据量比较大的时候，但它的问题在于无法把密钥传递到对端，因此我们才使用了非对称加密的方式来帮助做到这一点。但是，还有其它原因，比如说，对称性密钥是每次会话生成的，会话以外自动失效，这就像武功唯快不破一样，通常很短的时间就更换掉了；如果使用非对称性加密方式来传输实际数据，因为它只在最开始的时候生成一次，而不是每次会话都生成，因此在传输中同一个公钥会被发给多个不同的客户端，因此第三方的中间人可以使用这个公开的公钥解密服务端发给其它客户端的数据，这显然不具备安全性。 9 
2019-09-23对于老师的置顶回复中的下面这句话有一个疑问：「第三方的中间人可以使用这个公开的公钥解密服务端发给其他客户端的数据。」
我的理解是：非对称加密意味着「公钥加密，私钥解密」。
如果使用公开的公钥加密传输数据，第三方中间人仍然需要私钥来解密数据。
为何第三方中间人可以使用这个公钥来解密数据呢？
不确定是不是自己哪一步理解有误。
提前谢谢老师。展开作者回复: 这是一个很好的问题。
有“公钥加密，私钥解密”，但其实也有“私钥加密，公钥解密”。
从消息保密的角度来说，一般我们都是使用公钥加密，私钥解密。这样才能让消息保密，即便被第三方窃取了消息，消息内容也不会泄露。如果是这个用途，那么你说的完全正确。
但是 non-repudiation 则是反过来，使用私钥加密，目的就是让对方，以及可能出现的第三方使用公钥解密，这样大家都能证明消息已经确实被发送了，因为在私钥没有泄露的情况下，这条消息是无法被创建的，这也就使得“否认”（repudiation）变得不可能。 1 3
2019-12-02老师，为什么要设计成有了ABC才能计算出密钥，不要AB行吗？因为只有c是加密的，攻击者拿到c 不就可以计算出密钥了吗？那ab 还有意义吗？谢谢作者回复: 这种方式（传统 RSA 方式）下，C 是通过非对称密钥加密的，因此攻击者拿到加密后的 C，却无法解密。最后的对称密钥的计算，需要解密后的 C。
至于 A 和 B 因子的引入，是为了提高 pre-master 的随机性。 1 1
2019-10-17老师，证书发布机构对证书做摘要生成的指纹和客户端生成的指纹 P1 是一个东西吗？作者回复: 对。对于证书做摘要得到指纹，这个指纹无论是发布方还是客户端得到的，它们必须一致，要不然校验就失败了。
1- 2019-10-17老师，您建议先粗略的读一遍，再重读的时候再学习这些延展资料，还是第一遍的时候就跟着学下来呢？
作者回复: 这个取决于你自己吧 :) 理解内容最重要。
1 
2019-10-10老师我有俩问题：
1、“快速验证”对对话摘要加密使用的秘钥应该是A+B+C生成的会话秘钥吧？
2、有了会话秘钥之后，传输数据时为了判断信息是否被篡改，是不是也要对信息进行摘要然后对称秘钥加密后再把信息、摘要发给对方啊？作者回复: 1. 是会话密钥
2. 这就不会了，因为前面的机制保证了会话密钥仅此两份- 2019-09-23思考题1：
如果这个支付功能网站本身就是为了钓鱼设计的，仍然可能出现安全问题。（后看到老师置顶留言，才知道原来不能把 HTTPS 的安全结论推广到整个支付过程。HTTPS 只是支付过程的一部分。）
思考题2：
是安全与效率的取舍。
如果全部使用对称加密，安全性不可靠，相对容易反推秘钥；如果全部使用非对称加密，内容传输的效率低，在数据量大的时候低很多。
严格确认双方身份后，就可以用低成本高效率的方式来沟通。
（后看到老师留言，使用非对称性加密来传输实际数据，没有一过性，反倒会有安全性问题。）
选修课堂和扩展阅读长知识了，谢谢老师。展开作者回复: 👍
2019-09-181. 不对，因为在建立 TSL 连接的过程中可能会出现中间人攻击。
2. 出于性能和安全性考虑作者回复: 感谢回答。
正确，但不完整，你可以看看别人的回答。- 2019-09-17思考题：
1. 这种想法是不对的，虽然有证书和加密机制做保证，但是黑客们还是可以在请求访问的过程中做文章。在网上找到了个例子：“DNS 劫持”，因为我们在向服务器发送请求的第一步就是去到 DNS，通过域名获取服务器 IP，如果说这一步我们访问的 DNS 服务器是黑客的，这个 DNS 会返回一个错误的 IP，导致我们使用 HTTPS 去和一个错误的 server 去建立所谓的 “安全” 连接。一句话总结就是 HTTPS 安全不等于支付过程安全
2. 回答这个问题之前，先分析一下我们对 TLS/SSL 建立连接的需求和期待：
i) 客户端和服务器都能够解密它们之间传输的数据
ii) 保证这个过程效率尽量高
iii) 保证这个过程尽量安全
如果说双方都使用对称性加密算法，确实建立连接的效率很高，双方也可以加密解密彼此的数据，但是这其实并不安全，首先密钥不能够通过安全的方式告知对方，另外动态更新密钥会使得安全性提升，但是告知方式受阻，这里也做不到。
如果说双方都使用非对称性加密算法，由于密钥只有一把，传递出去的都是公钥，公钥只能加密不能解密，这个安全问题解决了，每次传输数据都用对方给的公钥加密，接收数据都用自己生成的私钥解密，数据加密解密确实也可以完成，但是非对称加密算法本身效率不高，加上客户端服务器来回生成公私钥，传递公钥，传输效率也大打折扣。
如果我们结合这两个算法的优缺点，用非对称算法保证传输安全，用对称算法保证解密数据的高效和正确性，确实是一个较为合理的做法。
感谢老师分享，读完文章受益匪浅，花了比较多的时间看整个 TLS/SSL 这个过程，算是初步理解了，扩展阅读给的第一个链接非常不错，简明易懂，这里请教老师几个文章中提到的概念和自己思考的问题：
1. TLS/SSL 建立链接的第四步和第五步中，客户端和服务器都会发送 Encrypt Handshake Message 用于对方做测试使用，这里说需要解密并和 “原串” 对比，不太清楚的是这里的 “原串” 具体指的是什么？
2. 证书验证部分，客户端需要根据具体算法 “摘要” 得到指纹 P1，然后使用公钥和数字签名解密得到指纹 P2，这里的 “摘要” 指的是什么？
3. 之前用 node 中的套件调用 Restful API 传输 json 文件进行 server 之间或者 server 和 client 的数据交互，这里是不是默认都是 HTTP 协议呢？如果要改成 HTTPS 的话，需要在 server 上做设定吗，还是说直接在调用套件的时候指明就行？因为没有实做过这一块，如果老师有相关链接分享那是极好的。
问题比较多，劳烦老师指点了，谢谢老师展开作者回复: 感谢答复！
第一问，回答举的例子非常好，HTTPS 只能保证连接的可靠，如果连接目标都是错的，那么安全性就无从谈起。
第二问，描述的内容也是正确的，当然，两者都有可以补充的内容。
关于你的三个问题：
1. 无论是客户端还是服务端，对前面所有的传输的数据做一次摘要，再解密对端传过来的消息，二者进行比较。
2. 摘要，其实就是指一种单向的哈希算法，比如 MD5、SHA-1。
3. 这个我不清楚怎样设定。 2 
2019-09-15请问下关于 Repudiation，否认这项；
HTTPS如何保证不被否认的？因为有TLS建立过程，有双方公私钥的参与？作者回复: 好问题！
目前的 TLS 机制无法单独保证 Repudiation（否认），请注意我在文中也写到“第四个问题还需要引入数字签名来解决”。
Repudiation 的解决，必须要靠类似数字签名这样的机制：A 必须收到 B 经过对方私钥加密的消息，这样 A 再使用 B 的公钥解密。而公钥是公开的，也是通过证书等权威形式认证的，所有人都是可以拿到的，公证方一使用 B 的公钥解密，就可以证明这条消息确实来自 B，那么 B 也就无法否认事实了。当然，实际操作的过程中私钥加密的未必是原始信息，也可以是原始信息的散列值，从而保证效率，但效果是一样的，这也是我们看到的数字签名的原理。 2
2019-09-13老师 我想问一下 ，那个快速验证，加密的内容是什么 ，服务器端解密后 是怎么知道内容是正确的呢？作者回复: 加密的内容包含了前面连接过程所有传输的数据，并进行摘要，得到的这个数据串，发送到对端；而对端也拥有所有的数据，经过同样的摘要，那么它应该和对端传过来的摘要相等。这个过程对于客户端和服务端来说都是类似的。
3