- 2019-08-24保密性：靠混合加密解决，非对称加密实现对称加密秘钥传递，对称加密实现内容加密。
完整性：靠摘要算法解决。
身份认证：靠数字证书解决，数字证书因为CA机构的信任变成一个完整信任链条，从而实现通过数字证书证明了对方真实身份，但注意身份真实也可能是挂羊头卖狗肉，是一个坏人，所以，有了CRL、OCSP，还有终止信任。
不可否认：靠数字签名解决，内容摘要算法得到摘要，私钥加密摘要，对方使用对应公钥解密，得到摘要，再和自己得到的服务器提供的原文摘要对比，一致说明这个内容就是原服务器提供的，由证书说明了服务器的身份。
关于证书验证：
服务器返回的是证书链（不包括根证书，根证书预置在浏览器中），然后浏览器就可以使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签，然后拿一级证书的公钥解密一级证书拿到二级证书的公钥和摘要验签，再然后拿二级证书的公钥解密二级证书得到服务器的公钥和摘要验签，验证过程就结束了。展开作者回复: 说的非常好。
14 
2019-07-24问题1. 非加密算法需要公开公钥从而让客户端能解密。如果用对称加密，加密秘钥公开，就达不到加密效果了
问题2. 客户端发现当前网站的证书是二级CA，在可信任签发机构中找不到，就会去拿二级CA的数字证书的签发机构去做检查，发现它是一级CA，也不在可信任签发机构中，再找一级CA的数字证书的签发机构，发现是受信任的ROOT CA，至此完成验证。如果到最后一层CA都不受信任，就会警告用户作者回复: √
1 8
2019-07-24看完老师的文章有点迷惑，主要是没搞清完整的流程，又去找资料看了一下，说下自己的理解，老师看看对不。
数字签名和数字证书只用于TSL/SSL的握手阶段，主要是保证服务器的公钥能够正确地传给浏览器（不被中间人伪装发送假的公钥）
具体流程大概是：
1、服务器去CA机构申请证书，证书中包含了要发给客户端的公钥、签发者、到期时间等等信息。如果这样简单地把证书发给浏览器，中间人可以轻松地修改成自己的公钥，之后的通信就是不安全的了。于是需要一定的加密手段，这里的做法就是使用数字签名：将证书的信息利用摘要算法计算出摘要之后，用CA的秘钥进行加密，生成数字签名。
2、服务器将数字证书和数字签名一起发给浏览器，因为有数字签名，所以数字证书无法被中间人做修改（修改之后生成的数字签名无法被CA公钥解密），浏览器拿到数字证书之后，去本地的信任机构中查询到对应的机构，利用其公钥解密数字签名，验证证书是否有被修改过。这一步就保证了浏览器获取到的公钥一定是正确的。
3、公钥正确地传给浏览器之后，接着就是协商对称加密的密钥，然后通信等等..
参考：
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
https://www.zhihu.com/question/52493697展开作者回复: 态度很认真，值得表扬。
有一点小错误，数字签名的防窜改不是因为“修改之后生成的数字签名无法被CA公钥解密”，而是修改后的摘要变动了，与签名里解密出的原始摘要不匹配，所以能够发现原文被窜改。
另外，你说的这些是目前流行的PKI体系，但公钥私钥本身并不一定要用证书，它们本身属于密码学。 1 7
2019-07-24重放和篡改的问题没有提，黑客是解不开秘文，但是可以重复发送，需要时间戳和随机数再合起来做一个不可逆的签名，服务端收到重复的就丢弃作者回复: 感谢补充，这个就是nonce了。
5
2019-07-24对于第二个问题证书链验证的过程，有些不理解的地方，请老师指教，您在文章说“操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验，直到找到根证书”，服务器只返回了他的证书（假如返回的是二级证书），浏览器内置的是根证书（根公钥）使用根公钥只能解密根机构签名的证书，无法解密二级证书，使用一级证书（公钥）才能解密二级证。那么浏览器是怎么自下向上层层解析到根证书？我的理解的是服务器返回的是证书链，然后浏览器就可以使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签，然后拿一级证书的公钥解密一级证书拿到二级证书的公钥和摘要验签，再然后拿二级证书的公钥解密二级证书得到服务器的公钥和摘要验签，验证过程就结束了。谢谢！作者回复: 你理解的很对，服务器会在握手的时候返回整个证书链，但通常为了节约数据量，不会包含最终的根证书，因为根证书通常已经在浏览器或者操作系统里内置了。
2 3
2019-08-17老师，在nginx中一般都会配置由ca机构签发的证书（ssl_certificate）和私钥（ssl_certificate_key）；
问题一：那个证书是由ca机构的私钥进行加密过的，然后在客户端访问的时候，通过浏览器中内置的ca的公钥进行解密，这样理解对吗？
问题二：nginx中配置的私钥(ssl_certificate_key)又是什么用途呢？作者回复:
1.基本正确，浏览器用的实际上是证书里的公钥，不是裸公钥。
2.Nginx中配置的私钥就是用来证明服务器身份的私钥，也就是服务器证书对应的私钥，用来在tls握手时验证身份。
3.可参考后面两讲，看看证书和私钥是怎么起作用的。 2
2019-07-24到这里完全爆炸了作者回复: 哪里不明白可以随时问。
1 2
2019-11-18老师好，有两个问题：
1. 在有正向代理服务器的时候TLS是如何工作的？
您在代理服务器那个章节提到，代理服务器会更改http header的信息，如果设计的更改报文内容，那么完整性就破坏了。所以，我猜测，又正向代理服务器的情况下，整个通讯被分割成两段，一段是客户端到代理服务器的https通讯，另外一段是代理服务器到服务器的https的通讯过程。不知道是否理解正确？
2. 能否解释一下TLS里面的client certificate (two-way auth)的工作方式
我猜测是在握手协商的过程中，服务器要求客户端发送客户端证书过来，进行身份验证。但具体是怎么协商的，客户端又是怎么保住自己发送的证书安全到达服务器端的，还没搞清楚。
谢谢老师展开作者回复:
1.是的，代理作为中间人，对客户端和服务器分别使用TLS通信。
2.客户端证书的用法在后面有讲，其实并不难，因为证书本身是被ca签名的，可以防窜改，直接发就行。 1
2019-10-30为什么公钥能够建立信任链，用对称加密算法里的对称密钥行不行呢？
所谓建立信任链， 是指发送方相信公钥确实是接收方的。因为有CA的信任链和最后根CA的背书。
用对称密钥行不行呢？
用对称密钥来确认公钥的真实性，就好像是街头对暗号。 A:枯藤老树昏鸭 B:穿条秋裤回家。 这样做确实可以确认“你就是你”，可问题是如何交换密钥呢？ 问题就又绕回到了非对称密钥了。
假设有一个三级的证书体系（Root CA=> 一级 CA=> 二级 CA），你能详细解释一下证书信任链的验证过程吗？
没有具体实战过，我猜测如下：
二级CA交给了浏览器，CA说：“我是某宝，这是我的公钥，这个一级CA给我背书了， 你要相信我！”
浏览器再去确认这个一级CA可不可信，一级CA说：“我是公安局，这是我的公钥，这个根CA给我背书了， 你要相信我！”
浏览器再去确认这个根CA可不可信，根CA说：“我是上帝我说了算，你爱信不信”。浏览器也很无奈啊。。。只能信了。展开作者回复: 学习进度很快啊，回答的也很形象生动。
1
2019-08-19如果画一个完整的流程图就更好了作者回复: 后面两讲会对tls的握手有详细的流程图，请参考。
1
2019-07-27MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），两个摘要算法，能够生成 16 字节和 20 字节长度的数字摘要
为什么实验环境中实际 MD5算法生成的 32字节长度的呢？（英文中一个字母占一个字节）
sha1 算法生成的 是 40个字节长度的？
还有 sha-2 的算法，生成的长度都是扩大了2倍展开作者回复: md5、sha1的摘要是二进制数据的16字节、20字节，不能直接看，所以做了hex编码，也就是一个字节变成了两个字符，所以扩大了两倍。
3 1
2019-07-24老师我有两个疑问：
1. 用自己的私钥对摘要进行加密生成数字签名，这个数字签名需要经过公钥加密后发送给对方吗？
2. 是否在每次发送消息时都要进行生成摘要和生成数字签名这两个过程？作者回复: 1.只要私钥加密后就可以了，不需要公钥参与，私钥加密的结果就是签名。
2.如果每次都要对消息签名就需要做这两步，先摘要再加密，也就是数字签名。
3.但私钥运算很慢，实际上不会这样做，而是在握手的时候签名验签，接下来会讲tls握手，它实现了完善的密钥交换过程。 1- 2019-07-241、因为对称加密时，双方要协商密钥，密钥在传输过程中极易被窃取，而非对称加密方式，双方只要协商公钥就行了，私钥都是自己保存的
作者回复: √
1 
2019-07-24使用非对称加密算法RSA交换对称算法AES的密钥部分有疑问：
1，这个交换动作是谁发起的？
2，需要双方都要确认吗？
3，其中非对称加密算法RSA的私钥保存部分没看懂，网站的私钥保存在服务器端，安全；那么用户的私钥呢？是保存在ca证书颁发机构吗？还是保存在浏览器端？
另外，如果网站用户使用黑客手段修改客户端内存数据，然后提交服务器，这种情况https有招吗？展开作者回复: 1/2可以看接下来的tls握手，如何交换如何确认就要使用一种双方都认可的协议。
3.私钥需要自己保管，方法有很多，比如u盾（特殊的usb设备），或者直接就是一个文本文件，想怎么存就怎么存。
4.https只保证通信链路的安全，在这之外它是无能为力的。 1
2019-07-24对称加密就一个秘钥，CA有你的私钥如果ca被黑了黑客可以随便怎么玩。用公钥的话，CA被黑了，黑客没法拿到私钥。只能伪装用户没法伪装服务器。不晓得理解的对不对。
第二个应该从下往上一级一级严重吧。三级验证不通过就不用验证二级了。作者回复: 1的理解有点小问题，信任链里其实不一定非要有ca，如果只是在一个很小的范围内，没有证书只用公钥也可以建立信任关系。
关键是对称密钥没有私密性，不能实现身份认证。 1
2020-02-07对数字证书使用摘要算法生成摘要，用私钥加密摘要，向浏览器发送数字证书带上加密后的摘要，这样能保证数字证书的完整性对吗作者回复: 不是这样的，数字证书内本身就有ca私钥的签名，它自身就可以保证完整性，否则也不会叫“证书”了。
2020-02-04比如，你用自己的私钥签名一个消息“我是小明”。网站收到后用你的公钥验签，确认身份没问题，于是也用它的私钥签名消息“我是某宝”。你收到后再用它的公钥验一下，也没问题，这样你和网站就都知道对方不是假冒的，后面就可以用混合加密进行安全通信了。
我想问老师的是，后面用混合加密进行通信时还会进行身份验证吗？谢谢老师作者回复: 身份验证之后就可以确保安全了，后面就可以交换会话密钥进行安全通信了。
2020-01-19TLS的身份认证环节:
总原理:【私钥加密，公钥解密】
步骤如下:
①客户端和服务器相互交换公钥，各自的私钥，各自保密。
②客户端为例，客户端私钥加密摘要，发送给服务器，服务器用客户端公钥解密出摘要，用明文重新生成摘要对比刚解密出来的客户端摘要，一致则确认身份！
③使用混合加密进行数据传输！展开作者回复: 缺了使用非对称加密交换会话密钥的步骤。
2020-01-14usage: /25-1?algo=xxx&plain=xxx
algo : sha1
plain : 1234
digest: 7110eda4d09e062aa5e4a390b0a572ac0d2c0220
sha1摘要算法是返回20字节的输出，为啥测试是返回40个字符，相当于40字节吧，这一点没太明白？展开作者回复: 之前好像有同学问过这个问题。
20字节被16进制编码了，一个字节编码成两个字符，所以总共是40个字符。
比如0x71，是一个字节，但显示出来就是‘7’‘1’，变成两个字符。- 2020-01-14老师，有两个问题请教，不是很清楚：
1、私钥加密，加密的实际是原文的摘要，这个原文是明文还是会话密钥加密后的密文？
2、完整性通过会话密钥加密消息和消息摘要保证
这里两次加密，分别是用私钥加密原文摘要（实现身份认证和不可抵赖性），会话秘钥加密原文（明文）和原文摘要（实现完整性），是为了实现以上两种不同的目的，不知我的理解对不对？作者回复:
1.原文就是原始的数据，不管是密文或者明文都可以，原文允许公开就是明文，不公开就用密文，总之就是防止原文被窜改。
2.在hmac里，会话密钥同时加密原文和摘要，就可以保证完整性，因为会话密钥是保密的。
3.完整性的关键是加密用的密钥保密，保证摘要不被窜改。所以在混合加密系统里可以用会话密钥实现完整性。当然私钥天然可以实现完整性。