- 2019-07-291、TLS1.3精简了加密算法，通过support_groups、key_share、signature_algorithms这些参数就能判断出密钥交换算法和签名算法，不用在cipher suite中协商了
2、RSA握手时，client key exchage会使用RSA公钥加密pre master后传给服务端，一旦私钥被破解，那么之前的信息都会被破译，根本原因还是在于RSA的这一对公钥私钥并不是临时的。
3、相同点：都在未收到Finished确认消息时就已经向对方发送加密信息了，不同点：TLS1.3将change cipher spec合并到了hello中作者回复: great。
15 
2019-07-312. 结合上一讲的 RSA 握手过程，解释一下为什么 RSA 密钥交换不具有“前向安全”。
答：RSA 握手中，Server Hello 后，客户端拿到服务器的证书，从中提取出服务器的公钥，然后用这个公钥去加密客户端生成的一个随机数（会话密钥）得到密文，然后将其返回给服务器。虽然每次 TLS 握手中的会话密钥都是不一样的，但服务器的私钥却始终不会变。一旦黑客拿到了服务器私钥，并且截获了之前的所有密文，就能拿到每次会话中的对称密钥，从而得到客户端和服务器的所有“历史会话记录”。
说到底，RSA 握手下，服务器私钥是不变的，从而导致不具有“前向安全”。而 ECDHE 的私钥却是动态的，黑客拿到了一个，也只能解密一个密文。展开作者回复: 回答的非常好。
4
2019-12-06请教老师，一直没看懂，“秘钥交换算法参数”究竟是什么？作者回复: 可以参考“答疑篇”，讲ecdhe算法，参数就是算法的公钥、曲线定义。
1
2020-01-19虽然https提供了安全的保证，但是相比http来说在大请求量下性能还是比不过作者回复: 当然，毕竟多了加解密操作，不过比起以前来说已经有很大改善了，为了安全还是值得的。
2020-01-171.1.3在握手时指定了supported groups和key share和signature algorihms，服务器从这些参数中就能判断出密钥交互算法和摘要算法。
2.因为RSA是客户端算出pre master发送到服务端，算出来的master secret是固定的，随着时间的推移，有被黑客算出来的风险。
3.TLS1.2是客户端率先算出master secret，然后发送Application data 而TLS1.3是服务端优先算出master secret，发送Application data。作者回复: 经过了认真的思考，回答的非常好！
2019-11-031. TLS1.3版本在client hello时，已经指定了摘要算法，列出了所支持的椭圆曲线、基点信息。
2. RSA做密钥交换算法时，采用的是证书里面公钥对应的私钥来加密会话密钥，一般私钥被破解，就可以得到之前截获信息的会话密钥，解密消息
3 相同点，都是未收到响应前就把 客户端就把密钥交换算法需要的参数传了过去
不同点，因为服务器尚未选择密钥交换算法，因此密钥交换算法的参数有多个，false start中是客户端先得到椭圆曲线的两个参数，算出master key并发起 change cipher spec，而TLS1.3则是服务器先得到这两个参数，发起change cipher spec, TLS1.3change cipher spec合并到了clienthello中作者回复:
1.tls1.3用扩展协议列出了支持的密钥交换算法和签名算法，所以不需要用密码套件指定。
2.对。
3.对。
2019-08-05希望老师对TLS1.3增加一篇补充，里面涉及的细节大家不是很清楚怎么回事，网上资料少还容易误导。
1、服务器返回的Encrypted Extensions（被加密的扩展信息），加密的扩展信息里面不包含key_share和support_groups,这两个关键参数因为加密之后，无法计算pre-master。问题是加密的扩展信息使用的是哪个密钥对？
2、原文中“在算出主密钥后，服务器立刻发出“Change Cipher Spec”消息，比 TLS1.2 提早进入加密通信，后面的证书等就都是加密的，减少了握手时的明文信息泄露。问题是，除了证书还有那些参数使用加密传输，以及使用的是个密钥对？客户端不先计算pre-master何master-secret，怎么解密证书，进行验证？
3、server certificate verify，使用证书签名握手数据，Finished也是对握手数据进行摘要签名，它用的是master-secret进行的签名吗？展开作者回复:
这些比较细节和底层，如果想要认真研究还是建议去看rfc。
我简单解释一下：
1.tls1.3使用了多个对称密钥，服务器在握手Encrypted Extensions时使用的不是pre-master，而是server_handshake_traffic_secret。
2.可以参考课程里简略流程图，里面列出了那些记录，而具体的扩展字段会因密码套件而变化。
3.Finished消息与tls1.2的一样，是用会话密钥，也就是master secret加密的。
2019-07-31老师，客户端验证服务器证书，为什么不是pre_master计算出来才检验证书？因为服务器已经把证书加密传输的啊？作者回复: 这里有个细节没讲，其实tls1.3有多个加密密钥，在握手的时候，服务器发来的数据会用server_handshake_traffic_secret进行加密，而这个密钥也是由HKDF算出来的。
所以客户端先生成server_handshake_traffic_secret，把服务器握手消息解密，取出证书，验证证书，都没问题，才计算pre-master。
2019-07-30有点纠结ECDHE算法，为什么这个算法可以保证pre-master是唯一的，而服务端又能准确的知道呢作者回复: 这个涉及到算法的内部细节了，比较复杂，比如离散对数、椭圆曲线什么的，可以看看相关的资料。
其实如果不是专门做加解密的话，不需要了解太深入的细节。
2019-07-30这时只交换了两条消息，客户端和服务器就拿到了四个共享信息：Client Random和Server Random、Client Params和Server Params，两边就可以各自用 ECDHE 算出“Pre-Master”，再用 HKDF 生成主密钥“Master Secret”，这样主密钥的参数都是明文的，不是暴露了吗作者回复: 密钥交换算法ECDHE保证了pre-master的安全性，黑客即使截获了Client Params和Server Params，也是无法算出pre-master的。
- 2019-07-30老师，我对比了下tls1. 2和1.3，发现pre master根本就是多余的嘛,双方有个公共K, A=a*K发给服务端，服务端生成B=b*K,双方就可以利用a*b*K=b*a*K的相同密钥进行通信了,1.2是需要客户端把premaster发给服务端，然后双方a*b*K*pre master=b*a*K*pre master的对称密钥进行通信，1.3就是少了pre master，可以这样理解吧
作者回复: 不是的。
还是要有pre-master，注意tls通信使用的master key需要三个随机数生成，其中客户端和服务器的随机数是公开的，而pre-master是加密传输。
tls1.3只是简化了握手过程中的密码套件协商，还是要交换密钥参数算pre-master的。
如果是自己内部的系统，当然可以不用tls那么复杂，直接一个随机数当会话密钥。
可以再看一下tls1.3的握手流程图，里面还有pre-master。 1 
2019-07-29HTTPS再怎么进行优化，相比于之前的HTTP都增加了性能损耗，但是为什么HTTPS的网页会比HTTP的要快。我是通过下面这个网页测试的。
https://www.httpvshttps.com/作者回复: 有很多因素，不一定https比http要快，如果使用了http/2，还有0-rtt，https是和http/1.1性能上差不多的。
单从理论上分析，https多了加解密运算，是会慢一点，但可以用一些手段去优化，优化过的https可能会比未优化的http快。
2019-07-29老师，之前比喻的协议和协议之间嵌套关系就和快递一样。子协议之间的嵌套关系也是这样么?还是说这些子协议只是在某几个请求里有。之后就没了。作者回复: TLS里的子协议你可以理解成模块，是多个不同的部分，互相协作起作用。
- 2019-07-29感觉可能和Client Params和Server Params。有关系，具体不知，请老师指点
作者回复: 不知道你说的是哪个部分，可以补充完善一下问题。
1