259.https认证过程

服务区侧原始有：服务器公钥，服务器私钥，合法的CA证书

https本质：
https本质上是加密版本的http，提供传输安全性，通过ssl协议提供安全层，然后通过http进行传输的协议

目的：
保证数据在传输信道中的安全性,即使数据在中途被截获，也无法破解其内容。

HTTPS在传输的过程中会涉及到三个密钥：

服务器端的公钥和私钥，用来进行非对称加密
客户端生成的随机密钥，用来进行对称加密

一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。

1.客户端向服务器发起HTTPS请求，连接到服务器的443端口
2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
3.服务器将自己的公钥发送给客户端。
4.客户端收到服务器端的证书之后，会对证书进行检查，验证其合法性，如果发现发现证书有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为clientkey，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
7.然后服务器将加密后的密文发送给客户端。
8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

https工作过程简述：

1、客户端要求服务器的证书（后面简称“主机证书”），然后客户端根据本地的收信人根证书链验证主机证书的有效性，如果主机证书有效，则假设服务器是正确的；

2、主机证书中包含了一个公钥，然后客户端随机生成一个对称加密的秘钥作为https后续传输数据的秘钥（后面简称“传输秘钥”），然后通过主机证书包含的公钥加密后传给服务器

3、然后服务器和客户端通过传输秘钥对http报文中的内容进行加密后进行传输

交互过程：

1.浏览器发送一个连接请求给安全服务器。
2.服务器会向客户端返回：服务器公钥和CA证书
3. 客户浏览器检查服务器送过来的证书是否是由自己信赖的 CA 中心所签发的。如果是，就继续执行协议；如果不是，客户浏览器就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续。
4.接着客户浏览器比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户浏览器认可这个服务器的合法身份。
5.客户端会随机生成一对客户端的公钥和客户端的私钥，同时也随机生成一个客户端密钥，之后客户端会根据服务器的公钥对客户端的公钥和客户端的密钥进行加密。
6.用户服务器的私钥解密客户端发送来的信息，得到客户端的公钥和客户端会话的密钥。此时服务器会随机生成一个与客户端通信的会话密钥（服务器的的会话密钥）。
7.服务器会用客户端的公钥会加密服务器的会话密钥发送给客户端，客户端会用客户端的私钥解密会得到服务器的会话密钥。
8.客户端会用户端的密钥加密客户端正常请求的数据发送给服务端，同时服务器会用客户端的密钥解密。
9.服务器会用服务器会话密钥加密服务器的回复数据，客户端用服务器的会话密钥解密服务端发送来的数据，就这样重复循环。

简要的图片如下：

 

SSL协议工作的要素：

1、受信任的CA颁发给服务器的主机证书，证书包含以下内容：

颁发机构CA，
CA使用CA的秘钥加密域名的密文，
服务器提供的客户端公钥，
证书签名
2、客户端根证书链，证书链是一系列受信任的CA列表及其提供的公钥

3、主机证书中公钥对应的服务器私钥

SSL是实现原理

1、客户端获取主机证书

2、通过主机证书验证服务器的合法性，即是否是客户端想要连接的服务器：

通过证书中包含的签发机构，从根证书链中取得对应公钥，然后对目标域名进行签名，然后对比签名是否和证书中的一致；

如果CA不在证书链中，或者比对有一项不同则主机不被信任（或许是一个虚假主机，或许是不受信任的证书），如果选择信任则继续进行秘钥的磋商

3、传输秘钥的磋商，客户端随机生成传输秘钥，然后通过对证书中的公钥加密后传给服务器，

4、之后的http内容的加密则使用此密文进行加密。

SSL握手中的几个问题：

1、为什么不使用证书里的秘钥？

因为假如有人在通信的过程中截取了服务器发向客户端的数据，那么由于服务器证书是的开放的，无论是谁都能取到主机证书，然后SSL是个开放的协议，有了证书，解析出来服务器的内容不是难事；
其次对称加密性能比较差
2、传输秘钥能否由服务器生成？

如果由服务器生成秘钥，中间者就在这等着你，在这一步截取到服务器的数据，那么传输秘钥就被泄露了。

3、主机证书里的公钥不使用服务器的私钥加密？

问题是可以主动选择信任服务器呀，如果加密了，本地解不开证书里的公钥，那么后面怎么玩；

特殊情况分析：

1、既然能够轻易取到正确的证书，那么拿到整整的证书伪装目标服务器不是难事（再通过DNS污染或者在网络节点中动个手脚重定向网络数据）？

但是没有服务器秘钥，即使通过服务器验证，但是服务器和客户端的交互的数据是公私钥加密，后面的过程是无法继续的，因为客户端无法理解假的服务器的数据，反之亦然。

2、非对称加密只有拥有互补秘钥的双方才能解密对方加密的数据，在http中，对关键字段使用公钥，比如登录的密码，在浏览器中，公钥直接写在服务器返回的页面中，APP的http请求，直接使用预定的加密公钥加密不就行了？

但是基于现在的网页交互原理，首先需要向服务器请求数据然后才能开始一些列交互，那么如果这时的服务器是假的，后面再严密的保护措施都是摆设
即使是APP，可以直接使用APP中携带的公钥加密数据后向服务器发起请求，那么如果窃取到了http数据，就不care内容了，直接组包也能向服务器发起请求
 

3、http存在内容被篡改的风险，https能防御吗？

不能，但是能够确定是否被篡改了。人在河边走，怎能不湿鞋，跑在公网上不能确保安全的。http本身带有内容的签名，但是由于协议开放（即使不开放，只要有现存应用能解，理论上就能破），签名方式也是公开的，中途内容被修改然后重新签名，接收端是无法通过签名确保数据的合法性，但是https对内容的签名做了传输秘钥的加密，如果数据被篡改，但是无法正确签名的；

为什么不使用证书里的秘钥，因为假如有人在通信的过程中截取了服务器发向客户端的数据，那么由于服务器证书是的开放的，无论是谁都能取到证书，然后SSL是个开放的协议，证书谁都能用，使用其中的公钥解密报文不是问题

 

https能够完全保证传输安全吗

1、https只能保证信道安全，即使一方伪装为欺骗者，但是由于秘钥的存在，无论在哪一阶段进行伪装，都因为无法明白对方讲什么，无法告诉对方任何东西而告终，但是，假如信道两端出现问题，那么无解，如：

https普遍运行在浏览器。浏览器提供数据解析的公共设施，假设你的浏览器是某黑开发提供的，然后他内部有个黑规则，只要是使用某个黑私钥加密的证书，浏览器自动放行，那么小心被钓鱼了。除此，本来浏览器可以选择信任的不安全的https连接。
即使是APP上使用https，除非基础设施自己造轮子，否则如果基础设施被加了后门，那么不能幸免。然即使自己造轮子，万一中病毒，被别人修改了代码呢，被别人窃取到秘钥呢。。。
CA不守规矩了，随意颁发证书，那么服务器就能够完美的伪装成目标服务器了
攻破了服务器，拿到了私钥，然后伪装为服务器
除此之外，服务器人为泄露秘钥呢