Https加密认证过程

用对称加密可行？

可行，问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道

什么是非对称加密？

有两把密钥，通常一把叫做公钥、一把叫做私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开

用非对称加密可行吗？

浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了，因为只有服务器有相应的私钥能解开这条数据，但是由服务器到浏览器的这条路怎么保障安全？如果服务器用它的的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，这个公钥被谁劫持到的话，他也能用该公钥解密服务器传来的信息了

改良的非对称加密？

用两组公钥私钥，保证双向传输都安全

HTTPS的加密没使用这种方案，为什么？最主要的原因是非对称加密算法非常耗时，特别是加密解密一些较大数据的时候对称加密快很多

非对称加密+对称加密？

1. 某网站拥有用于非对称加密的公钥A、私钥A’。

2. 浏览器像网站服务器请求，服务器把公钥A明文给传输浏览器。

3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。

4. 服务器拿到后用私钥A’解密得到密钥X。

5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。

中间人攻击

1. 某网站拥有用于非对称加密的公钥A、私钥A’。

2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。

3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。

4. 浏览器随机生成一个用于对称加密的密钥X，用公钥B（浏览器不知道公钥被替换了）加密后传给服务器。

5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。

6. 服务器拿到后用私钥A’解密得到密钥X

根本原因是浏览器无法确认自己收到的公钥是不是网站自己的，如何证明浏览器收到的公钥一定是该网站的公钥？

数字证书

网站在使用HTTPS前，需要向“CA机构”申请颁发一份数字证书，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取出公钥即可

如何放防止数字证书被篡改？

我们把证书内容生成一份“签名”，比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名：

数字签名

用对称加密可行？

可行，问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道

什么是非对称加密？

有两把密钥，通常一把叫做公钥、一把叫做私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开

用非对称加密可行吗？

浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了，因为只有服务器有相应的私钥能解开这条数据，但是由服务器到浏览器的这条路怎么保障安全？如果服务器用它的的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，这个公钥被谁劫持到的话，他也能用该公钥解密服务器传来的信息了

改良的非对称加密？

用两组公钥私钥，保证双向传输都安全

HTTPS的加密没使用这种方案，为什么？最主要的原因是非对称加密算法非常耗时，特别是加密解密一些较大数据的时候对称加密快很多

非对称加密+对称加密？

1. 某网站拥有用于非对称加密的公钥A、私钥A’。

2. 浏览器像网站服务器请求，服务器把公钥A明文给传输浏览器。

3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。

4. 服务器拿到后用私钥A’解密得到密钥X。

5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。

中间人攻击

1. 某网站拥有用于非对称加密的公钥A、私钥A’。

2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。

3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。

4. 浏览器随机生成一个用于对称加密的密钥X，用公钥B（浏览器不知道公钥被替换了）加密后传给服务器。

5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。

6. 服务器拿到后用私钥A’解密得到密钥X

根本原因是浏览器无法确认自己收到的公钥是不是网站自己的，如何证明浏览器收到的公钥一定是该网站的公钥？

数字证书

网站在使用HTTPS前，需要向“CA机构”申请颁发一份数字证书，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取出公钥即可

如何放防止数字证书被篡改？

我们把证书内容生成一份“签名”，比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名：

数字签名

 

数字签名的制作过程：

1. CA拥有非对称加密的私钥和公钥。

2. CA对证书明文信息进行hash。

3. 对hash后的值用私钥加密，得到数字签名。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了

浏览器验证过程：

1. 拿到证书，得到明文T，数字签名S。

2. 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。

3. 用证书里说明的hash算法对明文T进行hash得到T’。

4. 比较S’是否等于T’，等于则表明证书可信。

为什么制作数字签名时需要hash一次？

非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。

怎么证明CA机构的公钥是可信的？

浏览器保有CA机构的公钥，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥了

数字签名的制作过程：

1. CA拥有非对称加密的私钥和公钥。

2. CA对证书明文信息进行hash。

3. 对hash后的值用私钥加密，得到数字签名。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了

浏览器验证过程：

1. 拿到证书，得到明文T，数字签名S。

2. 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。

3. 用证书里说明的hash算法对明文T进行hash得到T’。

4. 比较S’是否等于T’，等于则表明证书可信。

为什么制作数字签名时需要hash一次？

非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。

怎么证明CA机构的公钥是可信的？

浏览器保有CA机构的公钥，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥了